feat: make renderer methods public or protected #6887
Merged
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.
The basics
npm run format
andnpm run lint
The details
Resolves
Fixes #6871
Proposed Changes
@internal
, mostly only the top-levelrender
API which is called by blocks, and the debug methods which are due for removal anyway.goog
, it was not being surfaced in the reference docs, and was usually redundant with the real class documentation. In cases where it wasn't, I updated the real class documentation.Behavior Before Change
No reference documentation for renderers, and mixed messages about whether we wanted external developers to subclass renderers.
Behavior After Change
Developers can subclass any renderer and read documentation about the methods they're subclassing.
Reason for Changes
Developers are allowed to subclass renderers.
As an aside, we are not entirely sure why all of these methods were
@internal
to begin with. The@internal
annotation means it used to be@package
in the closure JS days, but we never intended to block developers from subclassing renderers. The leading theory is we locked them down while the new rendering system was in development/testing/beta, and they were never unlocked afterward.Also, this change is necessary if we were to move renderers out of core and into plugins.
Test Coverage
tsserver recognizes
Blockly.blockRendering.BottomRow
andBlockly.zelos.ConstantProvider
(this was also true before but it's still true)tested renderers in advanced playground
Documentation
Reference docs should now be generated.
Additional Information