React JS Best Practices • Hacker News Board

Re: React JS Best Practices

#51

Post by dynamic » Sat, May 09, 2015, 2:31 PM UTC

mushishi wrote: post #49

girvo wrote: post #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 stor…

What does isomorphism mean here? I know what it means in mathematics, but the explanation in flummox site does not compute for me.

It's a term used to refer to applications that run some of the same code client-side and server-side. See: http://isomorphic.net/

Re: React JS Best Practices

#52

Post by STRML » Sat, May 09, 2015, 3:16 PM UTC

dandelany wrote: post #18

lobster_johnson wrote: post #17

Earlier quoted context omitted.

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.

This is the right answer. This will effectively keep React from touching the element ever again after the initial render.

Re: React JS Best Practices

#53

Post by UUMMUU » Sat, May 09, 2015, 3:27 PM UTC

lopatin wrote: post #2

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

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?

Re: React JS Best Practices

#54

Post by lopatin » Sat, May 09, 2015, 3:29 PM UTC

rektide wrote: post #11

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…

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.

Re: React JS Best Practices

#55

Post by spicyj » Sat, May 09, 2015, 3:32 PM UTC

nulltype wrote: post #3

I'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?

You can choose not to use the React component abstraction at all and just re-call React.render(makeElements(state), el) at the top level each time your app changes (using pure functions to generate the tree). Our plan is also to support pure functions directly for components that don't rely on state.

You can also use the component abstraction but choose not to use getInitialState/setState -- but our goals are to provide a component abstraction that is flexible enough to meet people's needs while still being restrictive enough for us to build higher-level optimizations around them.

Re: React JS Best Practices

#56

Post by spicyj » Sat, May 09, 2015, 3:38 PM 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…

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 ;
    },
    componentDidMount: function() {
      googletag.defineSlot('/1234567/sports', [728, 90], this.state.id);
    },
    componentWillUnmount: function() {
      // Clean up the slot and any other resources here
    }
  });

and then not worry about it.

Re: React JS Best Practices

#57

Post by yblu » Sat, May 09, 2015, 4:15 PM UTC

girvo wrote: post #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 stor…

I wonder how everyone takes care of error handling in Flummox (or Flux in general)? Would you also trigger an action, then wait for the store to set some sort of error state?

Basically, how would you migrate the following code to Flux:

  click() { doAction().catch(err => showModal(err)) }

Re: React JS Best Practices

#58

Post by tel » Sat, May 09, 2015, 4:23 PM UTC

girvo wrote: post #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 stor…

This is probably obvious but why is the existence of singletons what destroys "isomorphism"?

Re: React JS Best Practices

#59

Post by straws » Sat, May 09, 2015, 4:31 PM UTC

Swizec wrote: post #4

nulltype wrote: post #3

I'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?

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.

Actually, custom getters and setters exist in ES5:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

AmpersandJS, for example, implements its observable pattern in this way:

http://ampersandjs.com/learn/state

That said, I don't think the pubsub/rx/observables pattern is the most optimal for UI development, since it still allows for cascading event chains. Modeling all application state as a large data structure that allows for efficient diffing — which nicely mirrors the diffing react does with both it's internal component tree and diffing with the DOM — is a much more straightforward approach. Just re-render your application 60 times a second, like a game engine, and make that process as efficient as possible.

Re: React JS Best Practices

#60

Post by straws » Sat, May 09, 2015, 4:50 PM UTC

yblu wrote: post #57

girvo wrote: post #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 stor…

I wonder how everyone takes care of error handling in Flummox (or Flux in general)? Would you also trigger an action, then wait for the store to set some sort of error state? Basically, how would you migrate the following code to Flux: click() { doAction().catch(err => showModal(err)) }

Great question! Actions should be thought of as a mapping between some mechanical UI event (typing in a form, clicking on a button) and an event with some meaning in your application ("user typed a hacker news comment", "user submitted a reply to this comment with this text"). Whatever your application data store abstraction is, it should be responsible for taking that meaningful event and figuring out what to do with it (check to see that the message isn't empty, check to see that the comment was persisted to the server).

Actions describe things that happened in the world and the role of your store is to figure out if that thing that happened is valid or not, and pass the necessary data to components listening for changes.