(the title is in jest, because there is not a lot in common with React here beyond the idea of having components that handle their own representation)
This does a few things:
- Introduce a new XML tag component that uses JS to generate its own XML, and creates a corresponding instance of the JS object.
- Engine.GetGuiObject returns the JS component for components instead of a 'fake' C++ object, making them effectively equivalent to the XML node.
- JS Components proxy to the C++ so things still work
- Objects can add children at runtime by using appendChild and putting XML in there, either an object or a component.
- Rewrite the developer overlay as a test bed & example of this feature.
The design goals are:
- Reducing the barrier between JS and C++ Objects, making it possible to create generic JS components that enhance raw C++ functionality (or even components entirely out of JS).
- Making it easier to develop for the GUI, allowing more dynamic setups.
The Dev overlay was chosen to test because it fits an arbitrary number of commands, with somewhat arbitrary capabilities that don't all neatly fix a checkbox.
- The c++ code needs a lot of work
- appendChild taking XML is kinda dumb. It would be a better API to take a class name and a dict of attributes directly (or components at least), since that would allow passing real JS stuff such as lambdas.
- Cannot define sub-XML for a component from XML (has to be done in the JS of the component) which is a bit limiting.
- Probably want increased communication to the JS object to hook into more stuff.
- This moves us towards needing fewer GUI pages, for sure.
- This moves us towards looking a lot more like the DOM.
- This makes it particularly visible that having no mechanism to include JS scripts is kind of annoying.
Might embark / make irrelevant: