(DRAFT) RFC v4

[JamesHemery]

Hello!

I'm happy to suggest an RFC for a major release of twrnc in order to provide solutions to regularly encountered problems.

To make sure I'm aligned with the library's philosophy: Keep it simple, bring tailwindcss to React Native without any modifications at build time.

⚠️ @jaredh159 This is a first draft for your feedback and brainstorming :)

1. Style API

Issue

As mentioned in several issues (#247, #234, #112, ...), there are many re-rendering problems when the device context changes. The problem can be easily summarized: twrnc has no ability to force a component to re-render when the device context (ak. styling context) changes.

Currently, useDeviceContext() on the App component (or expo-router _layout) isn't enough, as it doesn't allow you to re-render memoised components. This is particularly annoying when you consider that expo-router automatically memoizes all screens.

🚧 Examples coming soon 🚧

Considered Solutions

Router key :

My first solution for expo routing was to add a key to the Navigator. But this was only a temporary solution for several reasons:

• It doesn't take into account other memoized components
• when the styling context changes, the navigation state is completely reset

🚧 Examples coming soon 🚧

Styled component / HOC :

Another solution explored was to create a styled or tailwind HOC, but this solution doesn't seem to correspond to the library's philosophy and is restrictive for the user: it requires to be added to all the components concerned, which can quickly be forgotten, and it's a lot to ask just to manage the re-render.

🚧 Examples coming soon 🚧

Final Suggestion

The final suggested solution is to modify the style API to deprecate the default use of the tailwind instance directly. The recommended method would be to retrieve the instance using the useTw or useTailwind hook.

There are several advantages to this one:

• We can now watch the styling context and re-render components when necessary
• The user no longer directly imports the tailwind instance, so it can be replaced on the fly (for a color mode for example)
• It's explicit and React standards friendly
• Supports nested theme

function Button({ label, style }: { label: string, style: ViewStyle }){
	const tw = useTw();

	return (
		<TouchableOpacity style={tw.style('px-4', style)}>
			<Text>{label}</Text>
		</TouchableOpacity>
	);
}

The hook is responsible for re-rendering the component when the styling context changes.

For this system to work properly, it would be ideal to add a TailwindProvider.

const tailwind = create(...);

function App(){
	return (
		<TailwindProvider instance={tailwind}>
			<Text>{label}</Text>
		</TailwindProvider>
	);
}

TailwindProvider will give the instance to the hook using a React Context. The provider is also responsible for watch the styling context.

🚧 Examples coming soon 🚧

How to use it outside of a component ?

Sometimes it may be necessary to use the method outside a react component, in which case using hooks is not possible.

const tailwind = create(...);

tailwind.style(
	'bg-red-500',
	{ ios: true, ... }
);

// same for other methods like color.

The second parameter is used to specify the stylinh context and is only required when the styling context is not synchronized by a provider, otherwise it is optional. If the styling context isn't sync and not given as second parameter, it will throw an error.

Maybe we need to introduce a specific keyword like tailwind.unsafe.style(); or something to indicate that it's not reactive.

A different theme for a particular styling context ?

It could be interesting to allow the use of different config depending on the styling context.

const lightConfig = create(...);
const darkConfig = lightConfig.merge(...);
const androidConfig = create(...);

const config = createSet((deviceContext) => {
	if (deviceContext.android) {
		return androidConfig;
	}

	if (deviceContext.colorScheme === 'dark') {
		return darkConfig;
	}

	return lightConfig;
});

function App(){
	return (
		<TailwindProvider instance={config}>
			<Text>{label}</Text>
		</TailwindProvider>
	);
}

// Same behavior, I can use config.style(classNames, stylinhContext) or config.color...

Nested config ?

This pattern allows us to have nested config (thanks to React Context).

const configA = create(...);
const configB = create(...);

function App(){
	return (
		<TailwindProvider instance={configA}>
			// Router
		</TailwindProvider>
	);
}

function Button(){
	const useTw();

	return ...;
}

function ScreenA(){
	return <Button/>;  // In this case Button useTw() receive configA instance
}

function ScreenB(){
	return (
		<TailwindProvider instance={configB}>
			<Button/> // In this case Button useTw() receive configB instance
		</TailwindProvider>
	);
}

🚧 Examples coming soon 🚧

2. Last utility win

Issue

See #245

Proposed solution

The idea is to reproduce a behavior similar to that known in CSS, just correcting the precedence problem.

In CSS, it's not the order of class usage in HTML that determines the style, but the order of CSS declaration.

<style>
  .square { height: 50px; width: 50px; }
  .red { background: red; }
  .blue { background: blue; }
</style>
<div class="square red blue"/> // Will be blue
<div class="square blue red"/> // Will be blue also because the .blue CSS class was created last

It's this way of working in CSS that is problematic on the web with tailwind, and that's why libraries like tailwind-merge exist.

Still in CSS, the more precise an instruction is, the more weight it has:

<style>
  .square { height: 50px; width: 50px; }
  .square.blue { background: blue; }
  .red { background: red; }
</style>

<div class="square red blue"/> // Will be blue because .square.blue is more precise

It's easy to say that with tailwind it's the number of modifiers that determines the weight:

// 👉 Asume we are on sm screen.

<div class="h-[50px] w-[50px] bg-purple-500 sm:bg-red-500"/> // Will be red becasue sm: has more weight than nothing.

// ℹ️ One specifity is that in CSS, state (hover, focus..) has little more weight for same precision

<div class="h-[50px] w-[50px] bg-purple-500 hover:bg-green-500 sm:bg-red-500"/> // Red by default, green on hover

<div class="h-[50px] w-[50px] bg-purple-500 hover:bg-green-500 sm:bg-red-500 sm:first:bg-orange-500"/> // Always orange because sm:first: has more weight than sm: or hover: single

We can determine a few rules:

• We don't have constraints of the CSS language, so we can apply the last-utility-win policy.
• Weight of a tailwind class is determined by its number of modifiers
• State modifiers (hover, focus..) take precedence over other classes with the same weight
• className must be sorted in order of weight, without modifying the order of classes of the same weight.
• We could consider implementing the important modifier (!)

So for example :

Input : ios:sm:bg-blue-500 hover:bg-orange-500 sm:bg-purple-500 bg-red-500 bg-green-500
Output : bg-red-500 bg-green-500 sm:bg-purple-500 hover:bg-orange-500 ios:sm:bg-blue-500

4. Pseudo-classes, pseudo-elements supports

State supports:

🤔 WIP draft implementation

function Button({ label, style }: { label: string, style: ViewStyle }){
	const tw = useTw();
	const handlers = tw.handlers({
		onPressIn: () => {
			// Any custom behavior
		}
	});

	return (
		<TouchableOpacity style={tw.style('px-4', style)} {...handlers}>
			<Text>{label}/>
		</TouchableOpacity>
	);
}

Group supports :

🤔 WIP draft implementation

List :

🤔 WIP draft implementation

function Service({ title }: { title: string }){
	const tw = useTw();

	return (
		<View style={tw`bg-slate-100 border-2 border-slate-500 first:border-blue-500`}>
			<Text>{title}</Text>
		</View>
	);
}

function Services(){
	const tw = useTw();

	return (
		<TailwindList as={View} style={tw`flex-row`}> // Basically a Fragment with Context.
			<Service title="Service 1"/>
			<Service title="Service 2"/>
			<Service title="Service 3"/>
		</TailwindList>
	);
}

No Peer Support.

🚧 Examples coming soon 🚧

5. Media and feature queries

More complete styling context !

🤔 WIP RFC (AccessibilityInfo, Platform, Orientation, Dimensions, ColorMode, Custom modifiers...)

6. Transform support

🤔 WIP RFC
🥳 React Native soon supports transform-origin facebook/react-native#38626

[JamesHemery]

@jaredh159 What do you think?

[jaredh159]

@JamesHemery sorry for the delay getting back to you on this. I truly appreciate the time you spent writing all of this up.

My high-level, meta thought on all of this is that I'm at a point right now with my main project (not a RN project) where I'm working against a bit of a deadline trying to build and release a pretty major feature, so I just don't have the time to prioritize twrnc at the moment. I forsee this period lasting about 3-4 weeks, at which point I think I may be able to carve out some time to give this library some attention. So that's the main reason I've been slow to respond. Basically, I'm busy working on other stuff - the ios/android apps I have in production using twrnc are in maintenance mode right now, so I'm not actively working on the library.

Descending to more particulars: I'm definitely interested in tackling the issue with re-renders and memoization. In my mind, that seems to be the biggest hurdle some people are having with the library. I appreciate the documentation of your attempts on this front. I've not experienced this problem directly myself, since my RN apps don't use Expo or anything that forces me into memoization, but I know a lot of people do. What I'd like to do is take some time to more deeply understand this issue, hopefully with a sample expo project I can poke at. I'd like to work through some of the options you discuss and see their drawbacks firsthand before I make a decision. I'd also like to see if any other possible solution presents itself. I'd like to do this exploration sometime in late October. If I end up agreeing with your assesment, it could easily represent something worth doing a major semver bump.

The other issues raised in this RFC I feel less strongly about. The last utility wins is something only you (I think) have reported -- I'm not sure this is something causing problems for most users. And I sort of think there might be an easy fix which wouldn't warrant a semver bump, just a patch or minor, depending on whether we considered it a bug. The other ideas you present are intriguing, but I've not heard from any other users requesting those features, so I'm a bit reluctant to increase the complexity of the API surface area if I'm not sure that a good percentage of users are interested in the new features. I don't think I've seen any issues raised concerning those ideas. That doesn't mean I'm 100% opposed to implementing some of them, just that they are sort of new ideas to me, and I'd have to weigh the time and complexity costs against the perceived benefit for the average user.

Hope all that makes sense, and again, truly appreciate your involvement and interest.