5 ms·

I've been looking at reactive UI design, and it seems weird to me that React.js has this React.createClass and .setState stuff. It seems like it would be bette

I've been looking at reactive UI design, and it seems weird to me that React.js has this React.createClass and .setState stuff. It seems like it would be better to let the user manage the state and just re-render whenever the state changes. Am I missing something about how this works that makes those necessary?

Swizec 11y ago
By making it explicit and a bit clunky, you discourage users from using state. Without explicit functions to be called, you can't detect state changes and would need polling. This is terrible. At the end of the day, it's a limitation of JavaScript because unlike with Python, for example, you can't have automagic getter/setter functions. They have to be called as functions.
- nulltype 11y ago
  Seems like .observe() would fix that polling thing, right? http://www.html5rocks.com/en/tutorials/es7/observe/ http://www.html5rocks.com/en/tutorials/es7/observe/ Also you could just re-render whenever any event happens, which is probably when your state changes anyway.
  - Swizec 11y ago
    It would if browsers supported it: http://caniuse.com/#search=observe http://caniuse.com/#search=observe So far exists only on Chrome and Android browsers.
  - lopatin 11y ago
    One reason for the explicit method may be that React does an internal optimization where it batches state updates together. Two calls to setState can result in just one render. https://groups.google.com/forum/#!msg/reactjs/R61kPjs-yXE/ysmpC0IvA4YJ https://groups.google.com/forum/#!msg/reactjs/R61kPjs-yXE/ys...
    - masklinn 11y ago
      No reason why this wouldn't be possible with Observe, the first call schedules a re-render and the next one doesn't do anything since there's already a re-render scheduled.
  - cgag 11y ago
    Observe just makes making bad apis easier imo. I don't care if react can detect state changes, I want to detect state changes by searching for setState.
  - masklinn 11y ago
    A possible issue is setState doesn't transition the object's state, it creates an async future/pending state transition (and multiple state transitions can be batched). Object.observe can only operate reactively, the state has already changed and the next dereferencing of state data will see the "next state" instead of the "current state".
- straws 11y ago
  Actually, custom getters and setters exist in ES5: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects#Defining_getters_and_setters https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... AmpersandJS, for example, implements its observable pattern in this way: http://ampersandjs.com/learn/state http://ampersandjs.com/learn/state That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data structure that allows for efficient diffing — which nicely mirrors the diffing react does with both it's internal component tree and diffing with the DOM — is a much more straightforward approach. Just re-render your application 60 times a second, like a game engine, and make that process as efficient as possible.
  - nulltype 11y ago
    This is exactly where I am hoping reactive ui ends up. If you don't want to do 60 times a second you can render only on certain events like network call or mouseover. If you do the rendering in requestAnimationFrame you can batch things easily.
rattray 11y ago
I believe `React.createClass` will be deprecated in the future in favor of ES6 classes. As another commenter mentioned, explicit `.setState` makes it much easier to see where in your code you're triggering changes. It also helps you think, "okay, I am mutating the state here... is that really what I want to do?"
simplify 11y ago
You are absolutely correct; this is what Mithril.js does. In Mithril, a component is a plain JavaScript object with only two properties: controller and view. No set / replaceState, no component[Will | Did][Mount | ReceiveProps] – just plain JavaScript data structures. Because Mithril uses plain JavaScript constructs, you can use standard design patterns and techniques when constructing and managing your components. Everything works beautifully.
- Numberwang 11y ago
  Why isn't the Mithril library more popular?
  - simplify 11y ago
    It's getting more and more popular every day! It just doesn't have a billion dollar company's marketing budget to promote itself :)
spicyj 11y ago
You can choose not to use the React component abstraction at all and just re-call React.render(makeElements(state), el) at the top level each time your app changes (using pure functions to generate the tree). Our plan is also to support pure functions directly for components that don't rely on state. You can also use the component abstraction but choose not to use getInitialState/setState -- but our goals are to provide a component abstraction that is flexible enough to meet people's needs while still being restrictive enough for us to build higher-level optimizations around them.

Swizec 11y ago

By making it explicit and a bit clunky, you discourage users from using state. Without explicit functions to be called, you can't detect state changes and would need polling. This is terrible. At the end of the day, it's a limitation of JavaScript because unlike with Python, for example, you can't have automagic getter/setter functions. They have to be called as functions.

nulltype 11y ago
Seems like .observe() would fix that polling thing, right? http://www.html5rocks.com/en/tutorials/es7/observe/ http://www.html5rocks.com/en/tutorials/es7/observe/ Also you could just re-render whenever any event happens, which is probably when your state changes anyway.
- Swizec 11y ago
  It would if browsers supported it: http://caniuse.com/#search=observe http://caniuse.com/#search=observe So far exists only on Chrome and Android browsers.
- lopatin 11y ago
  One reason for the explicit method may be that React does an internal optimization where it batches state updates together. Two calls to setState can result in just one render. https://groups.google.com/forum/#!msg/reactjs/R61kPjs-yXE/ysmpC0IvA4YJ https://groups.google.com/forum/#!msg/reactjs/R61kPjs-yXE/ys...
  - masklinn 11y ago
    No reason why this wouldn't be possible with Observe, the first call schedules a re-render and the next one doesn't do anything since there's already a re-render scheduled.
- cgag 11y ago
  Observe just makes making bad apis easier imo. I don't care if react can detect state changes, I want to detect state changes by searching for setState.
- masklinn 11y ago
  A possible issue is setState doesn't transition the object's state, it creates an async future/pending state transition (and multiple state transitions can be batched). Object.observe can only operate reactively, the state has already changed and the next dereferencing of state data will see the "next state" instead of the "current state".
straws 11y ago
Actually, custom getters and setters exist in ES5: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Working_with_Objects#Defining_getters_and_setters https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... AmpersandJS, for example, implements its observable pattern in this way: http://ampersandjs.com/learn/state http://ampersandjs.com/learn/state That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data structure that allows for efficient diffing — which nicely mirrors the diffing react does with both it's internal component tree and diffing with the DOM — is a much more straightforward approach. Just re-render your application 60 times a second, like a game engine, and make that process as efficient as possible.
- nulltype 11y ago
  This is exactly where I am hoping reactive ui ends up. If you don't want to do 60 times a second you can render only on certain events like network call or mouseover. If you do the rendering in requestAnimationFrame you can batch things easily.

rattray 11y ago

I believe `React.createClass` will be deprecated in the future in favor of ES6 classes. As another commenter mentioned, explicit `.setState` makes it much easier to see where in your code you're triggering changes. It also helps you think, "okay, I am mutating the state here... is that really what I want to do?"

simplify 11y ago

You are absolutely correct; this is what Mithril.js does. In Mithril, a component is a plain JavaScript object with only two properties: controller and view. No set / replaceState, no component[Will | Did][Mount | ReceiveProps] – just plain JavaScript data structures. Because Mithril uses plain JavaScript constructs, you can use standard design patterns and techniques when constructing and managing your components. Everything works beautifully.

Numberwang 11y ago
Why isn't the Mithril library more popular?
- simplify 11y ago
  It's getting more and more popular every day! It just doesn't have a billion dollar company's marketing budget to promote itself :)

spicyj 11y ago

You can choose not to use the React component abstraction at all and just re-call React.render(makeElements(state), el) at the top level each time your app changes (using pure functions to generate the tree). Our plan is also to support pure functions directly for components that don't rely on state. You can also use the component abstraction but choose not to use getInitialState/setState -- but our goals are to provide a component abstraction that is flexible enough to meet people's needs while still being restrictive enough for us to build higher-level optimizations around them.