React JS Best Practices • Hacker News Board

Re: React JS Best Practices

#11

Post by rektide » Sat, May 09, 2015, 5:56 AM UTC

lopatin wrote: post #2

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

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.

Re: React JS Best Practices

#12

Post by nthitz » Sat, May 09, 2015, 5:56 AM UTC

lopatin wrote: post #2

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

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

Re: React JS Best Practices

#13

Post by lopatin » Sat, May 09, 2015, 6:02 AM UTC

nulltype wrote: post #9

lopatin wrote: post #2

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

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.

Re: React JS Best Practices

#14

Post by cgag » Sat, May 09, 2015, 6:05 AM UTC

nulltype wrote: post #5

Swizec wrote: post #4

Earlier 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.

Observe just makes making bad apis easier imo. I don't care if react can detect state changes, I want to detect state changes by searching for setState.

Re: React JS Best Practices

#15

Post by lopatin » Sat, May 09, 2015, 6:12 AM UTC

nthitz wrote: post #12

lopatin wrote: post #2

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

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

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.

Re: React JS Best Practices

#16

Post by nodejsisbest » Sat, May 09, 2015, 6:27 AM UTC

lopatin wrote: post #13

nulltype wrote: post #9

Earlier 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.

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.

Re: React JS Best Practices

#17

Post by lobster_johnson » Sat, May 09, 2015, 6:45 AM UTC

lopatin wrote: post #15

nthitz wrote: post #12

Earlier quoted context omitted.

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

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 t…

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.

Re: React JS Best Practices

#18

Post by dandelany » Sat, May 09, 2015, 6:58 AM UTC

lobster_johnson wrote: post #17

lopatin wrote: post #15

Earlier quoted context omitted.

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 t…

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 comp…

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.

Re: React JS Best Practices

#19

Post by iyn » Sat, May 09, 2015, 7:20 AM UTC

lobster_johnson wrote: post #17

lopatin wrote: post #15

Earlier quoted context omitted.

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 t…

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 comp…

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.

Re: React JS Best Practices

#20

Post by iyn » Sat, May 09, 2015, 7:23 AM UTC

nthitz wrote: post #12

lopatin wrote: post #2

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

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