Skip to content
This repository has been archived by the owner on Jul 2, 2024. It is now read-only.

Responsive based on screen size? #28

Open
rawrmonstar opened this issue Jul 1, 2022 · 4 comments
Open

Responsive based on screen size? #28

rawrmonstar opened this issue Jul 1, 2022 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@rawrmonstar
Copy link

Are there plans to support responsive classes? Tailwind has a screens property in its theme file where you define screen sizes such as sm: 640 and md: 768 which generates modified class names such as md:text-center where the text-center class is only applied if the screen meets the requirements for md (e.g., being 768px or wider).

https://tailwindcss.com/docs/screens

I could imagine this being implemented similar to how dark mode is: smClasses, mdClasses etc., or maybe with some special style handlers (however they would need access to windowDimensions state)

I would be willing to hack on this if you are open to the idea.

@gksander
Copy link
Contributor

gksander commented Jul 2, 2022

I think this is a fantastic idea! I think that, similar to dark mode, we could setup a top-level screen size listener (in the StyleProvider), and use that to apply styles based on configurable breakpoints. I think this is very doable, and wouldn't be too complex -- just need to workshop on what the api would look like! (How/where we want to configure the breakpoints, how we want to specify classes per breakpoint, etc)

If you're interested in contributing, I'd be happy to work on this with you! Otherwise we can file this as an "enhancement" ticket, and get to this in the near future.

@gksander gksander added the enhancement New feature or request label Jul 2, 2022
@gksander
Copy link
Contributor

gksander commented Jul 6, 2022

Okay, so here's what I'm thinking for an API:

const { useStyles } = createStyleBuilder({
  // Define your breakpoints (and prefixes) when configuring your builder
  breakpoints: {
    sm: 300,
    md: 450,
    lg: 700
  }
});

// Apply them...
const MyComponent = () => {
  const wrapperStyles = useStlyes({
    classes: ["flex:1", "bg:red-300", "p:1"],
    darkClasses: ["bg:red-900"],
    smClasses: ["p:2"],
    mdClasses: ["p:3"],
    lgClasses: ["px:6", "py:4"]
  });

  return <View style={wrapperStyles} />;
}

Basically,

  1. Define breakpoints in your builder configuration.
  2. Then, Zephyr will expose additional *Classes fields for you to pass in classes to be applied when viewport width greater than specified breakpoint values.
  3. Under the hood, Zephyr will apply those classes accordingly based on viewport width.

@gksander gksander self-assigned this Jul 6, 2022
@rawrmonstar
Copy link
Author

rawrmonstar commented Jul 7, 2022

I was imagining a way to generalize this kind of functionality. I can think of dark mode and media queries as modifiers to a class name. Tailwind uses this idea and denotes the modifier by using a colon after the modifier: https://tailwindcss.com/docs/hover-focus-and-other-states e.g., dark:active:sm:bg-red-300. Since a colon is already used in zephyr maybe it could be replaced with the pipe character: dark|active|sm|bg:red-300. If such a scheme was adopted you would probably need to introduce modifier filter functions

{
    modifierFilters: {
      dark: (styleState) => styleState.darkMode,
      mq: {
	    sm: (styleState) => styleState.viewportWidth >= 300,
	    md: (styleState) => styleState.viewportWidth >= 600,
	    lg: (styleState) => styleState.viewportWidth >= 800,
      },
      active: (styleState) => styleState.active
	}
}

here styleState could be provided to the useStyle hook as a second argument (with defaults provided by state context.

const styles = useStyles([
  "flex:1", 
  "bg:red-300",
  "active|bg-red-500",
  "dark|bg:red-900",
  "dark|active|bg-red-600",
  "p:1",
  "mq:sm|p:2"
  "mq:md|p:3"
  "mq:lg|px:6",
  "mq:lg|py:4"
], {
  darkMode: true, // force dark mode (normal scenario this would not be provided here and would be pulled from context)
  viewportWidth: 600, // force a certain viewportWidth (normally would not be provided and pulled from context instead
  active: true // potentially provided by wrapping pressable or props
});

return <View style={styles} />;

I totally understand if this is not the sort of api you want. It's just what I had in mind when I made the issue.

@atanaskanchev
Copy link

Any news on this one? It's the only missing feature that will get Restyle to the back bench 🥇

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants