-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
React native support #596
Comments
Hi 👋🏻 I've been working on the RN version of Stitches here: https://github.com/Temzasse/stitches-native The core functionality is pretty much ready but I'm quite badly stuck with the TS typings. Any help with the typings would be very much welcome! 👐🏻 @peduarte do you have any tips about how could I utilize the existing types of Stitches in the RN version? I see that you have gone the declaration route instead of adding types to the implementation itself. I've been trying to type the implementation in my version and it gets super tricky 😄 Would you be open to sharing the learnings of your TS journey with Stitches? |
@Temzasse hi! Nice 💯
We're currently working on a TS specific sprint. Expect lots of TS changed over the next few weeks. Right now, I cant recommend anything, because its likely everything will change. When we release the new TypeScript work, I'll post an update here! |
FYI: I believe this is the TS PR Pedro referred to: #659 👀 |
Uuuh nice! 👍🏻 I'll take a look 👀 I actually managed to get the TypeScript part working with the current typings from Stitches repo by copy-pasting them into my repo and modifying the types to work with React Native. I still need to write some docs for React Native specific stuff and test the lib more (and maybe write some actual tests 🙈) and then I would be ready to publish the first version of |
The TS sprint was a success and we have since launched v1.0.0. Does this work for |
Hey @jonathantneal - do you have any near plans to support react-native as part of modulz directly? |
@jonathantneal I haven't had the time to incorporate the updated typings from v1 yet but I'll try to get it done as soon as possible. There are a few other smaller things that also need to be implemented in Maybe we can keep this issue open until the first proper release of |
@Temzasse one issue I see with the implementation is that it doesn't use dynamic window dimensions for media queries. Since RN doesn't have native breakpoints, this would be required via a hook. It's what we use for Dripsy. As a result, changing screen size won't update styles. Have you considered a way around this? |
Stitches Native TS update@jonathantneal I got the new Stitches v1 types working in Stitches Native apart from one issue in RN specific There is a new pre-release version that people can try out: Next stepsI still need to comb through the Stitches API and verify that I'm not missing anything important in Stitches Native. One thing that I know is still missing is the composability of const sharedCssA = css({ /* styles */ });
const sharedCssB = css({ /* styles */ });
const CompA = styled('View', sharedCssA, sharedCssB);
const CompB = styled('View', CompA); Stitches Native currently only supports the simple version of composing const CompA = styled('View', { /* styles */ });
const CompB = styled(CompA, { /* styles */ }); Not sure if it's enough that you are able to spread as many const cssA = css({
backgroundColor: '$background',
});
const cssB = css({
alignItems: 'center',
justifyContent: 'center',
});
const Comp = styled('View', {
flex: 1,
...cssA,
...cssB,
}); I guess the drawback is that you can't really use |
@nandorojo could you open an issue about this in the Stitches Native repo so that we could discuss this topic there? 🙂
|
I’m unsure if we should leave this open, direct the discussion to stitches-native, or seek to merge stitches-native into our repository. I’d like to hear your ideas, @Temzasse, before knowing what action to take here. |
@Temzasse will do. One other suggestion is not not allow the |
My 2 cents: if the core Stitches team is willing to merge Can't wait to try Stitches with RN, either way! Thanks @Temzasse ! |
Yes! I think it's a good idea to merge. Thank you for considering it! |
I'm definitely open to any of the above 👍🏻 @LucasUnplugged had a good point that merging stitches-native to the main Stitches repo would help reduce some of the maintenance burden from me, and in the future it would be easier to have both Stitches for Web and Stitches for React Native evolve hand in hand without too much divergence. However, I'm also happy keeping stitches-native as a separate project and you can direct any discussion to stitches-native repo. In any case It would be cool to get more contributors aboard in order to make it a more community driven effort 🙂 Here are some pros and cons for the merging idea that came to my mind: Pros:
Cons:
|
Stitches Native update
The way forward@jonathantneal have you and the rest of the team had the opportunity to think about the idea of merging Stitches Native into the Stitches repo? I feel like Stitches Native is now ready for wider usage. There are still things to do like writing tests (🙈) and refining the docs but the core functionalities should be pretty much in place (unless I have missed something). One challenge that I have is that I'm not currently able to dog food Stitches Native at my company or in side project so it's difficult to make sure that there are no unhandled edge cases. I'm considering publishing |
Interesting thread, I'm building a web components library for my company using Stitches but we also have a React Native app and today I was facing the question: will I be able somehow to reuse the styles for React Native? @Temzasse I think you should publish the library as |
As mentioned I started testing it and I found a few issues with types that I'm reporting here: Temzasse/stitches-native#20 For visibility in case Modulz team wants to help solve them 🙏 |
After a couple of hours working with Anyway here is what I think as of today:
These 2 points should be fixable but it's not an easy task and it would require a lot of tests. Now, the most problematic issue: React Native doesn't support nesting/selectors so it makes it really hard or impossible to build components using the composability that Stitches offers (nested Stitches component selectors for example) You can see it already by trying to build a simple https://github.com/Temzasse/stitches-native/blob/main/example/src/Example.tsx#L140-L226 In conclusion, I think Stitches is great because of the extensive work they have done around the library to make it work perfectly with the web platform and the React workflow for a developer. |
If it helps, I ran into this types issue with Dripsy (which is based on Theme UI), and I fixed it on v3. I basically use the RN type only, unless you specify otherwise in your theme, which indicates that you have a value in your theme that would override it. |
OT: @nandorojo I didn't know your library, looks interesting I'll check it out 😄 thank you |
@mtt87 Thank you for your feedback 🙏 Here's my response to the various topics: TypeScript
Nesting/selectors
In a perfect world there would be an universal styling library that would map 1-1 between Web and Native but I think that is not practically feasible due to the inherent differences between the platforms. I totally understand that when creating design systems / component libraries it would be nice to share as much as possible but I feel like the sharing part should mostly happen at the design token level. Implementing shareable components will probably lead to an implementation that is not optimized for either platform. Sorry if this sounds harsh - I just wanted to share my philosophy about this subject 😅 |
Thanks for your reply, and don't worry it didn't sound harsh at all 😄 I'll think about if there are ways to improve the compound variants but I suspect there aren't 😭 I'll have a look at the source code to see if I can help with the types perhaps although I'm not a TS expert I'd say 😄 |
I like the discussion here. Here’s my take: we should embrace the way that React Native works, rather than fit it to be like CSS. Nested selectors and pseudo elements give you convenience, but don’t scale well for a component-based design system. I think it’s actually a good limitation of React Native to not have these. I recommend this talk from the creator of React Native for Web, it really solidified that perspective for me: https://youtu.be/tFFn39lLO-U I’ll also be talking about this topic at Next.js Conf in a few days: https://nextjs.org/conf/speakers/fernando
I agree, but the baseline for these styles should be React Native’s styling system, not CSS. If that’s the case, then we can in fact get the 1-1 mapping. React Native’s styling system lends itself to work well on web. CSS, on the other hand, is too low level and coupled to HTML to be used on other platforms. I’m not sure what the right answer is in the case of porting Stitches and its variants, but I think we can take the best of stitches, and still lean into React Native (+ Web)’s styling philosophy. I came to this conclusion after using Dripsy in production for beatgig.com for about a year, where my original goal was also to copy all the CSS options from theme UI. I hope that makes sense. |
I share your same feeling here
I love this talk from Nicolas, watched many times 😄
Sounds great I didn't know, looking forward to watch you and @peduarte talk!
Agree I think the "design token first" approach of stitches and the DX around it provided by perfectly crafted Typescript types is super valuable. Perhaps @Temzasse should consider making
One observation here: I loved rebass / styled-system / theme-ui in the past but I find the array syntax to be more error prone compared to the breakpoints you declare in stitches |
@jonathantneal can I ask a TypeScript related question? 🙂 It's related to the feedback from @mtt87 and the notion of narrowing types like Is it possible to restrict certain CSS properties to only accept either a string that starts with By looking at the types in {
[K in keyof CSSProperties]?:
| ValueByPropertyName<K>
| TokenByPropertyName<K, Theme, ThemeMap>
| ThemeUtil.ScaleValue
| Util.Index // <------------------------
| undefined
} leads to any number being a valid value eg. when doing: const Comp = styled('Text', {
fontWeight: 700,
}); I'm not sure I understand the need for By removing Addiotionally, removing const Comp = styled('View', {
alignItems: 'not-valid',
}); So I guess the main question is this: is there a way to make these types more strict without losing the nice autocomplete feature for tokens? Unlike on the Web an invalid CSS value can cause a hard crash in React Native so it would be very helpful if we were able to protect the users of Stitches Native from these kind of errors when using TypeScript. Thanks in advance! |
I didn't look at the codebase but all these styling properties are already correctly typed |
Hmm I might have figure this out myself 😄 If I remove type FontWeightProperty =
| 'normal'
| 'bold'
| '100'
| '200'
| '300'
| '400'
| '500'
| '600'
| '700'
| '800'
| '900'
| (string & {}); // <-------- remove this then it's possible to narrow down the types to only acceptable value from React Native's perspective. Now I'm only wondering what are the side effects of this change 🤔 All three main use cases seem to work fine:
const Comp = styled('Text', {
fontWeight: '700',
});
const Comp = styled('Text', {
fontWeight: '$bold',
});
const Comp = styled('Text', {
fontWeight: theme.fontWeights.bold,
}); @jonathantneal is there something that I'm missing? |
@mtt87 I have released a new canary version ( If you (and other people too) could test the new version I would appreciate that a lot 😊 One thing that I did not change yet but was thinking about is the type of the theme definition. Currently it looks something like this: export type Theme<T = {}> = {
borderStyles?: { [token in number | string]: boolean | number | string };
borderWidths?: { [token in number | string]: boolean | number | string };
colors?: { [token in number | string]: boolean | number | string };
fonts?: { [token in number | string]: boolean | number | string };
fontSizes?: { [token in number | string]: boolean | number | string };
fontWeights?: { [token in number | string]: boolean | number | string };
letterSpacings?: { [token in number | string]: boolean | number | string };
lineHeights?: { [token in number | string]: boolean | number | string };
radii?: { [token in number | string]: boolean | number | string };
sizes?: { [token in number | string]: boolean | number | string };
space?: { [token in number | string]: boolean | number | string };
zIndices?: { [token in number | string]: boolean | number | string };
} I'm wondering if we should narrow the types here too for Currently you can do this (which is invalid): const { styled } = createStitches({
theme: {
fontWeights: {
bold: 700,
}
}
});
const Comp = styled('Text', {
fontWeight: '$bold',
}); Again I'm not quite sure if there are some side effects for this change 😅 |
@Temzasse is In theory using the |
Re: TS The CSS Re: TS The CSS Re: Narrowing If React Native is so far behind the abilities of CSS, that’s unfortunate. It may also be inevitable if React "Native" is not truly CSS. I would expect these platforms to continue to evolve separately. It seems like attempting to bridge browsers and 'native' by their weakest link requires rethinking what 'styles' are in a very narrow way. (The closest similar leap I can think of would be supporting IE6, which did not support chaining. It sounds very miserable / profitable.) |
Yes, Dripsy uses StyleSheet.create. Dripsy also efficiently deep compares your Keep in mind that StyleSheet.create is a web-only optimization. On native, it actually is a function that returns its argument and provides TS convenience. |
I'm aware on the web (React Native Web) using the According to the docs and other answers I found online, the https://reactnative.dev/docs/stylesheet#flatten
Maybe it's not noticeable in very small simple apps but it might be in more complex apps |
|
Oh wow interesting! This is confusing online there are different places including the documentation that don't seem to be very clear about this but the code is the ultimate source of truth. Thanks! |
@peduarte any official update from the dev team on this ? |
Hey everyone 👋 |
@hadihallak here's the PR 😉 |
I really love what you guys have been doing with stitches and have been loving it so far!
Any idea if react native is in the roadmap, I think the community would benefit a lot from this
The text was updated successfully, but these errors were encountered: