What are the best resources for someone looking to learn react and jsx?
Other than the docs: https://github.com/ryanflorence/react-training
React Tips and Best Practices
21–30 of 42 posts
Re: React Tips and Best Practices
#22One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-... Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will…
I think one thing that's misunderstood about Flux is the store model distinction. Coming from MVC, it's a pretty easy mistake to make, but stores _are_ effectively global state objects: You can access a store's state from any component -- whether that's good practice is doubtful, but it can be done -- and even though you have to call that store's getter in particular, it's not really that different from requesting state from a global object. (As the article hints at, Om makes it even clearer that stores handle global state in the app-state atom.)
All of that is to say that I think Flux-y architectures can help with reasoning about GraphQL's and Relay's data handling, which I think is seconding your opinion, even if it's quibbling a bit with how annoying driving stick (or working in Flux) is. :)
Re: React Tips and Best Practices
#23Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?
It's a good point. But don't mistake Flux, GraphQL, cursors, etc. with React.
React is just a great, fast way to interact with the DOM, with much less hoops than usual.
I think the community is still converging toward the proper way to deal with state. First it was passing callbacks, then the Flux pattern, and now there's talk of how GraphQL and Relay fit in.
And speaking of functional approaches, there are those of us who have been inspired by the Clojurescript community (who was in turn inspired by Haskell, as I understand it) and are interested in using cursors (similar to lens) to encapsulate state.
Re: React Tips and Best Practices
#24One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-... Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will…
That was my initial thoughts when Relay/GraphQL were announced, but it seems that though Relay is inspired by Flux it is somewhat different. Facebook's most recent post on Relay and GraphQL (http://facebook.github.io/react/blog/2015/02/20/introducing-... - February 20) addresses Relay's relation to Flux at the end and mentions that Facebook actually has apps using Flux and Relay.
Re: React Tips and Best Practices
#25Data passed to the controller view should be state from stores, not props. read the docs plz.
Re: React Tips and Best Practices
#26One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-... Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will…
Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.
Re: React Tips and Best Practices
#27Great article. One thing I would like to mention is that using component state (this.setState) is okay ! Central stores, and the flux architecture, are very helpful but if your state shouldn't persist after an unmount, there's no point in extracting to a central store and passing it through your entire app as props. (i.e. Whether or not a certain dropdown is expanded). Just keep that state local.
My point was that the state of the dropdown is something that perfectly fine to manage directly in the component (nothing else needs to know about it). Things like the selected value would not be something to manage using component state.
Re: React Tips and Best Practices
#28Alternatively, there is a very similar example, including a talk, right from the source: https://github.com/facebook/flux/tree/master/examples/flux-c... https://facebook.github.io/flux/docs/chat.html#content
Sorry, wrong react thread - and I cannot delete this post.
Re: React Tips and Best Practices
#29Let's be real. It's 2015 and we need quite some hoops to get, in most cases, some very simple data rendered on the screen. And even with all those hoops, we are still not sure that it works in all cases. Isn't it time for better tools than react? Like functional languages that support incremental computation?
It is always an adventure, to discover what will be on the other side of the phrase "Let's be real".
Re: React Tips and Best Practices
#30Data passed to the controller view should be state from stores, not props. read the docs plz.
That's only true if you're following the canonical Flux architecture to the letter. There's little difference between having your store trigger setState() on a root component and having your store trigger React.render() with new props.