Generic iterable data for ReactDOMComponent CSS styles

[cigitia]

Currently, React supports only regular JavaScript objects for ReactDOMComponents' style props, using their enumerated keys:

divStyle = {color: "white"};
React.createElement("div", {style: divStyle}, "…")

But it would be wonderful if it could also support generic data for CSS styles through, e.g., the iterable interface. That would enable Immutable.js and ClojureScript data structures to be directly used as their styles:

divStyle = Immutable.Map({color: "white"});
React.createElement("div", {style: divStyle}, "…")

Currently, this necessitates converting the generic data into regular JavaScript style objects for every styled element for every render, which is pretty wasteful.

In general, it's extremely useful to be able to express styles as generic data, especially persistent immutable data structures, in order to let the end user manipulate the data in the application's UI (e.g., for end-user UI themes), to serialize the data, and to dynamically merge and manipulate the data as needed at runtime.

React Native already supports the last sort of thing with merging StyleSheets, but it’s uncertain whether regular React will have it (see #2196), and it'd be even better for serializability and manipulability if generic style data could be used.

Potential problems:

• This suggestion might or might not slow down React reconciliation or rendering.
• React Native already has a {style: [styleObject1, styleObject2]} standard syntax, used for merging style objects together. Unless that is revised (e.g., by adding a StyleSheet.merge method and having people use that instead), it may not be possible to also support generic style data in React Native, which might create too great of an API mismatch between React and React Native.

Nonetheless, I think generic style data are quite important, and I'm already using them copiously, especially for UI themes.

[Somewhat related to #3059.]

[ghost]

React CSS in JS presentation by Christopher Chedeau.

http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html

See the m() function and see this repo

https://github.com/Sitebase/cssinjs for an inspiration.

I've been using this for a while and it works awesome!
On Sun, Mar 29, 2015 at 4:25 AM cigitia notifications@github.com wrote:

Currently, React supports only regular JavaScript objects for DOM
components' style objects:

divStyle = {color: "white"};
React.createElement("div", {style: divStyle}, "…")

But it would be wonderful if it could also support generic data for CSS
styles through, e.g., the Iterator interface. That would enable
Immutable.js and ClojureScript data structures to be directly used as their
styles:

divStyle = Immutable.Map({color: "white"});
React.createElement("div", {style: divStyle}, "…")

Currently, this necessitates converting the generic data into regular
JavaScript style objects for every styled element for every render, which
is pretty wasteful.

In general, it's extremely useful to be able to express styles as generic
data, to let the end user manipulate the data in the application's UI
(e.g., for end-user UI themes), to serialize the data, and to dynamically
merge and manipulate the data as needed at runtime.

React Native already supports the last sort of thing with merging
StyleSheets https://facebook.github.io/react-native/docs/style.html,
but that's not yet supported in regular React, and it'd be even better for
serializability and manipulability if generic style data could be used.

Potential problems:

• This suggestion might or might not slow down React reconciliation or
  rendering.
• React Native already has a {style: [styleObject1, styleObject2]}
  syntax for merging style objects together. Unless that is revised (e.g., by
  adding a StyleSheet.merge method and having people use that instead),
  this suggestion might create an API mismatch between React and React Native.

Nonetheless, I think generic style data are quite important, and I'm
already using them copiously, especially for UI themes.

[Somewhat related to #3059 https://github.com//issues/3059
.]

—
Reply to this email directly or view it on GitHub
#3542.

[cigitia]

@garrrio m() and the cssinjs project use regular JavaScript objects (POJOs) to express CSS styles, which ReactDOMComponent's style prop already supports anyway. This issue is about being able to directly use other kinds of data (e.g., persistent immutable data structures like those from Immutable.js, ClojureScript) that support a generic interface (e.g., iterable) in ReactDOMComponent's CSS styling. (Since version 0.13, React already does much of the same thing with element children.)

Persistent data structures like those in Immutable.js, ClojureScript, and Mori allow people to similar things to m() but also much more, without completely copying over objects every time. It should be possible to use them, and any other iterable data structures, directly as DOM elements' styles.

As far as I can tell, CSS-style-attribute rendering and style-prop reconciliation both simply iterate over style POJOs' keys using for…in loops already; this might have pretty similar performance characteristics. What worries me more is if whether would induce too great of a mismatch with React Native's method of merging StyleSheets with arrays, since arrays are also iterables. Nonetheless, it'd be super useful to be able to directly use iterables as style props.

[Gozala]

+1 Please add support for Immutable.js and alike!

Problem is indeed is in use of for in loop with .hasOwnProperty :

react/src/renderers/dom/shared/CSSPropertyOperations.js

Lines 121 to 137 in 4c3e965

	createMarkupForStyles: function(styles) {
	var serialized = '';
	for (var styleName in styles) {
	if (!styles.hasOwnProperty(styleName)) {
	continue;
	}
	var styleValue = styles[styleName];
	if (__DEV__) {
	warnValidStyle(styleName, styleValue);
	}
	if (styleValue != null) {
	serialized += processStyleName(styleName) + ':';
	serialized += dangerousStyleValue(styleName, styleValue) + ';';
	}
	}
	return serialized || null;
	},

Personally run into issue with a computed styles who's fields are expressed via getters.

[sophiebits]

Going to count this as part of #3059 as we'll likely support either both or neither.

[cigitia]

Ah, I see; thanks for the response. Since, as syranide had pointed out [https://github.com//issues/3059#issuecomment-87301879], the style prop of ReactDOMComponent is technically a separate issue, this issue may still be a contender even if #3059 is eventually rejected for good (which I do hope won't be the case). We’ll see what happens to #3059 first, though, yes.

[sophiebits]

It's true that there's no technical reason they need to be consistent, but it's hard for me to imagine us doing one and not the other.