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!
That's pretty much it! Although the ideas presented here do make sense (https://speakerdeck.com/vjeux/react-css-in-js) we haven't gotten there yet. Our css namespacing scheme solves the "global namespace" issue, which was the biggest issue that stood out for us.
Nice, we're actually posting a tutorial in a week or two about how we use d3 + react. I'll try to summarize though.
In the case that a library modifies the DOM, we try to keep React out of it's way. React works best when it has full control of the DOM. In these cases, React components are more of "wrappers" for the 3rd party libraries. Mostly by using the componentDidMount/componentWillUnmount to initialize/destroy the third party library, respectively. And props as a way of giving the parent a way of customizing the behavior of the third party library that the child wraps.
We use Google ads in our React apps, and it turns out to be a problem. I wonder if anyone has solved it in a satisfactory way.
Basically, with GPT you have named slots identified by their DOM element IDs. You can "refresh" a slot any time, which will populate the element if it's empty, or load a different ad.
So we do that when we're mounted. Unfortunately, if the page structure changes, React will re-render the component and blow away the contents -- anything GPT has put in the element is considered alien.
That's fine, we just refresh. The problem is knowing _when_ a render has finished and the ad element is empty. In my testing, React elements would often have a delay after which their changes have been applied to the DOM; so I use setInterval to check repeatedly for an empty element. It seems like a stupid solution, but I couldn't figure out a more solid way; there's no React callback for completed renders.
Seems to me you could wrap ad elements in container components that have:
shouldComponentUpdate() { return false; }
Which would prevent React from re-rendering them after initial mount... any reason why this doesn't work? I do this often when using d3 selections to keep React out of the way and catch incoming props in componentWillReceiveProps instead.
I'm intrigued as to why you think this approach is better than using a key? The 'shouldComponentUpdate' way of doing things means any changes to props or state on the component have to be handled manually, which can introduce a lot of non-trivial and overly complex code.
Do you have the 'key' prop specified on these components? React uses the key to keep track of a particular element. If you specify your own unique key, react will know that the dom representation of a component matches your react instance, and thus not replace the dom element when changes happen in a parent component (apart from if the component or parents are completely unmounted).
Without the implicitly set key, react creates its own index, so if a change happens in the hierarchy above your component, a new key might be given by react, causing the dom element to potentially be replaced when rendering.
Never used Google Ads, but you should be able to do something like
var GoogleAd = React.createClass({
getInitialState: function() {
return {
id: makeUniqueId()
};
},
render: function() {
// Since this is always the same, React won't try to change the contents
return <div id={this.state.id} />;
},
componentDidMount: function() {
googletag.defineSlot('/1234567/sports', [728, 90], this.state.id);
},
componentWillUnmount: function() {
// Clean up the slot and any other resources here
}
});
It would probably be good to supply a `key` property to the div to ensure that React never tries to reuse it (say, when changing from one GoogleAd to another).
Can you somehow use store to... store the ads? Like use getInitialState() to load the ads and use render() to just display it. I feel that you want to use regular MVC, while in React you should think of one-directional data flow (flux architecture). I probably don't understand the problem here, maybe if you would provide more details/some code I/somebody could help.
I noticed in your first code example you use a mixture of leading a method with an _ and some without. Ex. navigateToContact vs _hasUnsavedChanges and _saveChanges. I read somewhere that a best practice is to always prefix custom methods with _ to differentiate from React core methods. What're your feelings on that?
Oh this is definitely a personal preference thing, but our convention is this: private instance methods start with an underscore, public instance methods have no underscore. Public ones have no syntactic difference from the core life cycle methods but that's ok to me because they're all easy to remember. Btw we use public instance methods very sparingly, basically as a last resort when all else fails.
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?
Thanks! Glad to hear it was easy to follow and didn't ramble. Our backbone model cache is a simple module that you request backbone model instances from by a unique key. You also pass initialization options in case it doesn't exist in the cache. The instance will be constructed, saved in the cache, and returned. You can pass a TTL also. It's not great, feels clunky, but it works.
React is supported by a ton of goodwill from a lot of camps. What you offer here seems like some particular experiences you had. To say it's a best practice because it explains your world feels to me laden with folly. Linking a particularly wishy-washy state v.s. props article in core docs as if it's the final gospel- reeks of finding easy convenient idols to call out that make you sound better- it sells your article with a notion of completeness, declares a kind of finality. Nearly every point raised comes to me more as a question, a thing we have some rough anecdotes to tell, rather than something actually informative or much less definitive. I'll just start walking down your article's core bullet points.
Use componentShouldUpdate well: yes, do. You'll know why you should, quickly enough.
State v.s. props is a great point, but then you need both declarative managed injection via props to initialize or control, mixed with a transient stateful interactivity when the user begins free interactions. Early experiments in "best practices" are efforts like React-Controllables, trying to create components which are isomorphic to state v.s. props driving them.
Everyone is doing their own experiments with how and where data lives and how and where it gets there. That's the nature of webdev, experimenting with pipes. Some cursory words on Flux in your article indicate how vastly unresolved and mysterious the ???->data part of the webapp equation is. "We're experimenting with something Relay like". So way Soundcloud in 2012. Best practice: use react for the next step, data->html.
Best practice: wrap the most boring boilerplate css with your own react components. Oh great, just what everyone needs to go do. Recommendation is to not rely a lot on css, but how, if not global, do we start sharing some style rules effectively? It's disingenuous to offer this as settled "be balanced" best practice, particularly when it's still the hay days of excitement, with new encompassing visions like https://github.com/petehunt/jsxstyle/ just popping up.
It looks like you're bucketing the ideas in the post into one of two categories. Either 1. Too obvious to write about or 2. Not a best practice because new ideas are always being introduced.
Regarding the first, those topics weren't obvious to everyone. Besides no one really benefits when posts are called out for this.
And re the second, these patterns have emerged from one year of maintaining a large app with a growing team. The points mentioned are tips for writing code so that your app will scale, not silver bullets for complex topics such as the general question how to write styles for React. The best practices mentioned in the post are just that, but they're not the only ones.
