JS Performance

[nandorojo]

Big fan of the approach taken by this library, and generally with the React DOM for Native RFC. I gave a talk about my hopes for the future of RN dedicated to the RFC: https://www.youtube.com/watch?v=dKItY_2wFH0

That said, I am curious about plans for implementing good performance. It appears that, on native, react-strict-dom uses multiple contexts and re-renders on any screen size changes.

react-strict-dom/packages/react-strict-dom/src/native/modules/useStyleProps.js

Lines 32 to 46 in b62769c

	export function useStyleProps(
	style: Styles,
	options: StyleOptions
	): $ReadOnly<{
	style?: $ReadOnly<{
	[key: string]: string | number | Animated.Value
	}>,
	...
	}> {
	const { height, width } = useWindowDimensions();
	const inheritedFontSize = React.useContext(FontSizeContext);
	const inheritedCustomProperties = React.useContext(ThemeContext);
	const writingDirection = React.useContext(WritingDirectionContext);
	const fontScale = PixelRatio.getFontScale();
	const { customProperties: customPropertiesFromThemes, hover } = options;

In my experience, the React Native's Text component is somewhat slow. When we switched to using createElement('RCTText, props) instead of <Text>, our lists got noticeably snappier. I assume this slowness is due to the pressability hooks/nested text style context/other stateful hooks inside of Text.

Is it possible to implement themes and other useful features on the native side, without relying on React context in every component? Or is this more of a secondary concern for when the library is feature complete? I understand it might not be on the roadmap now, but I'm curious if this might change in the future or not.

As it stands, the use of context is similar to what most RN libraries have to do now. But it would be great to have these primitives available to design system authors on the native side.

Thank you!

[necolas]

Is it possible to implement themes and other useful features on the native side, without relying on React context in every component?

Yes eventually.

Or is this more of a secondary concern for when the library is feature complete?

Exactly. Community adoption and advocacy will help us to prioritize this direction internally, and get more investment in native implementations of the core API based on web standards. Everything from W3C compliant CSS features and Events, through Elements and Web APIs.

React Native has been moving quite slowly as most attention is on getting Fabric out. This library is needed to prove out the value of the target API I proposed in the RFC, and allow our internal teams to actually build stuff in the meantime. As you mentioned, lots of the core components in RN are already quite inefficient, so we'd like to build out a completely fresh set of native primitives one day that model these web primitives and implement the correct W3C semantics and props. Certain features, like PointerEvent support and the traversal APIs, are already in native and could be reused in some form on these new, faster primitives.

I'm hopeful that this project will encourage the community to kick-start the effort of building new core primitives over in React Native, so that our internal teams can see the wider interest, and have an easier time prioritizing internal resources.

[nandorojo]

Community adoption and advocacy will help us to prioritize this direction internally

Happy to help with this where possible. I think the reception will be very positive, especially if it’s communicated that any performance-heavy features could be offloaded to the native side in the future. This possibility alone makes me get behind it.

[necolas]

Just to add, there are many features that cannot be polyfilled, so I've been trying to get RN to invest in those first because they block migration of large chunks of our web code to native. Spending years replacing working polyfills without adding significantly to the overall feature set would risk losing the internal product customers who were only able to invest in this direction because we created these polyfills. Better to have people using APIs and wanting them to be faster than not having any customers left because there are so many missing capabilities that web products can't realistically run on native beyond a few toy examples.

[nandorojo]

Better to have people using APIs and wanting them to be faster than not having any customers left because there are so many missing capabilities that web products can't realistically run on native beyond a few toy examples.

Definitely.

I've been trying to get RN to invest in those first because they block migration of large chunks of our web code to native.

It would also help if people know that PRs to the native side will get reviewed and merged. The Web umbrella issues and their quickly-merged PRs got good reception from the community and helped spark necessary excitement about the future of RN.

Historically, PRs to Yoga / RN’s native features have had a reputation of getting ignored. So if these get looked at I think it will 1) get users behind React Strict DOM and 2) attract people to contribute the missing features on the native side.

[necolas]

We're also open to further incremental improvements if people have ideas for how to implement certain polyfills in user-space (i.e., not in React Native) without relying on React Context.

[nmn]

There may also be some possible improvements we can make with React 19's use() function and the optimisation when using it within a useMemo.