6 ms·

Author here, happy to answer any questions or discuss further!

by lopatin 11y ago

nulltype 11y ago
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"?
- lopatin 11y ago
  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.
  - nodejsisbest 11y ago
    This is a, well, dick off account but behind it is really a genuine developer. I recently converted my React code from scss to the embedded styles in JavaScript. Does each component have that many scss styles to justify using scss? I guess my project isn't such a large scale, but I'm just curious as to what benefit you get from scss. Note that I didn't read the article. I rarely do, but I'll give this one a go because well, I'm commenting on the gosh darn thing so I may as well stop being a fucktard and read the damn thing! EDIT: Well, you only mention scss once in the entire article. I guess I didn't learn much on why you use it vs. just using the embedded styles for components in React.
  - rattray 11y ago
    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!
    - lopatin 11y ago
      That's pretty much it! Although the ideas presented here do make sense (https://speakerdeck.com/vjeux/react-css-in-js 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.
      - nulltype 11y ago
        I like the vjeux thing, I think for dynamic sites if we replace static html and css with javascript the world will be a better place.
vanadium 11y ago
Got a FOUC (especially on the webfonts) the first couple of renders on the page; looks like the overloading of the META tags might be to blame. Otherwise, really good stuff here as someone rapidly picking up on React.
- noahgrant 11y ago
  Were you looking at the siftscience.com marketing site or the Sift Science console?
rektide 11y ago
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/ https://github.com/petehunt/jsxstyle/ just popping up.
- lopatin 11y ago
  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.
nthitz 11y ago
Hi, how does React work with other libraries that modify DOM state arbitrarily? How might d3 dom changes or canvas context calls work with React
- lopatin 11y ago
  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.
  - lobster_johnson 11y ago
    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.
    - dandelany 11y ago
      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.
rattray 11y ago
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?
- lopatin 11y ago
  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.
UUMMUU 11y ago
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?
- lopatin 11y ago
  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.
  - UUMMUU 11y ago
    Awesome. Thanks again for the write up. I love reading well written Javascript.

Author here, happy to answer any questions or discuss further!

by lopatin 11y ago

Author here, happy to answer any questions or discuss further!

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"?

lopatin 11y ago
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.
- nodejsisbest 11y ago
  This is a, well, dick off account but behind it is really a genuine developer. I recently converted my React code from scss to the embedded styles in JavaScript. Does each component have that many scss styles to justify using scss? I guess my project isn't such a large scale, but I'm just curious as to what benefit you get from scss. Note that I didn't read the article. I rarely do, but I'll give this one a go because well, I'm commenting on the gosh darn thing so I may as well stop being a fucktard and read the damn thing! EDIT: Well, you only mention scss once in the entire article. I guess I didn't learn much on why you use it vs. just using the embedded styles for components in React.
- rattray 11y ago
  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!
  - lopatin 11y ago
    That's pretty much it! Although the ideas presented here do make sense (https://speakerdeck.com/vjeux/react-css-in-js 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.
    - nulltype 11y ago
      I like the vjeux thing, I think for dynamic sites if we replace static html and css with javascript the world will be a better place.

vanadium 11y ago

Got a FOUC (especially on the webfonts) the first couple of renders on the page; looks like the overloading of the META tags might be to blame. Otherwise, really good stuff here as someone rapidly picking up on React.

noahgrant 11y ago
Were you looking at the siftscience.com marketing site or the Sift Science console?

rektide 11y ago

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/ https://github.com/petehunt/jsxstyle/ just popping up.

lopatin 11y ago
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.

nthitz 11y ago

Hi, how does React work with other libraries that modify DOM state arbitrarily? How might d3 dom changes or canvas context calls work with React

lopatin 11y ago
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.
- lobster_johnson 11y ago
  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.
  - dandelany 11y ago
    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.

rattray 11y ago

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?

lopatin 11y ago
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.

UUMMUU 11y ago

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?

lopatin 11y ago
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.
- UUMMUU 11y ago
  Awesome. Thanks again for the write up. I love reading well written Javascript.