useContext would be more efficient for changing theme values then a local subscription and useState variable duplication for every useStyles hook

[kevpug]

Hello!
Firstly, I love your lib and is currently kicking NativeWind and switching to Unistyles.

Secondly, considering I'm working on a big scale app with my own atom components that I reuse EVERYWHERE, I have A LOT of useStyles hooks that are being created.

Now, I got stuck on what you said on Discord about useContext & useState being the same.
So, to silence the VOICES, I went and tested it.

Test: Rendering 1000 views that each have their own useStyles hook.

Screenshot 1: The current implementation of useStyles using a localized useState and a subscription to an event for every useStyles called

Screenshot 2: Added a theme provider at the root with a useState variable that tracks the theme and modified the useStyles hook to use useContext instead

The results shows that the current way and the useContext way have some differences:
The initial render time is the same, which is REALLY good! But, changing the theme (and maybe even the other values like the insets and width/height) is slower with the current implementation compared to useContext.

I suspect that, adding a subscription and it's own local state variable to each components adds a lot of overhead when anything from the useStyles hook changes (mainly if your design pattern causes lots of useStyles hooks being used).

I know that V3 is in the works and will do some beautiful voodoo magic with the ShadowTree to do no rerenders, but for the time being, wouldn't converting to useContext be better for the layout, insets and theme changes?

Related repos:
The test
The fork where I changes for using useContext in useStyles hook(I only changed what was necessary for the test, so all the other things like UnistylesRuntime.themeName or UnistylesRuntime.setTheme do nothing and are not in sync with the context value)

[jpudysz]

Interesting findings!

I know that V3 is in the works and will do some beautiful voodoo magic with the ShadowTree to do no rerenders, but for the time being, wouldn't converting to useContext be better for the layout, insets, and theme changes?

The library is evolving all the time. If I hadn't gone fully native, I would have happily convert current solution to useContext in new 3.0. However, at this point, it's too late to introduce breaking changes with version 2.9.0, as I will soon release a new version without context, hooks, etc.

The current implementation meets the needs of 99% of developers. I understand that, with a large codebase, it might produce overhead in rendering. You can simply fork the repository for the next few weeks and patch it with useContext. I can even answer some questions how to do it if you have any.

I will be happy to give you early beta access of 3.0 to test it with such large codebase. I hope it will resolve all the issues mentioned by you.

[kevpug]

Makes total sense! Native ftw
Will complete my fork while waiting for V3:p

[yousefelgoharyx]

Hey, that's really affecting me, I'm using unistyles everywhere in the app and changing theme or orientation is very very slow
What do you suggest to solve this

[kevpug]

Hi, if that's really a big problem for your app here's a step by step guide to replicate what I did to achieve what was described above:

1. Fork react-native-unistyles yourself (since I'm not really updating my fork & the code I did is not that polished)
2. Add yourself a UnistylesProvider like this
3. Add it to the index.ts like this so it's available for import
4. Then modify the useStyles.ts hook to use useContext of your provider instead like this & remove the import of useUnistyles hook
5. Get rid of src/hooks/useUnistyles.ts file and remove it's export from the src/hooks/index.ts
6. Build with the script "prepare": "bob build" (Remove all related to husky and .husky folder we do not need git hooks for this)
7. Remove lib folder from .gitignore and the push the build to your fork
8. Install custom version of package. For example this looked like this in my package.json (I use yarn): "react-native-unistyles": "git+https://github.com/kevpug/react-native-unistyles.git#package" (Be sure to add the right branch after the #)
9. Add the new UnistylesProvider to root of your app:

import { UnistylesProvider } from "react-native-unistyles";
...
<UnistylesProvider>
...
</UnistylesProvider>

10. Rebuild your app & enjoy

If your unistyles config is set correctly It should be plug and play and work just as normal (Same functions to change theme, etc...)

If you have any problems let me know and I'll try to help. :)

[yousefelgoharyx]

Thank you so much!!
That's really really helpful

[yousefelgoharyx]

Most apps will have a tab navigator that's always mounted which causes switching themes in unistyles to be very slow in even medium sized project
setting freezeOnBlur helps the situation a little bit but it causes a flash of the previous theme