Roadmap

[jquense]

Here is is a quick list of the big bits of functionality that react-dom provides, that RDL does not at the moment.

• SVG and namespaced attribute support
• Event normalization / polyfilling
• Portals (event propagation)
• Controlled inputs
• Browser support matrix
• SSR, hydration.

One thing to figure out is what "feature parity" looks like for this project. Is the goal to try and provide the same or close to the same feature-set as RD but smaller, or are we ok supporting fewer browsers, and features? I can think of an important line to note along that spectrum, the one where most existing react-dom packages will or will not work with RDL. I think being able to leverage the existing ecosystem of react components is a must so we need to figure out what is required to implement from that perspective.

For instance without using the synthetic event system we save a ton of bytes compared to RD, but lose the ability to neatly polyfill or normalize event behavior across browsers, That is isn't likely to break any existing packages (to some degree) but it does mean that we are limited to browsers that support all the events. I also think we can do some simple work around event listening to pool listeners do some basic event object normalization to shim out the same API at least as the synthetic event system.

The other question is how far do we go supporting controlled inputs? We need to figure out how to handle reacts onChange (maybe just attach onInput?) and react controlled inputs with imperative value sets, a fraught area that @nhunzaker can attest to.

There are also the million other places that we don't cover an edge case RDL does. For instance, the current "property vs attribute" strategy in RDL is "use the property unless it doesn't exist" which cases us a bunch in whitelists and log, but differs from upstream. I think some of that is good to try and experiment with, especially if it helps us make RD upstream smaller in the long run.

cc @gaearon @prometheansacrifice

[gaearon]

IMO one angle worth considering is “what would a mobile-focused version of react-dom look like”.

[ManasJayanth]

My thoughts:

One thing we all agree upon would be for the library to play well with the Web ecosystem and of course the React ecosystem. This combined with focus on low powered devices could be a great driving force for RDL.

1. Things like MathML and SVG, though with poor browser support enable expressing/communicating things on the web better. One solution I have is have compile time checks like shouldSupportMathML, similar to React’s __DEV__ checks, and maintain different builds - for example one with support for MathML and one with just DOM.
2. Event normalization / polyfilling: I’m tempted to say, simply ignore non standard behaviour, but its not as simple as that right? This I think will end up being string of experiments till we find a clean way to account for bad browser behaviour
3. Portals: We could come back to this later as its not something app authors cannot live without. At the same time support Portals doesn’t seem like it’ll cost us a lot
4. Controlled components: These exist as a result of the first principles. Definitely as must. How far do we go implement it: atleast as much as fundamental v = f(d) needs.

[ManasJayanth]

Summarised this thread in a Road map section of the ReadMe.md. @jquense Close this issue for now?
Or clean it up and label it discussion?

Summarised the discussion so far in ReadMe.md

[nhunzaker]

The other question is how far do we go supporting controlled inputs? We need to figure out how to handle reacts onChange (maybe just attach onInput?) and react controlled inputs with imperative value sets, a fraught area that @nhunzaker can attest to.

I think you could get pretty far just listening to onInput without a polyfill, maybe redirect onChange to onInput for compatibility with React, then never touch the value attribute on input elements. Then the only trick is just to only assign value if the property is different, which could probably be isolated to a single equality check function with a ton of unit tests.

Certainly, anyway, if it wasn't for the backspace issue with onInput on IE9, I'd love for React to just do this.

[jquense]

I'm hoping we can gain some learnings here to push back up! I'd also love to get your eyes on on my first pass at controlled components once I push the branch (I'll ping you on it)

[nhunzaker]

Please do :).