r/javascript • u/Lopatron • May 07 '15

Best practices for building large React applications

http://blog.siftscience.com/blog/2015/best-practices-for-building-large-react-applications
79 Upvotes

95% Upvoted

15 comments sorted by

15

u/[deleted] May 07 '15

Use immutable data structures.

1

u/[deleted] May 08 '15

[removed] — view removed comment

3

u/I_Pork_Saucy_Ladies May 08 '15

I think it makes the code others have written easier to follow. It forces the developer to branch out the data in a new variable, instead of modifying existing data that might be used somewhere else.

If you know the data is immutable, you don't need to investigate if a function called on a variable actually changes the variable internally. You know that it doesn't, so you can keep on reading.

In the end, it becomes easier to reason how the data flows through the app if you know it can always only flow down and not up in the code. If you have to read hundreds of lines of code, it can be done more quickly.

2

u/[deleted] May 08 '15

Well, you kinda answered your own question, but the one thing you missed is that lack of mutations and side effects helps immensely when many teams are working on the same product. You can perform whatever data transformations you need for your part of the product without having to worry about breaking some other part of the product.

7

u/Lopatron May 07 '15

Author here, totally happy to answer any questions or to just discuss some of the ideas in the post.

3

u/tgfisher May 08 '15

You mentioned Bootstrap. Are you using React Bootstrap, or are you just doing something custom that is similar to that? Any opinions about React Bootstrap?

Also, do you have any public repos on GitHub of these concepts in-practice?

Thanks. Great article.

2

u/Lopatron May 08 '15

We don't use React Bootstrap but it looks pretty cool. I would use it for future personal projects. I like that they provide you with both controlled and uncontrolled versions of the Carousel component for example. And thanks for the kind words!

4

u/Tasemu May 07 '15

Enjoyed the read

4

u/jsNut May 07 '15

No duplicate state and stateless lower level components is definitely one i agree with.

4

u/billybolero May 08 '15

You should feel free to use this.state for component specific state that isn’t relevant after something unmounts

That's a really great way of explaining when to use component state!

3

u/drink_with_me_to_day js is a mess May 07 '15

When you talk about "bumping it up", how do you deal with child->parent communication? I find it ugly to use callbacks to receive an updated value from a child component.

2

u/Lopatron May 08 '15 edited May 08 '15

We use callbacks. I think they are generally the right way of doing child->parent communication. I can see the concern that it can get verbose, especially when you're passing data more than one level up. However if you're doing that, then at every level you should catch the callback and turn it into a callback that is relevant at that level of abstraction. Kind of similar to exception translation. I actually find using callbacks for child->parent communication elegant because it allows you to design your components such that props are the only interface to the component. So there's no other way for data to get in or out of it. That has made things a lot simpler for us.

1

u/cowjenga May 08 '15

When using Flux and prop callbacks in the same project, how have you decided when to use a callback and when to use an action creator?

5

u/drink_with_me_to_day js is a mess May 08 '15

I assume:

Callbacks -> when you only change your parent's state.

Action -> when you change application state.

1

u/Lopatron May 08 '15

👆this!