9 ms·

React v0.14

320 points by spicyj 11y ago

deleted 11y ago
[deleted]
clessg 11y ago
A lot of great ideas in this release and it makes me excited for the future of React. I've been on 0.14-rc1 and my favorite feature so far is stateless function components. So much cleaner than class-based components. One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) Andrew Clark (core contributor to Redux and creator of Flummox) just released Recompose which provides powerful capabilities for stateless components: https://github.com/acdlite/recompose https://github.com/acdlite/recompose. Some of the benefits of stateless function components as outlined in Recompose's readme: * They prevent abuse of the setState() API, favoring props instead. * They're simpler, and therefore less error-prone. * They encourage the smart vs. dumb component pattern. * They encourage code that is more reusable and modular. * They discourage giant, complicated components that do too many things. * In the future, they will allow React to make performance optimizations by avoiding unnecessary checks and memory allocations.
- smadge 11y ago
  What exactly is different? I've been using "stateless function components" with react 0.12 and 0.13. Just write a function that returns a ReactElement, eg: function renderFoo(props) { return <span>{props.foo}</span>; } Then use it elsewhere in your code like a normal function: function bar(props) { return <div>{props.foos.map(renderFoo)}</div>; }
  - epmatsw 11y ago
    Looks like they've just added first-class support for that pattern, so you get propTypes, defaultProps, etc.
    - danabramov 11y ago
      Also in the future this pattern will be faster thanks to React not having to maintain an internal instance for such components. (How's that different from just a function? It shows up as separate thing in React DevTools, it can have default props or, in the future, shouldComponentUpdate (or built-in memoization strategy?), you can potentially later change it to be stateful without rewriting consuming code, etc)
- k__ 11y ago
  Is it possible to build an entire app with them using Redux?
  - grayrest 11y ago
    The Elm and Reagent (Clojurescript) communities build apps this way. It's theoretically possible to do everything in render in practice you wind up wanting to do things in other lifecycle events (e.g. display a google map) in most apps. There isn't any component local state but the components aren't pure render functions either.
    - tracker1 11y ago
      In general, interacting with anything that does more interactive rendering (three.js, google maps, ads, etc) requires access to lifecycle events beyond a simple render method... In the past I've had to keep a handle on the DOM nodes for ad slots that may hide/reshow when a window was re-sized, so the same ad was kept. However, this should be the exception to the rule, and I still love the React way over components (Polymer) or angular directives.
  - clessg 11y ago
    That should be possible! Of course, stateless components don't have state, so you would need to something like Recompose if you need that. And of course, not all React-related projects explicitly support stateless components at the moment (e.g. hot reloading). Another option is to use psuedo-local state with Redux and pass everything as props: https://github.com/rackt/redux/issues/159 https://github.com/rackt/redux/issues/159. As Dan notes in that issue though, it might be better to wait for the state tree model to be improved: https://github.com/facebook/react/issues/4595 https://github.com/facebook/react/issues/4595. In short: early days, too early to tell what patterns will emerge.
  - aboodman 11y ago
    I generally try to do everything in render(). It almost always works out better. Sometimes I end up needing a lifecycle event. Timers (e.g., for manual animations) end up being hard to model without mount/unmount.
- devit 11y ago
  The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications. For example, if you display photos in a table, there is no state, but if you display photos with a carousel, then you have state as the current page, but these two components should otherwise have the same interface and implementation. Also in general the current selection and scroll position is state, albeit stored in the browser, so any UI component can potentially have state, even if it is only stored implicitly in the DOM objects. What really matters is whether the component holds any state with "semantic" meaning or that needs to be persisted (like a date the user selected in a date picker) or whether all the state is "presentational" (like the month a date picker is showing). What you should do in React is not hold any "semantic" state in components, unless it's a component that is solely designed for holding and managing such state (e.g. Relay container components, or a root App component). EDIT: slightly reworded to be clearer and more correct, since having the same API interface regardless of statefulness is implicit in React
  - clessg 11y ago
    > The idea of having "stateless" UI components in this sense seems ill-conceived, because whether a UI component has state should not be a concern of the user of the component. I might not understand your point, but the user of the component shouldn't have any need to know whether it's stateful. A stateless `Photo` function component should have the same interface as a `Photo` class component: `<Photo ... />`.
  - lobster_johnson 11y ago
    You embed stateless (function-based) components just like you do for normal components. There is no interface difference; the caller doesn't need to know whether the component it is using is stateless or not.
  - masklinn 11y ago
    > The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications. But… it doesn't? 0.14 just provides a simpler way to define stateless components. For a component user, there should be no difference between a "functional" stateless component and am "object" stateless component which defines a whole class with only a render method.
- sebmarkbage 11y ago
  Note that the stateless part is mostly just a stepping stone to a stateful variant. https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State https://github.com/reactjs/react-future/tree/master/07%20-%2...
  - clessg 11y ago
    Yep, I saw that, and that's even more exciting. Any possibility of 0.15 or 0.16 on that front?
- octref 11y ago
  I also like stateless function components. If you are using Redux, all the state management can be done at Redux side and you can make all React components stateless. And they become even easier to write after this release.
- acdlite 11y ago
  Thanks for the link! Should clarify that Recompose works equally well with stateful components created with either createClass or React.Component. It just happens to be especially useful for stateless functional components :)
- danabramov 11y ago
  >One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) There's work in progress on this, and I'll try to release an update to React Transform & friends handling this next week. Might take longer to retrofit this into React Hot Loader but if there's enough demand I can try doing this too.
- malandrew 11y ago
  So basically, react is becoming like mercury one release at a time.
gh0sts 11y ago
Great news. I just upgraded our app to 0.14-rc1 last week and particularly enjoy "refs" being direct references to the DOM nodes. Can't wait to move some of our stateless components to functional.
desuvader 11y ago
Wohoo! .getDOMNode() is finally gone! Edit: Haha, I just noticed that someone else was also happy about this. Also, now that classnames is standalone module, I recommend that people start using a standalone implementation of keyMirror (for flux) as well!
- hexasquid 11y ago
  .getDAMNNode
- thebigkick 11y ago
  Would you mind explaining? As a jQuery believer, to me this looks like a selector method - getElementByID or something. I'm guessing this is against the whole idea of React.
  - desuvader 11y ago
    Refs are simply references to DOM nodes that you have to specify through the ref (HTML) attribute. You can give a DOM node the ref value "foo" and then later reference it in a react component with this.refs.foo (previously this.refs.foo.getDOMNode()).
Touche 11y ago
> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. Since React is a semver project, from the website: > How do I know when to release 1.0.0? > If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
- drinchev 11y ago
  Yes. This bugs me out. It's already so popular and a lot of people use this in production and rely on that. I really hope they do what NodeJS/IO did and figure out that it's far away from any "pre-release" state to keep the version number after two 0s.
- eric-hu 11y ago
  I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?
  - epmatsw 11y ago
    We're migrating from Backbone to React, and it's been lovely. Our main argument is essentially what the grandparent said: based on the policies React has been following, it basically behaves like a 1.0 release. There's clear deprecation warnings and announcements, and those are caught by our test suite. The only backwards-incompatible changes that have happened since we started using it earlier this year have been mostly painless Ctrl+F fixes, and even the bigger ones (ReactDOM, etc.) have not been too much of a problem. And from a logical perspective, if it's stable enough for Facebook (Alexa #2) to use for production, it's stable enough for a smallish HR software company.
    - ry_ry 11y ago
losvedir 11y ago
The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code. Can React be a competitor to, say, Knockout? React seems more in the realm of angular or ember to me.
- insin 11y ago
  > Is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? Not if you want to reuse the server-generated markup. You can use it for little pieces in an otherwise static page, but it needs to own rendering of those pieces.
  - donjh 11y ago
    On some platforms you can render your React components server-side and have the JS take over. ReactJS.net, for example, has this capability.
- tootie 11y ago
  React is really 2 things. One is an implementation of web components which makes it a competitor to Polymer and is is useful on almost any project. Secondly, React is an implementation of the Flux architecture (one-way data binding) which is most useful for SPAs, but doesn't disrupt a static site as much as Angular does.
  - robertfw 11y ago
    React is not an implementation of the Flux architecture. Flux is an architecture that works well with react. I would argue that the primary contribution from React is not the web component aspect but the declarative, immutable-friendly approach to UI rendering
  - 11y ago
aaronkrolik 11y ago
I'm fairly new to react, and have wondered if I was using it correctly (as intended). Almost always I have a root component that manages state, passing it to children via props. All changes to state go through that root component, either by callback (also passed as prop) or some external event. Is this update in a sense validation of that approach?
- epmatsw 11y ago
  What you've described is pretty similar to Flux or one of its variants. The main difference would be that instead of managing state inside of the root component via setState, you have an external state ("store"), which would handle the state logic and provide the appropriate values as props to the root component. So yes, it sounds like you're doing it "right".
drinchev 11y ago
React is cool. Switching to React helped me do : 1. Get rid of any jquery-like library. 2. Get rid of my HTML/Handlebars files :) 3. Generate dynamic CSS classNames for my components allowed me to get rid of stylesheets naming conventions / strategies ( BEM, etc. ) 4. With the help of Flux ( yahoo's implementation ) I got rid of writing two code-bases ( front-end / back-end ). Now I'm putting everything in one place, this is awesome! ( I did it with server-side rendering, so I didn't loose anything at all )
- omouse 11y ago
  The light-weight structure that React imposes is what lets you get rid of jquery (and much of the plugins) and Handlebars/Mustache special syntax. React removes a layer of syntax and favours using plain old JavaScript.
- doque 11y ago
  Can you explain 3.?
- s3nnyy 11y ago
  Can you please elaborate on 3.?
  - Callmenorm 11y ago
    I think he's talking about css modules. Postcss or something like that. Webpack can generate unique names for you when you use that loader. I think it's more about webpack for #3 than react.
    - drinchev 11y ago
      Yes it is. But those tools usually rely on your Javascriptified HTML, which is something that React does. So React is a prerequsite on that.
  - drinchev 11y ago
    Yes. Since your HTML is all Javascript now, there are people that went a bit further and created libraries for modularising your CSS files, based on that components [1][2]. The basic idea is that, since you are using ReactJS and you are compiling your JSX files to normal JS files, for which you are using a tool like "browserify" or "webpack". These tools are so powerful that can capture your `require` statements and convert your "non-javascript" required modules to something that javascript can use. In a similar way I'm using webpack & css-loader. My JSX file looks like this : // Component.jsx var styles = require('./Component.css'); // Component.css is a normal css file that has a .component class inside class Component extends React.Component { render() { return ( <div className={ styles.component }></div> ) } } Now your webpack / browserify tools captures those require files, parses their class names and outputs a concatenated "stylesheets.css" file that has all the class names with a hash prefix. And the final Html/Css look like this : <div class="_12az2X"></div> with stylesheets file ._12az2X { color: red; } [1] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules [2] https://github.com/webpack/css-loader https://github.com/webpack/css-loader
omouse 11y ago
I'm glad they separated out react from the DOM. This makes it much more likely that people will export the ideas and the API of React to other languages. The API is sane for data-flow programming and the lifecycle is well-defined. The separation of properties from state can be useful in other contexts.
kraig911 11y ago
Anyone find a list that says what is broken by this update? I couldn't find an easy to parse list of functions/methods/etc that have changed ||&& are broken.
- spicyj 11y ago
  Were my "Upgrade Guide" and "Breaking Changes" sections not clear? I tried to make it as clear as possible but you still seem confused…
  - danabramov 11y ago
    If you didn't see warnings running code under 0.13, nothing should break per se, right? And if you see warnings now, that's the stuff that will break in 0.15 but works for now.
    - spicyj 11y ago
      Yes, with the exception of the React.initializeTouchEvents() removal and the ReactTestUtils change I noted.
zkhalique 11y ago
I have a question, why is dirty-checking so great? Whether it's Angular doing dirty-checking in the $digest cycle or React walking the virtual DOM and doing dirty-checking? Why not just subscribe to events and update things when the model changes? That would seem to be far more efficient, and also make clear the mapping of dependencies of views on data.
- draw_down 11y ago
  React does not do dirty checking.
  - pkozlowski_os 11y ago
    Well, it kind of does when comparing virtual DOMs before and after changes.
    - danabramov 11y ago
      Usually people say “dirty checking” when they mean “keep checking in some kind of event loop whether external entity modified some object, and if so, do something”. In React there's no such event loop where it checks virtual DOM—React knows if it needs to compare virtual DOM trees (not arbitrarily check models for changes, for example) because all changes are explicit and happen either due to `setState()`, `forceUpdate()` or `React.render()` top-level call. So React doesn't do dirty checking in the sense Angular does, unless by dirty checking you mean all kinds of comparisons.
      - pkozlowski_os 11y ago
        Right. I guess it really depends how people define "dirty checking". What I was trying to say is that at the end of the day you do diffing on some data structure: model in Angular and virtual Dom in React. Loop vs. one pass is an important distinction, agreed. But when we bring Angular we should be noted that Angular 2 doesn't do those checks in a loop but does comparisons in one pass only.
oblio 11y ago
Is there some sort of React component repository or something?
- clessg 11y ago
  http://react.parts/web http://react.parts/web and http://react-components.com/ http://react-components.com/
  - hliyan 11y ago
    Thank you so much for this! http://react.parts/web http://react.parts/web is very useful (particularly that it shows stars and download counts next to each component entry).
- tracker1 11y ago
  Would start with npmjs.com, either a direct search or a site specific search with google. https://www.npmjs.com/search?q=react%2C+component https://www.npmjs.com/search?q=react%2C+component https://www.google.com/search?q=site%3Anpmjs.com+react%2C+component https://www.google.com/search?q=site%3Anpmjs.com+react%2C+co...
crudbug 11y ago
Are there any good component libraries for React ? JSF ecosystem is a good example of component based web UIs.
suchitpuri 11y ago
Well i think it will take some time for libraries and components to be updated. For me currently at least react router should provide a compatible build with react 0.14

320 points by spicyj 11y ago

deleted 11y ago

[deleted]

A lot of great ideas in this release and it makes me excited for the future of React. I've been on 0.14-rc1 and my favorite feature so far is stateless function components. So much cleaner than class-based components. One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) Andrew Clark (core contributor to Redux and creator of Flummox) just released Recompose which provides powerful capabilities for stateless components: https://github.com/acdlite/recompose https://github.com/acdlite/recompose. Some of the benefits of stateless function components as outlined in Recompose's readme: * They prevent abuse of the setState() API, favoring props instead. * They're simpler, and therefore less error-prone. * They encourage the smart vs. dumb component pattern. * They encourage code that is more reusable and modular. * They discourage giant, complicated components that do too many things. * In the future, they will allow React to make performance optimizations by avoiding unnecessary checks and memory allocations.

smadge 11y ago
What exactly is different? I've been using "stateless function components" with react 0.12 and 0.13. Just write a function that returns a ReactElement, eg: function renderFoo(props) { return <span>{props.foo}</span>; } Then use it elsewhere in your code like a normal function: function bar(props) { return <div>{props.foos.map(renderFoo)}</div>; }
- epmatsw 11y ago
  Looks like they've just added first-class support for that pattern, so you get propTypes, defaultProps, etc.
  - danabramov 11y ago
    Also in the future this pattern will be faster thanks to React not having to maintain an internal instance for such components. (How's that different from just a function? It shows up as separate thing in React DevTools, it can have default props or, in the future, shouldComponentUpdate (or built-in memoization strategy?), you can potentially later change it to be stateful without rewriting consuming code, etc)
k__ 11y ago
Is it possible to build an entire app with them using Redux?
- grayrest 11y ago
  The Elm and Reagent (Clojurescript) communities build apps this way. It's theoretically possible to do everything in render in practice you wind up wanting to do things in other lifecycle events (e.g. display a google map) in most apps. There isn't any component local state but the components aren't pure render functions either.
  - tracker1 11y ago
    In general, interacting with anything that does more interactive rendering (three.js, google maps, ads, etc) requires access to lifecycle events beyond a simple render method... In the past I've had to keep a handle on the DOM nodes for ad slots that may hide/reshow when a window was re-sized, so the same ad was kept. However, this should be the exception to the rule, and I still love the React way over components (Polymer) or angular directives.
- clessg 11y ago
  That should be possible! Of course, stateless components don't have state, so you would need to something like Recompose if you need that. And of course, not all React-related projects explicitly support stateless components at the moment (e.g. hot reloading). Another option is to use psuedo-local state with Redux and pass everything as props: https://github.com/rackt/redux/issues/159 https://github.com/rackt/redux/issues/159. As Dan notes in that issue though, it might be better to wait for the state tree model to be improved: https://github.com/facebook/react/issues/4595 https://github.com/facebook/react/issues/4595. In short: early days, too early to tell what patterns will emerge.
- aboodman 11y ago
  I generally try to do everything in render(). It almost always works out better. Sometimes I end up needing a lifecycle event. Timers (e.g., for manual animations) end up being hard to model without mount/unmount.
devit 11y ago
The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications. For example, if you display photos in a table, there is no state, but if you display photos with a carousel, then you have state as the current page, but these two components should otherwise have the same interface and implementation. Also in general the current selection and scroll position is state, albeit stored in the browser, so any UI component can potentially have state, even if it is only stored implicitly in the DOM objects. What really matters is whether the component holds any state with "semantic" meaning or that needs to be persisted (like a date the user selected in a date picker) or whether all the state is "presentational" (like the month a date picker is showing). What you should do in React is not hold any "semantic" state in components, unless it's a component that is solely designed for holding and managing such state (e.g. Relay container components, or a root App component). EDIT: slightly reworded to be clearer and more correct, since having the same API interface regardless of statefulness is implicit in React
- clessg 11y ago
  > The idea of having "stateless" UI components in this sense seems ill-conceived, because whether a UI component has state should not be a concern of the user of the component. I might not understand your point, but the user of the component shouldn't have any need to know whether it's stateful. A stateless `Photo` function component should have the same interface as a `Photo` class component: `<Photo ... />`.
- lobster_johnson 11y ago
  You embed stateless (function-based) components just like you do for normal components. There is no interface difference; the caller doesn't need to know whether the component it is using is stateless or not.
- masklinn 11y ago
  > The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications. But… it doesn't? 0.14 just provides a simpler way to define stateless components. For a component user, there should be no difference between a "functional" stateless component and am "object" stateless component which defines a whole class with only a render method.
sebmarkbage 11y ago
Note that the stateless part is mostly just a stepping stone to a stateful variant. https://github.com/reactjs/react-future/tree/master/07%20-%20Returning%20State https://github.com/reactjs/react-future/tree/master/07%20-%2...
- clessg 11y ago
  Yep, I saw that, and that's even more exciting. Any possibility of 0.15 or 0.16 on that front?
octref 11y ago
I also like stateless function components. If you are using Redux, all the state management can be done at Redux side and you can make all React components stateless. And they become even easier to write after this release.
acdlite 11y ago
Thanks for the link! Should clarify that Recompose works equally well with stateful components created with either createClass or React.Component. It just happens to be especially useful for stateless functional components :)
danabramov 11y ago
>One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.) There's work in progress on this, and I'll try to release an update to React Transform & friends handling this next week. Might take longer to retrofit this into React Hot Loader but if there's enough demand I can try doing this too.
malandrew 11y ago
So basically, react is becoming like mercury one release at a time.

gh0sts 11y ago

Great news. I just upgraded our app to 0.14-rc1 last week and particularly enjoy "refs" being direct references to the DOM nodes. Can't wait to move some of our stateless components to functional.

desuvader 11y ago

Wohoo! .getDOMNode() is finally gone! Edit: Haha, I just noticed that someone else was also happy about this. Also, now that classnames is standalone module, I recommend that people start using a standalone implementation of keyMirror (for flux) as well!

hexasquid 11y ago
.getDAMNNode
thebigkick 11y ago
Would you mind explaining? As a jQuery believer, to me this looks like a selector method - getElementByID or something. I'm guessing this is against the whole idea of React.
- desuvader 11y ago
  Refs are simply references to DOM nodes that you have to specify through the ref (HTML) attribute. You can give a DOM node the ref value "foo" and then later reference it in a react component with this.refs.foo (previously this.refs.foo.getDOMNode()).

Touche 11y ago

> Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain. Since React is a semver project, from the website: > How do I know when to release 1.0.0? > If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.

drinchev 11y ago
Yes. This bugs me out. It's already so popular and a lot of people use this in production and rely on that. I really hope they do what NodeJS/IO did and figure out that it's far away from any "pre-release" state to keep the version number after two 0s.
eric-hu 11y ago
I came in here to comment on this. React sounds exciting from what I've read about it, but I didn't realize it was pre-1.0. To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?
- epmatsw 11y ago
  We're migrating from Backbone to React, and it's been lovely. Our main argument is essentially what the grandparent said: based on the policies React has been following, it basically behaves like a 1.0 release. There's clear deprecation warnings and announcements, and those are caught by our test suite. The only backwards-incompatible changes that have happened since we started using it earlier this year have been mostly painless Ctrl+F fixes, and even the bigger ones (ReactDOM, etc.) have not been too much of a problem. And from a logical perspective, if it's stable enough for Facebook (Alexa #2) to use for production, it's stable enough for a smallish HR software company.
  - ry_ry 11y ago

losvedir 11y ago

The enthusiasm around React is infectious and I'm thinking about integrating it into one of my projects but I can't quite tell what exactly it's supposed to be used for. Is it only for SPAs or is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code. Can React be a competitor to, say, Knockout? React seems more in the realm of angular or ember to me.

insin 11y ago
> Is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side? Not if you want to reuse the server-generated markup. You can use it for little pieces in an otherwise static page, but it needs to own rendering of those pieces.
- donjh 11y ago
  On some platforms you can render your React components server-side and have the JS take over. ReactJS.net, for example, has this capability.
tootie 11y ago
React is really 2 things. One is an implementation of web components which makes it a competitor to Polymer and is is useful on almost any project. Secondly, React is an implementation of the Flux architecture (one-way data binding) which is most useful for SPAs, but doesn't disrupt a static site as much as Angular does.
- robertfw 11y ago
  React is not an implementation of the Flux architecture. Flux is an architecture that works well with react. I would argue that the primary contribution from React is not the web component aspect but the declarative, immutable-friendly approach to UI rendering
- 11y ago

aaronkrolik 11y ago

I'm fairly new to react, and have wondered if I was using it correctly (as intended). Almost always I have a root component that manages state, passing it to children via props. All changes to state go through that root component, either by callback (also passed as prop) or some external event. Is this update in a sense validation of that approach?

epmatsw 11y ago
What you've described is pretty similar to Flux or one of its variants. The main difference would be that instead of managing state inside of the root component via setState, you have an external state ("store"), which would handle the state logic and provide the appropriate values as props to the root component. So yes, it sounds like you're doing it "right".

drinchev 11y ago

React is cool. Switching to React helped me do : 1. Get rid of any jquery-like library. 2. Get rid of my HTML/Handlebars files :) 3. Generate dynamic CSS classNames for my components allowed me to get rid of stylesheets naming conventions / strategies ( BEM, etc. ) 4. With the help of Flux ( yahoo's implementation ) I got rid of writing two code-bases ( front-end / back-end ). Now I'm putting everything in one place, this is awesome! ( I did it with server-side rendering, so I didn't loose anything at all )

omouse 11y ago
The light-weight structure that React imposes is what lets you get rid of jquery (and much of the plugins) and Handlebars/Mustache special syntax. React removes a layer of syntax and favours using plain old JavaScript.
doque 11y ago
Can you explain 3.?
s3nnyy 11y ago
Can you please elaborate on 3.?
- Callmenorm 11y ago
  I think he's talking about css modules. Postcss or something like that. Webpack can generate unique names for you when you use that loader. I think it's more about webpack for #3 than react.
  - drinchev 11y ago
    Yes it is. But those tools usually rely on your Javascriptified HTML, which is something that React does. So React is a prerequsite on that.
- drinchev 11y ago
  Yes. Since your HTML is all Javascript now, there are people that went a bit further and created libraries for modularising your CSS files, based on that components [1][2]. The basic idea is that, since you are using ReactJS and you are compiling your JSX files to normal JS files, for which you are using a tool like "browserify" or "webpack". These tools are so powerful that can capture your `require` statements and convert your "non-javascript" required modules to something that javascript can use. In a similar way I'm using webpack & css-loader. My JSX file looks like this : // Component.jsx var styles = require('./Component.css'); // Component.css is a normal css file that has a .component class inside class Component extends React.Component { render() { return ( <div className={ styles.component }></div> ) } } Now your webpack / browserify tools captures those require files, parses their class names and outputs a concatenated "stylesheets.css" file that has all the class names with a hash prefix. And the final Html/Css look like this : <div class="_12az2X"></div> with stylesheets file ._12az2X { color: red; } [1] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules [2] https://github.com/webpack/css-loader https://github.com/webpack/css-loader

omouse 11y ago

I'm glad they separated out react from the DOM. This makes it much more likely that people will export the ideas and the API of React to other languages. The API is sane for data-flow programming and the lifecycle is well-defined. The separation of properties from state can be useful in other contexts.

kraig911 11y ago

Anyone find a list that says what is broken by this update? I couldn't find an easy to parse list of functions/methods/etc that have changed ||&& are broken.

spicyj 11y ago
Were my "Upgrade Guide" and "Breaking Changes" sections not clear? I tried to make it as clear as possible but you still seem confused…
- danabramov 11y ago
  If you didn't see warnings running code under 0.13, nothing should break per se, right? And if you see warnings now, that's the stuff that will break in 0.15 but works for now.
  - spicyj 11y ago
    Yes, with the exception of the React.initializeTouchEvents() removal and the ReactTestUtils change I noted.

zkhalique 11y ago

I have a question, why is dirty-checking so great? Whether it's Angular doing dirty-checking in the $digest cycle or React walking the virtual DOM and doing dirty-checking? Why not just subscribe to events and update things when the model changes? That would seem to be far more efficient, and also make clear the mapping of dependencies of views on data.

draw_down 11y ago
React does not do dirty checking.
- pkozlowski_os 11y ago
  Well, it kind of does when comparing virtual DOMs before and after changes.
  - danabramov 11y ago
    Usually people say “dirty checking” when they mean “keep checking in some kind of event loop whether external entity modified some object, and if so, do something”. In React there's no such event loop where it checks virtual DOM—React knows if it needs to compare virtual DOM trees (not arbitrarily check models for changes, for example) because all changes are explicit and happen either due to `setState()`, `forceUpdate()` or `React.render()` top-level call. So React doesn't do dirty checking in the sense Angular does, unless by dirty checking you mean all kinds of comparisons.
    - pkozlowski_os 11y ago
      Right. I guess it really depends how people define "dirty checking". What I was trying to say is that at the end of the day you do diffing on some data structure: model in Angular and virtual Dom in React. Loop vs. one pass is an important distinction, agreed. But when we bring Angular we should be noted that Angular 2 doesn't do those checks in a loop but does comparisons in one pass only.

oblio 11y ago

Is there some sort of React component repository or something?

clessg 11y ago
http://react.parts/web http://react.parts/web and http://react-components.com/ http://react-components.com/
- hliyan 11y ago
  Thank you so much for this! http://react.parts/web http://react.parts/web is very useful (particularly that it shows stars and download counts next to each component entry).
tracker1 11y ago
Would start with npmjs.com, either a direct search or a site specific search with google. https://www.npmjs.com/search?q=react%2C+component https://www.npmjs.com/search?q=react%2C+component https://www.google.com/search?q=site%3Anpmjs.com+react%2C+component https://www.google.com/search?q=site%3Anpmjs.com+react%2C+co...

crudbug 11y ago

Are there any good component libraries for React ? JSF ecosystem is a good example of component based web UIs.

suchitpuri 11y ago

Well i think it will take some time for libraries and components to be updated. For me currently at least react router should provide a compatible build with react 0.14