What is react-gui?

[chantastic]

Hey friends!

This tweet is bouncing around my timeline today:

https://twitter.com/estejs/status/1414259301632385027?s=21

It looks like Facebook will release react-gui soon. The library is already out, but the repository is still private.
It looks like it's heavily inspired maybe slightly changed React Native for Web.
That's what the ecosystem desperately needs.
https://ixrvy.sse.codesandbox.io/docs

The linked doc page has related homepage and playground links.

I know that this style of hooks-based event handling has been discussed and researched for years.
Is this the library the eventual culmination of that research?
Is it a defunct artifact of that research that was just recently uncovered?
A little bit of both?
Is there anticipation that it will be a part of long-term v18 release?
If not the eventual target, are there patterns and practiced to be further explored from this experiment?

Thanks for the clarity!

[necolas]

Hi Michael,

Thanks for the question and sorry for the confusion. This is a personal experiment I moved to a FB repo to share with colleagues. There is no official relationship with React. We are experimenting with it in a few places at FB in a very limited way, and at this stage there are no current plans for a publicly supported release. Some ideas from it have been feeding back into React Native for Web and discussed with the React Native team, but it's too early to say whether this will become anything more.

I'm happy to discuss some of the thinking behind the experiment wherever those conversations are best had :)

[chantastic]

Nicolas! Good to see you 🤩

Thank you for the clarification. I love seeing those RNfW roots getting closer to React 😀 This looks great and I'm excited to see where your research goes.

I like this example where you demonstrate how this gives flexibility and control to component library authors.

[sebmarkbage]

@chantastic Related to this and React 18 Alpha. In earlier experimental releases we relied much more heavily on React's internal event system. Meaning that if you used raw addEventListener on a DOM node, it didn't work quite the same. The general new direction is to move away from relying on React's synthetic events and move closer to the DOM.

This allows user space libraries to build abstractions such as this one in react-gui and not worrying about being left out. It's also the status quo that not everything goes through React's synthetic event system so it eases the upgrade path, and compatibility with third party.

• In React 17 we moved listeners to the root to allow bubbling between React nodes and outer DOM listeners to interleave.
• In React 18 alpha we started to use microtasks to infer the border between events for flushing discrete work - instead of using React's internal listeners for this.
• In React 18 alpha we infer the event priority based on window.event at the time you call setState. So even if you're in a user space event listener, we know if it's safe to batch them asynchronously or not.
• Before React 18 beta, we plan to move some parts of Selective Hydration to native listeners so that user space listeners work just as well as built-ins for SSR. Currently, only React listeners are replayed and the timing of some user space listeners might be a bit too late for them to fire on selective hydration.
• User space listeners on DOM nodes are not interleaved with bubbling on React listeners. In a future release we could possibly move to attaching React listeners directly on the DOM nodes to solve this.
• User space listeners don't bubble through Portals.

This doesn't mean that this low level access is the end game. It just means that the React event system isn't the right level of abstraction. New high level abstractions can be experimented with in user space.

[Andarist]

What kind of an impact moving to native listeners have for event bubbling through portals? 🤔

[necolas]

@Andarist Any user-space use of native listeners will not bubble through portals in the same way, as React is not managing those events and not dispatching them through the synthetic event system. React Portals don't currently support preventing events from bubbling through portals, so for the use cases where event bubbling through portals is not desired, using native listeners could simplify product code. As @sebmarkbage mentioned: we're better able to explore these ideas in user space now thanks to changes going into React 18, but it doesn't necessarily mean work taking place in user space will stay there if it proves to be a good idea.

[chantastic]

Thanks @sebmarkbage for the additional insights on the goals for the event system and items standing in the way of that goal 🙏