-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BlockAutoformatEditing and InlineAutoformatEditing does not have docs for pluginName property #7290
Comments
Those properties can be removed as these are not plugins. |
My 2 cents: Yep it looks like those can be simple functions - we use that pattern everywhere else. Personally I don't like creating objects that are not referenced anywhere so it would be nice to refactor that (if we have time, etc). |
If we're about to do small refactoring, I'd add simplifying arguments handling to the list. Currently, there is a logic to support, various types of arguments like: |
Let's cover that in #1239. |
…d InlineAutoformatEditing. Closes #7290.
…toformatEditing's formatCallback. It was used only in tests, and was not checking whether the command `.isEnabled`. Autoformat uses its own `getCallbackFunctionForInlineAutoformat`. The change was proposed at #7290 (comment).
📝 Provide a description of requested docs changes
As you can see below
pluginName
property does not have any docs forBlockAutoformatEditing
andInlineAutoformatEditing
These properties were added at 3879b03 with
@inheritDoc
, but the thing is both classes do not inherit from anything.https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-autoformat/src/blockautoformatediting.js#L23
Personally, I don't get the design pattern there. They only have a
constructor()
defined, which does a lot, and the instances returned fromconstructors
are not used anywhere.Given the instances are not stored anywhere, I'm not sure why
pluginName
is even needed?The text was updated successfully, but these errors were encountered: