feature support in tailwindcss 3.0

[chinieer]

tailwind 3 provides more classes like color etc,how to update tailwind-react-native-classnames to support v3,thank you!

[brainlet-ali]

+1

[jaredh159]

thanks for the issue, I'm excited about v3 as well. the stated goal of this library is just to provide support for the tailwindcss utilities that directly map to a support RN style prop.

therefore, what we need to do is figure out which of the new v3 features fall into that category -- i.e., they fill in a gap by mapping directly to a RN native style prop. assuming there are some of those, i'd definitely be up for working on an implementation fairly soon.

do either of you (@chinieer or @brainlet-ali) have any desire to compile that list?

[jakobo]

I did a first pass.

☑ supported | ⚗ possible support | ⛔ can not support

Major Feature List

• ☑ Extended colors (no change required beyond updating the Tailwind library)
• ⚗️ motion-reduce: - Can be supported since the motion preference is in the AccessibilityInfo API
• ⚗ Colored box shadows - React Native box shadows do not follow the CSS specification, but the syntax of shadow-lg shadow-cyan-500/50 is certainly doable since we already have the logic to support shadows in v2
• ⛔ Scroll Snap - This cannot be achieved with React Native's StyleSheet
• ⛔ Multi Column Layout - React Native does not have a way to do flowing columns
• ❓ Form Control Styles - React Native only has a TextInput control, making things like the checkbox accent styles not very applicable.
• ⛔ print: prefix - There's no way to realistically turn this on or off. You probably want to use a library like react-native-print for better print control than RN's StyleSheet object provides
• ⚗Aspect Ratio - This can be mapped to width/height assuming one of the values is provided, falling back to the dimensions of the screen. Otherwise, a ratio like aspect-[4/3] would by default do a 4/3 aspect ratio of w-full h-3/4 which I don't think comes out correctly.
• ⚗ Underline Styles - We can... kinda use these. Except wavy. ref. Underline style and color are iOS-only properties and are ignored on Android.
• ⚗RTL/LTR - In theory could be supported. You would enable RTL with allowRTL() in your AppDelegate.m and MainActivity.java files. When that is enabled, we can then support rtl: and ltr: prefixes via I18nManager.isRTL
• ⛔ Arbitrary Properties - This would probably end poorly. You can already assign whatever styles you'd like to the style prop and in exchange, React Native gets really angry.

Upgrade Guide Challenges / Tasks

• ⚗ purge becomes content ref - We're not using this right now AFAIK, but this was a backward incompatible change in the tailwind config
• ☑ Dark Mode Variant - Already handled by twrnc
• ☑ All Variants - Already handled by twrnc's jit support
• ⚗ Transform/Filter automation - May need to update mapping if currently supported in twrnc 2
• ⚗ Color changes ref - Needs to be in twrnc's upgrade guide
• ⚗ Name changes ref - Mapping update required
  • overflow-clip is now text-clip
  • overflow-elipsis is now text-elipsis
  • grow-* and shrink-* will alias to their flex values
  • outline-* wasn't previously supported, shouldn't impact twrnc
  • decoration-* wasn't previous supported, shouldn't impact twrnc
• No - as custom separator for class names
• Class prefix selector is now a string, not a function
• file:hover: n/a as we don't support file:
• fill- and stroke- if you want to support currentColor, you need it defined in your theme

The biggest motivator to add v3 support is the colors/variants/etc are all enabled by default. Otherwise, about the only thing we're really missing is the improved box shadow class names AFAIK.

Some "how to solve" came from checking what was supported in tailwind-rn since Vadim also recently updated to add v3 support to the non-JIT version.

[jaredh159]

@jakobo really appreciate the time you took to draw this list up. and, it's encouraging, because like you said, most of the work here is relatively fringe, we already support almost everything the average RN user would want from v3.

v2 already supports aspect ratio (though I'd need to double-check that the utility naming is consistent).

[jakobo]

Are we okay with throwing a warning for the new (but unsupported) classes and prefixes? If so we could go from v2 to v3 first, and then incrementally add missing features/prefixes.

[jaredh159]

you know, i never really commited to tracking semver versions with tailwindcss. we just happen to be on v2 right now, because it was a major re-write with breaking changes from the previous twrnc v1. but both v1 and v2 of this library were geared towards tailwindcss v2.

i don't think matching tailwind major versions probably makes sense, because, one could ask, why not track RN versions instead? i think we just should keep to our own semver, is my thought. if we really want to introduce a breaking change, we bump the major version. if we can accommodate v3 without breaking changes, then we stay on 2.x. does that seem right?

[jakobo]

I agree, we should be on our own semver. I just felt it was worth pointing out that moving to Tailwind v3 will be a breaking change since there are backwards-incompatible changes to things that affect end users such as class name designations & the config file, putting us (independently) on 3.0.0. We could then as we add features for parity & do minor releases (3.x.0) until we're happy with the feature support. The roadmap would look something like

• twrnc 3.0.0 - the goal of twrnc3 is to keep the changeset small so people can absorb the back-compat changes first
  • Uses new Tailwind v3 configuration file (removes purge, dark, variants)
  • Requires users to follow the Tailwind 3 migration guide for existing supported features https://tailwindcss.com/docs/upgrade-guide (auto-transforms for brightness/scale, color palette changes)
  • Tests updated to track against tailwind 3's class name generation / output
  • Update supported-utilities.md to reflect v3 support
• twrnc 3.1.0 (the one w/ new prefixes)
  • reduced motion support prefix
  • rtl/ltr prefix support
  • colored box shadows
  • underline styles

[jaredh159]

yeah, that make sense, thanks. if supporting v3 causes us to make breaking changes, then obviously we need to go to 3.x as well.

so, i was skimming the upgrade guide, and I'm having a hard time finding how we're affected at all. The tailwind.config.js changes don't cause breaks for us. at least, I can't think how they would break anything, am I missing something? We don't leverage purge, dark, or variants, and the overall shape of the config remains the same.

the only thing i could see causing a breaking change would be the renaming of classes, but I'm not sure that any of the ones that changed are supported by twrnc. Am i wrong about that?

I do like the idea of slowly layering on some of the new features, like reduced motion support, rtl/ltr, etc. maybe even opening issues for each one to help gauge interest. some of them seem like there may not be very many people really wanting to use them, so we could judge the cost of implementation against a sense of how many people actually care about the feature.

[jakobo]

Only breaking changes I found were colors related.

---

Colors:

1. You didn't have a custom tailwind.config.js and
2. You were using a generic color such as text-green-*

Then your green color will change to the extended palette green (previously mapped to emerald).

---

Grays:

1. You are using any of the gray scales by name

Then your names changed. For example blueGrey is now slate

[Natetronn]

I was looking into TWRNC for the first time and my first thought was to check for v3 compatibility before I gave it a spin.

Anyway, just wanted to say, thanks for working on this!

[soundsystems]

would be dope if tailwindcss team helped contribute to developing this

[jaredh159]

Ok, so I thought about this some more, and I think we can essentially declare ourselves compatible with v3 -- because:

• we don't leverage any of the tailwind config properties that were changed
• we don't support any of the few class names that were changed (they're not supported in RN)
• we already had full arbitrary jit-style class generation for v2
• the new features (like rtl:) don't squarely land in the scope of this project, which is to support tailwindcss utilites that directly map to RN style props -- we can always add support for these features if we decide to, but i don't think they should stop us from acknowledging that we are v3 compatible.

That said, we do have a dev dependency of tailwindcss, and I think it's wise to go ahead and as @jakobo proposed, bump our major version when we bump that dependency to 3.x. Then, we can go from there, layering on new features as necessary.

To that end, I've whipped up a PR on a feature branch, and beta release, if anyone wants to try it out before I merge and cut a release. I've tested it with local RN app, and it passes the whole test suite just fine. It would be nice if a couple other folks could test it as well, but I don't see any major concern with releasing this fairly soon. If you want to try, just run npm install twrnc@next to get the beta version.

Thanks for all the input!

[jakobo]

Gave it a spin. Since everything I have already was (mostly) working it wasn't tough to test out. We will want to have a v2=>v3 upgrade guide with the following items.

Color renames. In line with the upgrade guide, tailwind v3 has mapped green, yellow, and purple to their extended colors. Additionally, gray colors were renamed in the extended colors to be more specific. Both of these can be resolved by following tailwind's upgrade guide and optionally re-aliasing the colors in your tailwind.config.js.

New v3 prefixes and classes are being added as we identify use cases; each feature needs to be checked against React Native's capabilities before we can undertake it. If you do have a feature that would help your development, please open an issue and include any libraries / hooks that could help someone in the community put a PR together.

Other than the colors and being explicit about new items added on a "as needed" basis, LGTM! 🚀

[jaredh159]

just released v3.0.0. We'll open other issues for layering on new features, as requested, so I'm going to close this one. Thanks to all for the input.