jquense / react-dom-lite

Tiny dom implementation using react-reconciler

React DOM Lite

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery.

Compliance and amazing cross browser support led to a robust but heavy react-dom. React DOM Lite is an attempt to sculpt away some of the mass away and see if we can make something more low powered device friendly.

Road map

Keeping in mind the existing React ecosystem (and of course the web ecosystem too), following is the feature list to attain feature parity with the existing react-dom:

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

The goal is to be compatible with the react ecosystem, while remaining lite. This will likely mean that the supported browsers, will be more limited than react-dom, and attempts to polyfill differences between browsers will be limited and more tightly scoped.

react-dom-lite's Issues

Write protect master branch

Can you please write protect the master branch? Just to prevent accidental pushes.

Appear to build in development mode

Hi,

Thanks again for this module.

I'm having issues with my app using react-dom-lite showing up in React Dev Tools as having been built in development mode.

Following the guide here:

https://gist.github.com/bvaughn/73da9c832bef5dcaf1fcf9ea6528d94c

And the debug shows I'm evaluating if (renderer.bundleType > 0) as true.

The webpack 4 config file I'm using is:

https://github.com/technion/p3/blob/f630fb46867a64dd38f0a73499e1aa0a1fe8afcd/frontend/webpack.config.js

When I build in --mode production, it outputs "Running webpack prod build" per the debug on on line 56.

I've saved an output file here if it helps:

https://p3.lolware.net/p3-broke.js

Tooling and workflow setup

We could mimic react's setup as much as possible to reduce the onboarding time for new contributors. I, for one, am comfortable and infact tuned to upstream's standards. Any disagreements/suggestions can be discussed here.

Things we need in the workflow before we proceed with any new development

• Tests
• Prettier
• Linting
• Flow
• CI

Please let me know if I missed something.

Update to the latest reconciler

Would be nice to get context API support :-)

If you have any questions hit me up!

Inline host config at build

we should do this: facebook/react#12792

Roadmap

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

Use Rollup + GCC

In our experience they provide the best bundle size.
Let's use them here too?

Consolidate all our lightweight react-dom efforts

Quoting from the email earlier.

I just realised we all have independently been working on creating a light weight version of react-dom. It would be great if we could consolidate all our work into a single library.
What do you think? The obvious question is who would be the maintainer. We all can. We could put this under a separate organisation, to be fair to everyone's work. Depending on how much time and effort we can spend and our priorities I'm sure we can definitely work it out.
I'm equally excited about the new reconciler API as you guys. Let me know your thoughts :)

Just for reference I'm jotting down everyone's repos here so that we can take a look at each others work.

Jason Quense @jquense : https://github.com/jquense/react-dom-lite
Jiyahi Hu @jiayihu : https://github.com/jiayihu/react-tiny-dom/
Manas Jayanth @prometheansacrifice: https://github.com/prometheansacrifice/react-dom-lite/

Automagic setup?

Hi,

Thanks a tonne for this library, I feel it's exactly what we need.

I'm just wondering if there's a sane way to somehow have this replace react-dom globally? The problem I have is:

• Install the module
• Change my only ReactDOM import in accordance with your example
• Suddenly bundle size goes up

The reason for this took a while to track down, being that material-ui at some point imports react-dom. Are you aware of any way to shim third party libraries without sending a series of PRs and hoping they accept?

Long installation times because of electron

I was installing RDL earlier as an rpm package when I realised we have react-devtools. This led to a really long installation time because of electron. Do we need it? I grepped and couldn’t find where it was used. It seems it was added in the initial commit https://github.com/jquense/react-dom-lite/blame/master/package.json. We must have missed it earlier since we already had electron installed.