Make react-dom and react-art depend on react-reconciler from npm

[devongovett]

Currently, the react-dom and react-art packages each have their own copy of react-reconciler compiled into them. This means, if you use them together, you get two copies bundled in your app. react-reconciler is around ~93 KB minified, or ~30 KB min + gzip, which is not super small.

This also affects other renderers like react-three-fiber, react-pixi, react-pdf, etc. Each of these depends on the react-reconciler package from npm, but react-dom also has a separate copy meaning if you use them you get at least two copies.

It would be nice if react-dom depended on the react-reconciler package from npm rather than compiling an additional copy into the distribution. This would reduce the bundle size of applications using multiple renderers by at least 30 KB min + gzipped.

Is there a reason this is not already the case?

[sebmarkbage]

1. The inlining is important for runtime perf and some parts of the reconciler isn’t used. Perf is at least way less predictable and likely to cause VM deopts due to polymorphism.

2. Versioning. The host config protocol isn’t stable. It changes a lot. So as soon as a new version is published everyone would have to be immediately up-to-date.

We want to add some kind of lower level bindings for implementing custom “host components” but even that is kind of still influx since we’re changing the protocol and adding new features that host components can do. However this would still be more targeted to low level operations on a particular environment (eg dom nodes).

It’s actually kind of hard just to preserve the versioning between the “react” package and the reconcilers today. There are breaking changes and not all reconcilers work with the all the minors of “react” for the same major.

This would make that worse, or you’d be duplicating the code anyway.

[sebmarkbage]

Tbh I’ve been wanting to go the opposite way and have custom reconcilers use the same build tooling we use to inline the config. They run unnecessarily slow and the full react-reconciler’s size is much larger than it would be when inline and dce with a custom host config. Eg hydration code can be dce.

You can tell the cost of the reconciler in the react-art package. More like 23kb gzipped.

[devongovett]

Would be curious to see how much runtime perf changes. Wonder how this changes with modern bundlers that perform scope hoisting.

Wouldn't versioning be solved using a pinned version from npm? Or make react-reconciler follow semver. Then at least there is a better chance of them overlapping. Looking at the version history on npm, it doesn't look like it changes more than a few times a year (maybe more recently with React 18 release).

have custom reconcilers use the same build tooling we use to inline the config

I tried this by copy pasting the reconciler package, removing the function wrapper, and assigning the $$$hostConfig variable at the top of the file. It helped some, but not as much as I hoped.

More like 23kb gzipped.

It's 28kb by default, so this isn't that big a difference. Similar difference to what I saw doing the above.

[sebmarkbage]

At the end of the day though, the DOM one is by far the most important one and the main product. The other use cases tend to be more esoteric and loaded in a specific setting. We wouldn’t compromise the main one that tends to load earlier and is a predictable and cache stable bundle. Especially since it’s susceptible to way more scrutiny.

If anything it would have to be a special build that opts into deopting the DOM build to share it. It likely wouldn’t get as much love and would be ok if it deopted.

What’s your use case?

[devongovett]

Well, ideally it probably wouldn't be a custom reconciler but something else (like you mentioned for implementing custom "host" components), but custom reconcilers exist today so I was trying to come up with something there.

A bunch of libraries have a problem where they need to know about certain types of descendants. For example, a list component with keyboard navigation needs to know what elements exist in the collection in order to implement things like typeahead, arrow keys, selection, etc. Reach UI has a good overview of a bunch of different approaches to this. The most commonly used of them involve rendering all of the items to the DOM, and using some kind of context-based registration system to tell the parent about themselves, and the DOM to sort them into the correct order.

This has the downside that all of the items must be in the DOM at all times. In some cases, like virtualized scrolling, or a combobox/select where users can set the item without showing the list, some or all of the items shouldn't be rendered to the DOM. In React Aria, we walk the JSX tree to do this, which makes for a more natural API than giving up JSX completely (info). But this breaks composition, because only certain known element types are allowed.

With a custom reconciler, I could make <item> a host component, and build my own tree, without rendering any deeper than that until the real items are rendered to the DOM. I did a quick prototype and it seems to work ok, but the additional bundle size required for another copy of react-reconciler means I probably won't go this way.

I'm sure you have ideas on how this could be solved in the future (happy to discuss them here or elsewhere!), but I was looking for something that would work today and this seemed pretty close.

[sebmarkbage]

There are not yet portals between custom reconcilers and react-dom so even if you had one you’d loose a lot of features and fidelity in the seams. I think you would want the rest of the DOM to keep working like it does in the same reconciler. So it would be more like an intercept layer. One solution to this is just to fork react-dom like a long lived patch and then have users alias it.

Ofc it probably would be better if something in React could do what you needed.

I’m curious what this approach gives you over context registration?

[devongovett]

Mainly just that the items don't all need to be in the DOM for it to work. So virtualized scrolling can work, and still support keyboard navigation to items out of view (e.g. Home/End). And beyond that, sometimes we need the collection of items even when none of them are rendered, e.g. a closed combobox/select can still support typeahead (example, try focusing the button and typing, or using the left/right arrow keys), or to render the selected item's value.

[sebmarkbage]

I think I’m missing something because you don’t need to render them into the dom to register some abstraction with a parent.

You can register a component that doesn’t renders its children for example, which I assume is how you’d do it with the custom renderer.

You still need to render some part of the item if it’s wrapped in abstractions so neither solution works if it’s virtualized at the children level.

[nihgwu]

Hey @devongovett, I'm developing a package which can solve the problem you described above, for list you can render the abstraction without deep children to get the registration and then custom your render based on it

[devongovett]

I'm not sure if it's possible to get the correct order for registered items without the DOM. You can register items with a context, but if React renders the items out of order for some reason (suspense?), or a new item is added without the parent list re-rendering (e.g. in a child), you won't know the right index to insert it. That's why all the implementations I've seen register the objects plus a ref to an element, and then sort the array based on the rendered DOM order.

[nihgwu]

@devongovett If a item is inserted, it will clear registration and rescan, so the order will be guaranteed, same for suspense, as it will insert new items, I built a test page for this case

BTW, actually the package is initially created to make component composition more predictable for layout and easier for a11y support, but I think it would be nice to support list slots as it's the last missing piece 😄

[devongovett]

@nihgwu my reply was directed at @sebmarkbage, sorry for the confusion. 😄

But yes, I suppose you could force re-render every item whenever a new one is added/removed. Just seems a bit inefficient.

[nihgwu]

@devongovett sorry for interrupting but I guess my idea is a possible solution for your problem, and yes it's seems not that efficient, so I'm thinking if it's possible to support slots in React directly instead of such kind of hack

[Eldeloro1]

I'm not sure if it's possible to get the correct order for registered items without the DOM. You can register items with a context, but if React renders the items out of order for some reason (suspense?), or a new item is added without the parent list re-rendering (e.g. in a child), you won't know the right index to insert it. That's why all the implementations I've seen register the objects plus a ref to an element, and then sort the array based on the rendered DOM order.