add basic suport for mediaQuery aliases

[azazdeaz]

Regards this and this comment i implemented a possible way to use named media queries.

It's pretty simple:

var alias = '@portrait';
var query = '@media only screen and (max-width: 768px) and (orientation: portrait)';
Radium.Config.setMediaQueryAlias(alias, query);

and inside the resolveMediaQueryStyles() function it replaces the the alias to the query

if (Config.isMediaQueryAlias(query)) {
  query = Config.getMediaQueryByAlias(query);
}

In our use case we saving the styles into JSON so it's shrinks the file size and makes it easier to edit the mediaQueries later.

What do you think?

[ianobermiller]

Cool! Couple things to note:

• This same thing can already be accomplished through ES6 computed properties
• If we do add support, we should use the same syntax as proposed for css: http://dev.w3.org/csswg/mediaqueries/#custom-mq, which would be Radium.Config.defineCustomMedia('narrow-window', '(max-width: 30em)'); and @media (--custom name)

@alexlande thougts on adding this to Radium? is it worth adding if computed properties solve the same issue with no additional code on Radium's side? Unfortunately I am inclined to say no.

[azazdeaz]

This same thing can already be accomplished through ES6 computed properties

This is true and it's probably not a common way to use Radium but with the computed properties we have no clear way no change the media queries after the style objects generated.
Ie. i cant say that i load a JSON with my Radium styles and let my App to decide which actual media queries it wants to use for the different devices.

If we do add support, we should use the same syntax as proposed for css

Yes, it's perfectly make sense to implement a way that probably will be standard and i would happily do that but felt unnecessary to make regex match and string replace on every resolve when in the most cases we just need a named media query like we had in the older versions. On the other hand it would make the API more standard so i can agree whit this.

[ianobermiller]

I'm not sure we should be using Maps in the Radium core yet. They require more polyfill that what is needed for just React. So far we've only required the same ES5 polyfills, and let Babel do the rest.

[azazdeaz]

You're right, a plain object would do.

[ianobermiller]

no clear way no change the media queries after the style objects generated

Interesting, I've not thought about changing media queries at runtime.

regex match and string replace on every resolve

When seting the media query, you can just make the key @media (--${name}) instead, so no regex required. What you would lose, as opposed to an actually string replace, is the ability to compose custom media queries, like @meda (--narrow) and (--high-density).

[ianobermiller]

I wonder if we should make checks like this for development only using if (__DEV__) { ... } and some kind of webpack rule.

[azazdeaz]

Yes, and it seems pretty easy to add with webpack.

[alexlande]

Still not sure about this. In principle I like it, but computed properties (or the more ugly styles[mediaQueryVariable] if you're not using Babel) covers the vast majority of use cases.

Changing media queries at runtime is interesting, but an edge case. You could feasibly do it now by defining the custom media query styles in your render method, right?

var styles = {
  customMediaQuery: { }
};

render() {
  styles[globalMediaQueryVariable] = styles.customMediaQuery;

  return (...);
}

[alexlande]

I guess you wouldn't want to mutate styles as in that example. You could just pass in the customMediaQuery object into the component's style prop along with the other styles and let Radium resolve it.

[azazdeaz]

Yes, i'd like to "just pass in the customMediaQuery object into the component's style prop along with the other styles and let Radium resolve it" but it's really not the goal to solve my personal use case. If you don't feel like Radium should have some functionality like MatchMediaBase was or the Custom Media Queries i can live without it too :)

[alexlande]

@azazdeaz: Yeah, sorry, didn't mean you specifically, but "person [x] who might have that use case."

I mostly meant that there is an option (that's sort of ugly but not too bad) if someone has that requirement.

I'm thinking we don't need this in Radium unless we find another compelling use case. It's pretty doable with the available tools already.

[ianobermiller]

I tend to agree, especially since this adds 3 methods to the API. Thanks
much for the pr and raising the discussion!

On Thu, Jun 11, 2015, 10:27 AM Alex Lande notifications@github.com wrote:

@azazdeaz https://github.com/azazdeaz: Yeah, sorry, didn't mean you
specifically, but "person [x] who might have that use case."

I mostly meant that there is an option (that's sort of ugly but not too
bad) if someone has that requirement.

I'm thinking we don't need this in Radium unless we find another
compelling use case. It's pretty doable with the available tools already.

—
Reply to this email directly or view it on GitHub
#203 (comment)
.