Roadmap

[jpudysz]

Hello developers!

I'm nearing the release of the first Release Candidate (RC) for Unistyles 2.0. Here is the upcoming roadmap for future releases. In version 3.x, my primary focus will be on Web & Server-Side Rendering (SSR). Please feel free to share your ideas or request features 🦄

2.x (Core)

• Content size category link -> 2.0.0
• Support React Native macOS -> 2.0.0
• Explore handling booleans as variant values -> 2.1.0
• Alter theme after registration -> 2.2.0
• Support React Native Windows -> 2.3.0
• Add support for insets in UnistylesRuntime -> 2.4.0
• Add support for header metadata in UnistylesRuntime -> 2.4.0
• First class mock for UnistylesRuntime and Registry -> 2.5.0
• Support Bridgeless mode, RN 0.74 -> 2.5.0
• Manage status and navigation bar on Android -> 2.6.0
• Support tvOS -> 2.6.0
• Support visionOS -> 2.7.0
• TBA - more native APIs

3.x (Web + SSR)

• New arch only 0.75
• Explore option to move styleshsheets to C++
• Use C++ core with WebAssembly for Web?
• Static styles for SSR
• Unused styles eslint rule
• Headless mode Android -> read values directly from source rather than based on initial values
• Style caching - detecting if user is using same stylesheet to render eg. 100 componets
• Unistyles compiler with CSS media queries, variables, atomic styles and replacement for RNW StyleSheet
• Add support for pseudo clases / hover
• Explore React Strict Dom
• Add suport for multi-window stylesheets (visionOS)
• Redesign events, remove event emitter, trigger events directly from C++
• Refactor platofrm specific code, explore platform specific builders to reduce the setup
• Babel plugin for ommiting useStyles hook, could be done with signals
• TBA

[stevoland]

Amazing work, the first good RN styling lib imo. Something to consider: a codemod for apps using StyleSheet.create, ideally configurable for those referencing a theme statically.

[jpudysz]

Hey 👋 thanks!

Can you elaborate more on your proposal? I didn't get exactly what would you like to achieve

[stevoland]

Sorry, I wasn't clear. Imagine a large codebase using StyleSheet.create which is themeable at build time. It would theoretically be possible to automate the migration to runtime theming with a codemod, ie from:

import { StyleSheet, View } from 'react-native'
import { theme } from '~/theme'

export const Component = (props) => <View {...props} style={styles.component} />

const styles = StyleSheet.create({
  component: {
    backgroundColor: theme.background
  }
})

to

import { View } from 'react-native'
import { createStyleSheet, useStyles } from 'react-native-unistyles'

export const Component = (props) => {
    const { styles } = useStyles(stylesheet)

    return (
      <View {...props} style={styles.component} />
    )
}

const stylesheet = createStyleSheet(theme => ({
  component: {
    backgroundColor: theme.background
  }
}))

(Although it might just be me that would be interested 😄 )

[jpudysz]

Yeah, sounds like project specific scenario 😇. Would be hard to make it universal

[gabimoncha]

Adding support for other platforms and supporting Bridgeless mode should be a priority to make this lib the first one that comes to mind when choosing the stack and also be future proof.

[jpudysz]

Remember that bridgeless is not equal to fabric. Unistyles already supports Fabric and new architecture. I will add bridgeless support soon

[Nodonisko]

Bridgeless would be nice, although not a top priority now.

[xerxiastudios]

I created a repo with supabase auth. Unistyles-supabase-expo-starter. Working with unistyles feels much faster any other library. Few small features which I had to manually add but are always required in creating almost every app are

1. Add tailwindcolors as const. (https://tailwindcolor.com/)
2. Add size tokens for easy faster dev.
3. Default Themes, where we just replace tailwind-colors, and the whole app changes.

For reference check, themes.ts and sizes.ts in the above repo.

Thanks for the wonderfull work.

Question: I also created a custom Text component so that I don't have to pass styles to Text everytime. Will that decrease performance because there can be 100s of text lines in a screen, since it has to initialise useStyles everytime?

[jpudysz]

Thanks for the feedback and congratulations on the launch! 🚀👏

Regarding missing pieces:

• For Tailwind colors, I’m not using them. I almost always receive a Figma file from the graphic designer with a color palette. I don’t want to default any colors. It’s your choice what you pick for your theme

• Size tokens represents opinionated way of styling. It’s up to the theme author to introduce them or not. Unistyles has no concept of tokens, but you were able to implement it, so that’s good, it’s not encapsulated

• Again, this is the same opinionated way of styling with Tailwind. I’m not using Tailwind for my mobile apps, as mentioned in step one. I don’t want to impose any rules! That’s why any JavaScript object can be a theme

Regarding your questions about performance:

That’s the correct way of handling low-level components with Unistyles. Parsing time is around 0.01 ms per stylesheet, you won’t notice it even with 1000 components. Don’t worry about performance until your app starts to lag. I have never been able to see any lags due to Unistyles, even in large projects. 🙏

[xerxiastudios]

Thanks for the clarity. Looking forward for web compiler and more performance gains. 🙏

[mateuszmazurek]

+1 for React Native for Windows, I'm going to use this lib in my new project but need to be sure that Windows will be supported in the future

[jpudysz]

Hey 👋 which platform do you miss the most?

[Nodonisko]

Only Windows right now, but I am just brainstorming ideas to make stuff more future proof when possibly next platforms come to RN etc. so don't take me much seriously :D

[jpudysz]

How badly you want it?
I plan to add support somewhere in the February, but I need to find some spare time.

I need to get a windows as I'm a mac user 🫣

Without UnistylesRuntime and Bridge there is no way that Unistyles will work. The fallback is version 1.0 😁

[Nodonisko]

It's very low prio for me, just for hobby purposes and some experiments. For some reason I wish bridgeless mode :D

[jpudysz]

I see ☺️ then I will no rush. Nevertheless expect support in following weeks

[Online13]

Is there a solution for Unistyles being "Dev client only" on Expo and not supporting Expo Go?
Any plans to make Unistyles compatible with Expo Go in the future?

I'm eager to contribute to this library, but my expertise is primarily in JavaScript as a full-stack developer. I'm keen on learning the native part but unsure where to start, as it's a new domain for me. Any advice on how I can begin this journey?

[jpudysz]

Yes, it's not supporting Expo Go, because it's using custom native code. Expo Go is just a playground. If you're a JavaScript developer then it's still fine to use Unistyles. You just need to run dev client which is a single command that you can find in expo docs.

There is no plan to support Expo Go, because it's not longer possible.

If you want to contribute then most likely some C++/native knowledge is required.

Where to start? There is no simple answer. Start with React Native docs and analyze some OS projects.

[Online13]

Thank you for clarifying. I'll look into running the dev client as suggested in the Expo docs.

I do have a background in C++, but when it comes to the React Native part, are there any books or sources where I can learn to create native modules as you do in C++?

[jpudysz]

There is no place where you can learn everything, but you can start from RN Docs + RN JSI examples on Github. Later you can analize repositories like Unistyles and MMKV.

[rikur]

@Online13 check out https://www.youtube.com/@ospfranco/videos

[alireza-shakewell]

It would be very cool to have a linter that highlights the unused styles just like normal stylesheet.

[jpudysz]

It’s already in the roadmap (2.6)

[alireza-shakewell]

Oops. Didn't find it then. That's awesome 🌟

[jpudysz]

No worries :D

[GorbunovV]

Hello. First of all, thank you very much for the wonderful library. I would like to propose an idea to add all the functionality for working with screen orientation (handle change orientation, lock/unlock screen orientation, etc.). The available libraries leave much to be desired.

[jpudysz]

Thank you 🙏

To be honest I was also thinking about it. It's on my second todo list with ideas. I think that you can expect that in the future!

[joarkosberg]

Thanks for this awesome library 😊
Wondering, in the UnistylesRuntime, screen is available to read today, to use its width/height.
Is it any plan to also provide window sizes here? Or if window sizes will primarily be used for the breakpoints/media queries.

I have some use cases of having styles based directly on the window size, where it would be awesome to have it exposed in the stylesheet. For example handling font sizes with a clamp() like function from css, based on window size.

[jpudysz]

Thanks!
Screen is actually a window ;)

[joarkosberg]

Aha, thanks. I was testing initially with mac app (for ipad). Where it just read my screen width. See it is correct on other targets 😊

[jpudysz]

I mean for iPhone/iPad it will be a screen, but for web/macOS/windows - window.
With the visionOS support I will need to refactor it a little bit, as it may be confusing

[peterjskaltsis]

Love the simplicity of this lib! Thank you for taking the time to build a close-to-native solution for theming.

I've been experimenting with building out a component library on top of Unistyles and its been great. But I wish we had first-class support for Compound Variants.

I wonder if we're open to adding support for a syntax a bit like cva's? This would make it much easier to build components on top of Unistyles IMO: https://cva.style/docs/getting-started/variants#compound-variants

[jpudysz]

Cva like syntax but in v3.0.

Why? Because another loop will slow Unistyles a little bit. I really need to move variants and compound variants to C++ to make them instant. I'm planning new architecture and it looks like I can achieve cva like API with no performance penalty straight via JSI.

I know that more and more people needs it. I'm willing to support it soon 🙏

[peterjskaltsis]

Amazing to hear!

The performance hit from (compound) variants definitely builds up.

I think they are quite a key feature for building solid component libs, let us know if we can support in any way. Are you aiming for a rough timeline for v3?

[jpudysz]

There is no timeline at this point. Maybe summer 2024, idk

[chrisbianca]

Firstly, thanks for the great library, and the stream of continual improvements that keep simplifying the styling and theming of my apps!

Have you considered exposing the state of the keyboard as part of the runtime object? I've always found that the standard KeyboardAvoidingView never behaves quite how I'd like it to, so often build components that react to the visibility of the keyboard. Having the visibility and height of the keyboard available in the runtime object would make this much easier than having to listen for the height in the component and pass this into a style method.

Currently, I use the following on iOS to get the keyboard height:

export const useKeyboardHeight = () => {
  const [height, setHeight] = useState(0);

  const onKeyboardDidShow = useCallback(
    (e: KeyboardEvent) => {
      setHeight(e.endCoordinates.height);
    },
    [setHeight],
  );
  const onKeyboardWillHide = useCallback(() => {
    setHeight(0);
  }, [setHeight]);

  useEffect(() => {
    if (Platform.OS === 'ios') {
      // Use `didShow` to make sure the resize happens after the keyboard displays
      // to remove a flash of the screen resizing
      const keyboardDidShowListener = Keyboard.addListener(
        'keyboardDidShow',
        onKeyboardDidShow,
      );
      // Use `willHide` to make sure the resize happens before the keyboard hides
      // to remove a flash of the screen resizing
      const keyboardWillHideListener = Keyboard.addListener(
        'keyboardWillHide',
        onKeyboardWillHide,
      );
      return () => {
        keyboardWillHideListener.remove();
        keyboardDidShowListener.remove();
      };
    }
  });

  return height;
};

[chrisbianca]

@jpudysz thanks for the recommendations, I'll take a look and let you know if I think there are any gaps that Unistyles may be able to help with 👍

[rikur]

kirillzyusko/react-native-keyboard-controller is great, but there might be some perf issues on Android with heavy use (multiple KeyboardAvoidingScollViews rendered at the same time). I plan to create an issue there later.

[jpudysz]

I didn't know that!

[rikur]

@jpudysz Turns out it wasn't kirillzyusko/react-native-keyboard-controller that was slow.. It was FlatList inverted property in Android that causes significant perf degradation.

[jpudysz]

😬 You're using it for chat? Maybe rewrite it to FlashList

[AlexandrosMelissas]

Is anyone using this in production? Are there many breaking changes coming in the future?

[efstathiosntonas]

hey Alex, been using it almost after it was published, everything is running smoothly.

κανενα προβλημα 😀

[AlexandrosMelissas]

Thanks for your quick response! Awesome lib btw.

[omahili]

Looking forward to static styles for SSR in v3.

Great library and excellent job in maintaining it and bringing new features! 👏

[jpudysz]

Closing this thread as there is a new one for version 3.0!
Thanks to everyone for participating!