Idea: Experimental feature flags for CesiumJS
See original GitHub issueThinking about the future of the Model.js
refactor (a large part of #9520), one concern is migration will prove difficult, as there are many, many intertwined features there.
To help avoid creating staging branches for many months on end, it would be nice if we had some standard mechanism for enabling/disabling experimental features. This way, users can try out new features before they are fully finished.
For example, for 3D Tiles it would be very helpful if the contents could do something along the lines of:
var model;
if (ExperimentalFeatures.enable3DTilesNextModel) {
// Experimental version of Model. Basic rendering may work,
// but other features like animations and glTF 1.0 support are not yet implemented
// and may break.
model = new Model2(...);
} else {
// Original Model.js implementation
model = new Model(...);
}
Then applications only have to specify Cesium.ExperimentalFeatures.enable3DTilesNextModel = true
to try the new version of Model.
This could be used for other large features in the future as well. The important thing would be to clearly mention that experimental features are subject to change from release to release, use at your own risk.
What are your thoughts, @sanjeetsuhag, @lilleyse, @ebogo1? Is ExperimentalFeatures
something that would benefit CesiumJS in the long run? Are there any potential pitfalls to doing this?
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
@ebogo1 That’s a good point, though I think we should keep this simple, just a flat list of flags for now.
I plan to make a PR for this early next week. In the code I’ll include a block comment so we can describe best practices for this from the start. Some ideas:
Closing this as
ExperimentalFeatures
is now available in the latest release.