Parchment does not support multiple registries about parchment HOT 5 CLOSED

Separate registries would really help us in our use case with multiple editors on a page, each needing different formatting options

from parchment.

Sadly the linked branch is far from near complete. By my estimate it is still in the very beginning stages where the design is still not vetted as I already mentioned in slab/quill#1101. Skipping the design of the solution before implementation will lead to the need to implement multiple times. Invest the time to design properly and you will only need to implement once (and the typing will go very quickly).

Also stated in the Contributing Guide is that API modifications undergo the most scrutiny. It is not enough to be bug free or backwards compatible, it also needs to be the best possible solution and API design to be merged into core.

So if you want to make progress on the PR, spend a much larger portion of time thinking about the API, how it interacts with existing APIs and features and how your solution will behave, and then propose that solution.

If your motivation was just to use this feature, then the simplest solution is just maintain your own branch or fork, so you do not have to meet the standards Quill core must meet given its wide audience.

from parchment.

I've been watching this request for a while, and based on years of working with rich text editors for client projects, I think it would be best practice to isolate each editor's formatters - or at least provide an option to do so. Most editors on the market, open source or commercial, do this by default as it allows an editor to be used in different use cases on the same page.

My experience with Quill has had some surprises. Formatters loaded for one editor affect all editors, allow pasting of content into another editor that may not have appropriate toolbar buttons loaded for the content. There's currently no way to prevent an editor from supporting features intended for another editor on the same page. Making this change (merging this PR, or doing something else) would help modernize an otherwise strong product.

from parchment.

@jhchen From my perspective, the design is a fairly common convention, using class instances rather than attaching state at the module level...but I wasn't present for the initial design and development of the project, so it's difficult to anticipate the direction of the code base and fit the needs of the team who created it.

Maybe forking the project is our only option, but this is not an immediate need. Do you foresee the idea of independent registries being implemented in Quill 2.0 with a different design pattern? Also, are there specific areas of the design that you find problematic?

From what I can tell, it looks like the syntax module and some concerns about the boundingRectangle of the editor are the only incomplete details of the design. Otherwise it seems to function as intended. Again, this is a complex project, that I was not involved in from the start, so the nuances are beyond my ability and collaboration with the founders is entirely necessary to introduce updates to the API.

from parchment.

Supporting multiple editors better is a high priority so there is no disagreement on the need. I do intend for it to be a part of 2.0 one way or another.

The questions I posed in the issue were not very in depth (ex. what do the quickstart instructions look like now) and half were answered by just my drawing attention to them. The first premature jump into implementation already yielded the expected result of premature implementations. This is why I stress thinking through your solution first. This is not a Quill specific thing. We have not gotten to the interesting Quill parts yet and there is a ways before that happens, which I do not need nor have the time to be a part of.

from parchment.