WIP: Fix option namespace pollution #951
Closed
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.
Work in progress. Added a feature flag to get new behaviour, where option values are not stored on the Command object but in a separate field and accessed using new accessor methods. The new behaviour is opt-in, unchanged clients get unchanged old behaviour for first release.
Builds on work in #515 and #673
Feedback welcome (from anyone). Still a work in progress, I am still coding to try ideas so anything could change. 🛠
I will move to branch on tj/commander if other maintainers want easier access to code.
Still under consideration:
should new accessor methods be get+has (like Map) or getOption+hasOption for clarity?get/has for simplicity, like original propertiesbetter name for mapStyleOptions?storeOptionsAsPropertiessetFeatureFlag or setFeatureFlags?setFeatureFlagsStill to prototype:
.opts()
in README description of options tooCode fragment:
Other changes:
version
out of new-behaviour option values, because it is not really an option value (?)