Support for web utilities

[finkef]

Since this package works with react-native-web (although not officially supported I think), I was wondering if there is any interest in also adding web-only tw utilities like "cursor-pointer". When building for the web, natively supported RN styles gets us 90% of the way there, but showing a pointer cursor for buttons is a must.

My specific use case is that I want to support web utilities in react-native-tailwind.macro since it's trying to allow fully universal tailwind styles on both mobile and web.
I think the best option is adding support for those utilities in this repo by adding the missing resolvers. Alternatively, I could add them through this lib's plugins downstream in react-native-tailwind.macro, but I think many more users could benefit off of them when implemented here.

What do you think, @jaredh159?

[jaredh159]

I'm not 100% how I feel about this. Personally, I don't use RN web at all, so I don't feel particularly motivated to take on the maintenance of all the additional surface area represented by a decision to support all of the web utilities. I also have a concern about bloating the code and slowing down the parsing logic, for RN native, performance is really critical. That said, I know a lot of folks really like RN web, and are using this library with some success in that context.

I have sometimes thought that maybe at some point I might reorganize the lib to have a @twrnc/core module, and then maybe RN-web users could opt into another library like @trwrnc/web which adds the web stuff as an opt-in additional layer. But I don't really have the time or motivation to tackle that currently.

I wonder if a possible compromise would be to outline a handful or few dozen of the most core utilities that would go a long way towards making RN-web users not need to add a bunch of custom utilities. Stuff like cursor-pointer. Do you have a list of utilities that seem really critical? If so, how big would it be? If it were just a handful or a few dozen, maybe we could integrate them into the existing lib as is, and mark them for possible separation out into another module later. That could buy some time at least. Those are my thoughts, I guess.

[walidvb]

I've just added tailwindcss to my expo app to get the web classes as well. This had me change some Views to div, which isn't a real problem, considering I'd only want these we-specific utility styles to be run on web platforms anyways.
That's a small added level of complexity in the setup, but tbh not so much in the code. Maybe it can be added in the readme

One utility that i'm missing the most are the grid box model, for sure – super handy on web to create layouts, and (imo) a pain to achieve in React-Native.

PS: I haven't tried compiling the code into an app yet, and i'm currently not managing to compile media-query styles on production, but need to take a deeper look at vercel/next.js#14595 – so this is unrelated

[teovillanueva]

Hey @finkef, i've been working on a wrapper for twrnc. The library provides with support for RNW + SSR. Its done with some post-css magic and the wrapper. Im also trying to provide support for focus and active selectors both on web and mobile. The API is still a little bit RAW and since the release of tailwind 3.0 the mobile version looks to be a little bit broken. @jaredh159 Im a fan of your project and I think that it has really good potential but RNW support looks to me like a key piece when using tailwind. I'd like to contribute to the project, but its up to you where you want to drive tailwind-react-native-classnames to.

[finkef]

Totally get your point, @jaredh159! How about creating a @twrnc/web that people can add as plugin to their tailwind.config.js to opt into web utilities while libs depending on twrnc can apply them under the hood? That way we can decouple the development from the core there. I'll try to compile a list of the major web-only utilities though.
In principle, I think I would only stick to the ones that don't clash with RN stuff, so that RN and Web always produce the same results even if one platform or the other has some extra platform-specific goodies like a cursor-pointer or elevation. I think implementing the grid utils or anything related to non-flexbox styles would complicate stuff and would give unexpected results to users when all of a sudden those don't work on native.

@teovillanueva Interesting project! I'm currently working on support for web selectors, like focus and active, but also SSR dark mode in react-native-tailwind.macro. Under the hood, it uses twrnc, but handles all the prefixes itself. Goal is to achieve feature parity with all of the supported prefixes while still maintaining the ability for SSR. Fixing one last thing related to dark mode, but should have a new release out this weekend.

[teovillanueva]

@finkef I like the idea of using a macro. Definitely makes using tailwind with RN cleaner. The thing is, the approach of using twrnc in web does not look like a great idea to me. I think the web should be using classnames but since it isn't supported by RNW i came up with the postcss plugin that translates the native tailwind selectors into data attributes selectors which are supported by RNW. Can i ask if you @finkef and @jaredh159 are willing to create a unified source for this? I think we are all trying to achieve the same thing which is a common api for using tailwindcss in react-native in the same way we use it in web. I started to create a spec for using tailwindcss in RN/RNW

[finkef]

I see the macro simply as layer on top of twrnc, trying to enhance the ergonomics especially across platforms and for targeting Next.js and SSR with CSS media queries. I think twrnc has a super nice and clean API that already solves plenty of use cases without complicating the usage, whereas using the macro comes with some considerations and things to keep in mind towards the media queries. Also, for the macro all styles need to be static whereas I think twrnc could support stuff like tw`w-[${width}px]` (@jaredh159 Correct me if I'm wrong 😅)

I see the value in merging the projects, but I think it would complicate things a lot for people using just RN on native platforms that benefit from a much more flexible API from twrnc.

[teovillanueva]

@finkef you are right, i was thinking maybe instead of "merging" the projects to create like a set of tools that are completely independent one from another. Mainly because there are lots of projects trying to achieve the same thing in different ways and there is no project that has the solution to all problems.

[rborn]

@jaredh159 I'd like to get this to your attention again 😅.

I believe in the next few months we'll see a more and more usage of RN and RNW to create universal apps.
( this thread started to get speed - react-native-community/discussions-and-proposals#496, the new expo-router will soon ready for primetime https://github.com/expo/router)

Not sure how to approach this, with an extra layer (macro) or in the repo, but I think supporting web should be in the roadmap 🤗

[jaredh159]

ok, thanks for letting me know.

i understand the motivation, and you may be right that it could be time to expand twrnc to support web utilities in some fashion. i'll try to think it over a bit. i'm not doing any active RN development at the moment, my apps that use it are in maintenance mode right now. but i may revisit them in the future, and that might spur me on to work some more on this library. or perhaps maybe i could let a few contributors spearhead the effort.