TVke/react-native-tailwindcss

Responsive styling

Opened this issue · 6 comments

davidgovea commented

The responsive styling experience of tailwindcss is great. Mobile-first, then sm:, md:, lg:, xl: prefixes for breakpoints.

When thinking about the function-helpers in for lineHeight in issue #48, I thought that maybe this could work for responsive helpers, too.

Imagine:

import { t, md, xl } from 'react-native-tailwindcss';

<View style={[t.w16, md(t.w24), xl(t.w32)]} />

Internally, the helpers would look something like:

const md = (styles) => Dimensions.get('window').width > 1000 ? styles : undefined

The question is -- would this "screen-width breakpoints" approach be helpful in react-native?
I've been watching some approaches to responsive styling, and I'm not quite sure yet.

So, any thoughts?
It could be reasonable to omit all of this from rn-tailwind, and rely on other utilities for this functionality.
On the other hand, this is a pretty central feature to tailwind (IMO).

After reviewing the above repos, I think there could be a place for tailwinds "increasing-breakpoints" approach (min-width queries only, no max-width or ranges). "Scaling" approaches should probably stay in their own utilities.. could always do scaleSizeUtilityFromOtherLibrary(t.w16.width) or similar

The things I still want to brainstorm on are PixelRatio and orientation -- these exist on web too, but perhaps they're more critical in nativeland? Should the sm, md, etc breakpoints be based on screen width, or minimum-edge length?

If you've gotten this far, thanks a lot for reading!

TVke commented

Hi @davidgovea

Good filosofie and research, thank you for that. I presume you know still that I left it out simply as I myself did not have the need for responsiveness.
I understand the growing importance and I am totally open to add this feature.
I think for the philosophy and approach that we need to consider the following.
Users coming from 'tailwindcss' expect the width breakpoints and they also have the opportunity to make orientation breakpoints on the web and you can add them manually.

So in my opinion we approach it the same way and do the width breakpoints and when the orientation of pixel ratio is a need there are always possibilities for creating the distinction themselves.
Maybe we can make it available over time but I thing the main focus should be the width breakpoints as these are expected.

Thank you for your devotion to pushing react-native-tailwind further.

Greetings
Thomas

davidgovea commented

Good call. I'll work on something here.

Will try to match tailwind's customization: default-minWidth, and the min / max specifiers (https://tailwindcss.com/docs/breakpoints)

One place that it could depart from base-tailwind is the "raw" media query customizations..
Perhaps adapting this:

screens: {
  'portrait': {'raw': '(orientation: portrait)'},
}

to something like

// Tailwind supports `min`, `max`, and `raw` directives for media queries
//  We drop `raw`, and add `minRatio`, `maxRatio`, `orientation` directives
screens: {
  'portrait': {'orientation': 'portrait'},
  'hdpi': {'minRatio': 2}
}
  • 👍1
smlarkin commented

@TVke I just found your implementation of TW for RN is quite nice.

I was using tailwind-rn because it was the most popular and the one I had read blog posts about, but I like your API and Docs quite a bit more -- objects are better than strings for all kinds of reasons :)

All to say, would you consider implementing the responsive breakpoints like this ...

vadimdemedes/tailwind-rn#56

...It would really make RN + TW truly useful on the web too.

Also, do you plan on maintaining this project and growing it to cover more of TW's APIs?

TVke commented

Hi @smlarkin

Thank you for testing my implementation.
I will definitely check the implementation you suggested.
I do not have the time to focus full time on this package so I count on PR's for now.

Greetings
Thomas

smlarkin commented

@TVke Thanks you for your prompt reply.

I've read through your open PRs, Tags, Issues and and wanted to know where you were at with this project. I have not contributed to open source and can only imagine the time commitment of being a maintainer can be difficult and perhaps not worth it. There are plenty of stories of maintainers frustrated with the asks of others that cannot put in the time.

I see @davidgovea invested heavily in researching this issue and others and nothing has happened yet.

The link I send above for implementation of responsive breakpoints works and I hope you have time to try it out.

Cheers,
Shawn

TVke commented

Hi @smlarkin

I've spend a lot of time in the first version of this package which was a solid start. Then I had another wave of time to work out the docs and trying to solve the autocomplete problems (not a good solution and reversed it later).
The biggest problem right now is that I do not have any running react native projects anymore.
So I find it hard to work on this package when there is no real world app testing needing to be done.

I have played a lot with the thought of making @davidgovea an officiële co-maintainer.
And I hope he will accept as I do appreciate his hours of work he put in this package in the past and in the still open PR's.
When I have some spare I wil definitely test all the possible breakpoint implementation options, my biggest holdup is the transition and learning curves that come with new features.

Greetings
Thomas