Unistyles 3.0

[jpudysz]

Hello developers!
I started R&D phase for Unistyles 3.0. At the moment I'm exploring new ways to achieve faster rendering, less or zero re-renders as well as some cool new features. It will take some time as I need to dig deep into C++ and Fabric.I will start actively developing new core as soon as I achieve POC that satisfies me.

[jpudysz]

Hey everyone, I’ve started converting the core to a more extensible structure. I've learned a lot about C++, and I can see some issues that need to be fixed first. From a DX perspective, the API should remain exactly the same, so I will gradually release updates on the 2.x branch.

[oscklm]

That's awesome. Looking forward to it

[jpudysz]

After the successful release of v2.8.0 with a new C++ core, I've started working on version 3.0.
Check my progress here

There will be a lot of improvements and new APIs, at the cost of backward compatibility.
Unistyles 3.0 will be for the new architecture only, supporting React 19 / Expo SDK 52 / React Native 0.75. It will be released no sooner than a few weeks after the premiere of Expo SDK 52.

I will share some sneak peeks closer to the release date 🙏🏼

[fmendez89]

Hi @jpudysz
I don't know if this change in RN 0.76 affects you, but check it out in case you have missed it.

react-native-community/discussions-and-proposals#816

[jpudysz]

Thanks for pointing this out.
I will update both 2.x and 3.x branches as soon as I will be able to download RC of 0.76 🙏

[cedricfressin]

Do you think it would be possible to create an Expo module so we don't have go through pre-build anymore ?

[jpudysz]

What do you mean?

[cedricfressin]

I mean creating an Expo module with expo-module.config.json so we don't have to prebuild (and having iOS and Android folder in our project). It is not related to v3.0 but it would be a nice to have in the future.

[jpudysz]

This is my initial estimation based on the current progress. I hope it will be faster, but in case anyone is wondering if they should start a new project with 2.x or wait a little bit for 3.x.

I will keep you updated!

[AlvSovereign]

Awesome, thanks for the updates!

[nialldbarber]

@jpudysz it's clearly close! I am very keen to add unistyles to our project at work, but I'm unsure how big of a difference any API changes will be (I'm basing this off "at the cost of backward compatibility", meaning there will be API changes?).

Are you comfortable giving a rough outline on how large of a refactor there might need to be going from V2 to V3?

[jpudysz]

It's the same concept, so not that much. Different namings, imports etc

[marcel-happyfloat]

Great work @jpudysz! I'm really enjoying Unistyles and have started using it in my projects. One feature I’m missing to fully migrate from styled-components is support for nested themes. Specifically, I'm looking for the ability to define different themes based on a section of the UI (e.g., default vs container). The container might have a different background color, and all components within that container should automatically adapt their styles (like color, padding, or size) based on the container’s theme.

All the normal component variants would still apply and be adjusted depending on the nested theme, or inherit the parent theme if it’s missing some keys—so nested themes can be a subset only. Basically, a nested theme should be configured within a base theme, so it will also apply across light/dark modes seamlessly.

Right now, it's a bit impractical to pass a special prop or variant to every component depending on where it’s rendered. It would be great if components could inherit their styles contextually without needing to be explicitly aware of their parent section. Is nested theme support something planned for v3, or do you have any thoughts on how to handle this use case? Would love your input!

Here some example from Tamagui, which illustrates my use case a bit: https://tamagui.dev/docs/core/theme

EDIT: Sorry, I just found the other discussion about this topic here: #308

[knksmith57]

Thanks for acking, Jacek!

Do you have any guidance/thoughts/threads for us to pull on re: how we might approach this in userland code? I'm incredibly grateful for Unistyles and all of your time and work on the project.

If you have any ideas on how we might approach this without having to add workload to the core library, I'm sure we'd all appreciate it.

Thank you!

[jpudysz]

I don't this it's possible to achieve it without adding workload to the core library. It must be supported in the core.

[MikeKovarik]

+1 to this:

my app needs this for 2 use cases. And I'm unable to switch from styled-components because of that.

• it's a calendar & event app. Every type of event is color coded and thus the detail page of every event needs to use a different theme/tint. Specifically the way material design 3 does that where theme is based on tinted shades rather than shades of gray. So I have light green theme, light blue theme, etc... About 8 variants of the light theme.
• the app includes a photo gallery. Photo detail page needs to use a dark theme locally despite the light theme being used globally.

[jpudysz]

There is ongoing work to support it. Should land later this month on beta branch.

[jpudysz]

#401 👀

[jpudysz]

Unistyles 3.0 has been released, only one month after the initial estimation 😅.

Thank you all for your feedback and comments!

If you need to discuss anything please open separate thread 🙏🏼