You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR was written to clean up usage of expression renderer handlers.
After a short investigation, I've realized, that there is no way to remove some custom handlers of a plugin, where the renderer is executing and decided to write an extendable and flexible way of emitting and binding listeners on events. Right now, every expression_* plugin will need to defined emitters it is listening to as a type (only custom, resize, for example). They will appear as available keywords for event field in on(event, fn) method. If a plugin, which is executing a renderer will not have such emitter at its own handlers, it will be just ignored.
At this PR I've separated emitting and listening to events. As if at the further PRs, related to Expressions extracting, will contain a lot of code, rewritten from legacy on[Something](...) to event({ name: ..., data: ... }), I've decided to separate listeners and emitters of events to prevent spreading unclear code over the further plugins.
It is providing new pattern of listening and emitting events: on(event, fn) - binding listener; event({ name, data }) - emitting event.
A new type has been provided: InterpreterRenderHandlers<Emitters> - describes all emitters, which exist in handlers, Emitters are optional and enable extending some custom emitters of the platform.
A new function has been provided: getDefaultHandlers<T = {}> (): InterpreterRenderHandlers<T> - method, which creates object of handlers with all necessary emitters and listeners, specific to the place of executing. The object it returns contains on(...) method, which can bind listeners to all events, specified at T type and part of events from IInterpreterRenderHandlers interface.
Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.
Total count of every any typed public API. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats any for more detailed information.
Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
This PR was written to clean up usage of expression renderer handlers.
After a short investigation, I've realized, that there is no way to remove some custom handlers of a plugin, where the renderer is executing and decided to write an extendable and flexible way of emitting and binding listeners on events. Right now, every
expression_*
plugin will need to definedemitters
it is listening to as a type (only custom,resize
, for example). They will appear as available keywords forevent
field inon(event, fn)
method. If a plugin, which is executing a renderer will not have such emitter at its own handlers, it will be just ignored.At this PR I've separated
emitting
andlistening
to events. As if at the further PRs, related toExpressions extracting
, will contain a lot of code, rewritten from legacyon[Something](...)
toevent({ name: ..., data: ... })
, I've decided to separate listeners and emitters of events to prevent spreading unclear code over the further plugins.It is providing new pattern of listening and emitting events:
on(event, fn)
- binding listener;event({ name, data })
- emitting event.A new type has been provided:
InterpreterRenderHandlers<Emitters>
- describes all emitters, which exist in handlers,Emitters
are optional and enable extending some custom emitters of the platform.A new function has been provided:
getDefaultHandlers<T = {}> (): InterpreterRenderHandlers<T>
- method, which creates object of handlers with all necessary emitters and listeners, specific to the place of executing. The object it returns containson(...)
method, which can bind listeners to all events, specified atT
type and part of events fromIInterpreterRenderHandlers
interface.Example of usage
Imports:
Definition in plugin which is rendering:
Definition in
expression_*
plugin:And binding listener in
Component
:As a nice bonus, dynamical autosuggestions