I would love to see their HoverCard and similar components open-sourced, or at least shared in a gist. Many of their abstractions sound great & generalizable.
React JS Best Practices
21–30 of 92 posts
Re: React JS Best Practices
#22I'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?
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?"
Re: React JS Best Practices
#23Earlier quoted context omitted.
In the article you say you "Reuse through React instead of CSS" and that you have CSS files for the components and no global CSS classes. Do you mean that the CSS files are applied to the elements as inline styles by react, or just that each component has its own CSS so it's not really "global"?
The latter. Most of our components have an associated scss file. I didn't consider those to be global because we namespace all css rules in the style files under a class name of the same name as the component. But that's a great point, it didn't occur to me that that paragraph may have only made sense to people familiar with our conventions.
Interesting. Asking out of curiosity, not skepticism: why not use react styles in js directly, à la vjeux et al?
Reasons I'd guess: not being able to use pseudo-selectors and things like :hover; familiarity for designers; easier use of legacy code; benefits of SCSS that would take work to re-implement in js. But I'm curious what your real reasons were!
Re: React JS Best Practices
#24> Flux is also quite verbose, which makes it inconvenient for data state, state that is persisted to the server.
We felt the same way, until we moved away from Facebook's Flux implementation and adopted Flummox[0]. It's singleton-free, so we gained isomorphism for our application with only a tiny bit of extra work, and it hides away the dispatcher (unless you need it, which we haven't despite having over a dozen stores, tonnes of actions and a large number of components).
With Flummox making it so easy, we put all state into a store. This allows us to save application UI state to localStorage, bootstrapping the app into the same position the user was previous, with again no extra effort on our behalf. It's well worth checking out!
Re: React JS Best Practices
#25Author here, happy to answer any questions or discuss further!
Great article, thanks for sharing! Would have loved a few code samples to go along but your descriptions did an impressive job describing what's going on.
One question: what does that "global Backbone cache" look like?
Re: React JS Best Practices
#26Having just started using React for a new project, I absolutely love it. This new project uses a Rails backend, with React allowing the web to act the same way as any other client (iOS app, Android app etc), and it's so productive to work in. Pretty much decided I won't be writing a web app any other way for any future work. These best practices look pretty good, though my advice to any beginners would be to not get…
>Pretty much decided I won't be writing a web app any other way for any future work.
Careful what you wish for!
Re: React JS Best Practices
#27I would love to see their HoverCard and similar components open-sourced, or at least shared in a gist. Many of their abstractions sound great & generalizable.
Open sourcing a library of components would be fantastic.
Re: React JS Best Practices
#28Earlier quoted context omitted.
Seems like .observe() would fix that polling thing, right? 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.
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/ys...
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.
Re: React JS Best Practices
#29Earlier quoted context omitted.
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.
Seems like .observe() would fix that polling thing, right? 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.
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".
Re: React JS Best Practices
#30One of my initial problems with React & CSS was styling :hover etc. For now, Radium [0][1] solves this problem, but IMO as a community we're still trying to figure out all the best practices and patterns, when it comes to building isomorphic webapps (or webapps is general, since React introduces new way of building apps and I'm sure that's just the beginning).