- Element and Component Identity:
At the moment, whenever a particular branch of a layout is updated, all the state (i.e. hooks and event handlers) that live within that branch are thrown away and reconstructed. Given IDOM’s current implementation for
Layoutthis is unavoidable. To resolve this issue, we need to add a concept of “keys” which can be used to indicate the identity of an element within the layout structure. For example, if you have a list of elements that get re-ordered when a button is pressed, their state should be preserved, and reassigned to their new location in the layout.
By default React requires keys to be used to communicate element identity whenever the order or number of sibling elements can change. While there are clear performance benefits for adhering to this stipulation, it’s often confusing for new developers. React has the further advantage of the JSX syntax, which makes it easier for the program to determine exactly when keys must be supplied by the user. To make the experience for new users simpler, and due to a lack of enforcement via JSX, IDOM will be to assume that any element without a key is new. Thus, for IDOM, keys will primarily be a tool for optimization rather than a functional requirement.
- Reconsider Custom Component Interface:
One problem that’s come up several times while implementing alternate client solutions with React is that custom components must use the same React instances as the client. This is problematic for developers of these custom components because they need purpose-built compiler plugins that will convert imports of React to point to the location
react.jswill be once the component has been loaded via