loading...

React Beginner Question Thread ⚛

dan_abramov profile image Dan Abramov ・1 min read

Hey folks! My name is Dan, and I work on the React team.

I really like the idea of semi-regular “beginner threads” where people can ask simple questions without getting judged. This seems like a great community so I thought: can we try this here? 🙂

We run a thread like this on Reddit but to be honest I'm finding Reddit hard to use and very impersonal so I don't hang out there much.

The rules are simple:

  1. One question per comment.
  2. The questions have to be about React.
  3. No question is too simple! Seriously, ask away, I don’t bite.
  4. Try to keep questions to a few paragraphs at most. If you need a code sample, put it in a gist or, better, a sandbox.
  5. Please reply to the questions too if you know the answer! I might not be able to reply to all of them although I’ll do my best for this thread.

Note this is an experiment. 😉 I don’t know if enough people here are React users, and if the format is a good fit for this website. If that’s not interesting to you folks that is fine too. Cheers!

Discussion

markdown guide
 

Hello Dan.

I'm a React learner and right now I've digested only the basic stuff. How should we approach to shouldComponentUpdate? Some people, including my friends who have more experience than me, say "consider using it always" since without using it there is so much unnecessary render around and that slows the application. Even one of my friends showed me a real use case of it and his application slows down very much without using it.

The official documentation says "The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior."

Should not I use it?
Should I use it when necessary? For example after measuring the performance?
Should I design my application wisely so every render does not slows it down dramatically then shouldComponentUpdate will be unnecessary?

I've read some suggestions but I also want to hear yours.

Thanks.

 

In my personal experience you should use it only when it's necessary. I found using it almost always a solution to another slow thing. Let me give you a real example:

In a project I worked there was a list of comments (similar to this same list), it rendered 10 comments with all of his sub comments and then using infinite scroll it was loading more comments (and sub comments), but the render was too slow, specially after I loaded more pages of comments (the second time I loaded more comments the page took 10 seconds to update, in that time it was completely blocked).
My first attempt was implement shouldComponentUpdate for each component, and it worked, but after deploying that I investigated more and discovered the code was applying highlight.js to the whole document after each component was rendered and in a sync way, this was causing the super slow render.
So I could have used shouldComponentUpdate and call it a day, but if I did that I was never going to found the real issue.

React is already trying to update the DOM as little as possible, so you don't really need to care about your render method being called many times because it should be fast enough. Also implementing shouldComponentUpdate in any component could cause some unexpected issues like this:

You have a component A rendering a component B, both components are stateful. If A is a PureComponent (or manually implement shouldComponentUpdate) and B change it own state since A is not being updated (its state and props didn't changed) it's going to say that it does not need to update, which cause B not to update (because the React's rendered is going to stop traversing the internal component tree of A).

Another possible issue of using shouldComponentUpdate always is that you're adding more logic which need to be run every time something update, e.g. if your render method take let's say 100ms to render and now you need to run another 100ms logic inside shouldComponentUpdate to check if it should render it means you're still going to wait 100ms always and if the component needs to update it going to take 200ms to do it. Now imagine this everywhere.

tl;dr: only use shouldComponentUpdate if you measure you really need it and not always.

 

^ I agree with this. I’d also note you probably want to use PureComponent when you optimize instead of manually writing shouldComponentUpdate. Then verify with React DevTools (“highlight updates” checkbox) and Performance tab in Chrome (“User Timing” section) that the components don’t re-render anymore. Because the worst thing you can do is to add a shouldComponentUpdate but not verify that it actually bails out when expected.

Thank you for your answer Dan. I am definitely going to consider using PureComponent instead of shouldComponentUpdate, if I need it of course.

 

I'm provably misunderstanding something when you said:

You have a component A rendering a component B, both components are stateful. If A is a PureComponent (or manually implement shouldComponentUpdate) and B change it own state since A is not being updated (its state and props didn't changed) it's going to say that it does not need to update, which cause B not to update (because the React's rendered is going to stop traversing the internal component tree of A).

Why should B not update? Is this what you meant? codesandbox.io/s/ol4zllpj19

 

Thank you for this good, detailed answer. So, I won't consider using it unless I'm certain of it makes the application better. Using like a very sharp knife, use it only when necessary :)

 

Dan, please clarify on the use cases of PureComponent other than stateless components. My understanding of PureComponent is that if misused, will slow down the application rather than making it faster. Since PureComponent will diff the changes before rerender.

 

Use PureComponent when you have performance issues and have determined that a specific component was re-rendering too often, but its props and/or state are shallowly equal.

reactjs.org/docs/optimizing-perfor...

Thank you for the clarification Dan.

 

Do you work on React full-time? You seem so busy addressing people’s questions and complaints on Twitter 😅

 

Yeah, I work on React full-time. I suppose engaging with community can be considered a part of it although I mostly do it because I enjoy that, and it doesn’t take that much time to shoot a few tweets back.

 

Here goes another one: what would you recommend as initial steps to participate in React as open-source collaborator?

Thanks again!

 

First, just use React 🙂 You will notice bugs, pain points, etc.

Then, I encourage you to try helping people in the Issues section. A lot of those are just support requests or misunderstandings, but some are legitimate bugs. Even helping verify those bugs and creating minimal reproducing examples is a hugely valuable contribution. Answering React questions on StackOverflow is also a great contribution and grows your experience with the library.

Finally, keep track of the "good first issue" label in the repository. We use them to tag issues that we think are good entry points into helping with React.

I hope it helps!

 
 

Could be a silly question since I have not used React much. Recently i saw a code base using react and could not find much of unit testing. But there are lot of "snapshot" testing with Jest. I think that Jest internally compare a previously generated text output with current and break the test if it is different. But i don't think "snapshot" tests can totally replace unit testing since "snapshot" tests can't really test interactions isn't it?

Also how "snapshot" tests fit in to TDD?

Thanks.

 

Snapshot tests aren’t meant to replace unit testing. They’re complementary. I suggest using snapshot tests for cases where otherwise you wouldn’t have written any tests at all.

People have different opinions about how much unit testing is useful for components. When I was building products with React I didn’t write unit tests for components at all because they were changing too often, and adjusting tests all the time would slow me down. And if some logic is complex enough to be worth testing I would extract it out of the component anyway. I also definitely didn’t use TDD for components (my personal opinion is that TDD isn’t very useful for UI code in general).

But this is tradeoff is different for every team. Some teams find more value in unit testing components. You definitely can do this with React—either with react-test-renderer or enzyme. It is up to you to decide how to balance unit tests with integration and snapshot tests in your app.

 

Thanks for the rapid response in the Christmas day! Another question regarding HOC. How HOC is different from decorator design pattern?

I guess it’s a React-specific variation on it?

Probably :) but I can't really confirm since I have not used HOC in depth.

 

But i don't think "snapshot" tests can totally replace unit testing since "snapshot" tests can't really test interactions isn't it?

A snapshot is simply a different way of performing an assertion, instead of using expect(...).toBe(...). You can write any type of test using snapshots.

 

That’s a great point, you actually can test interactions with multiple snapshots.

 

I'm a beginner in JS world . So What are the concepts that I should know to learn and use react easily .

Many of my friends said react is not actually a beginner friendly one . So they asked me to try angular or polymer etc...

Is that so ?

 

React is a very lean library that one can easily learn. As a developer worked with Angular JS and Angular>2 before, I felt react is less opinionated, fun and, easy to learn. The react's component based development is far more well thought than the AngularJS's two way data binding & controllers. Angular >2 is a very opinionated framework that takes a long time to master.

Beginners who try React for the first time easily gets scared by the diverse tutorials out there. They use things like JSX, ES6, Webpack, Redux which annoys beginners and creates a pseudo humongous learning curve. Instead, you(a beginner) can straight forward include react.js and react-dom.js in your HTML and start creating components(like Angular JS).

Read this book, if you have a chance:
shop.oreilly.com/product/063692004...

It teaches you react from plain JavaScript's view. After reading this, read the official docs and everything makes sense to you.
reactjs.org/docs/hello-world.html

For more tutorials on React, visit this.
github.com/markerikson/react-redux...

Note:
First, learn JavaScript well. If you are good at JS, understanding a library is an easy thing. Reverse may not be true.

 

I think it’s very subjective. I know a lot of people who learned JavaScript through learning React. I think the main difference is that React embraces JavaScript instead of trying to hide it from you. So you need to get comfortable with the language. The upside is you don’t just learn a library, but actually learn the language you’re working with 🙂

I don’t think you need to know much to get started. To feel comfortable you’ll want to understand JS syntax and concepts (functions, classes, binding).

Really, the only sure way to know is to start going though our docs (reactjs.org/docs/hello-world.html) and/or the tutorial (reactjs.org/tutorial/tutorial.html). Try it and see!

 

Agree with Dan (not that you need me to). React is more like Javascript than Angular (I've used both) and most other frameworks, it really does embrace Javascript. I also feel like React embraces functional programming which is a good way to build good habits.

I dove into React as a beginner and found it much more beginner-friendly than most other frameworks or libraries. Beginner friendly doesn't mean it does a lot of the lifting for you like other frameworks that might do more 'under the hood' (although it does quite a bit).

 

Is there any particular criteria to prefer class components vs functional components?

I've read many threads arguing about this, in many cases discouraging the use of ES6 classes in general (google "Eric Elliot class"). At least for me is a bit troubling since there are a lot of examples and documentation written using classes.

I have experienced some of the pitfalls of using class in other contexts outside React, although I do not discard these problems being a result of amateur coding skills on my part. Yet similar experiences are shared by more experienced developers.

I would like to hear your thoughts about this, and what is the position of the React team on this topic.

Thanks!

EDIT: Reading below I see that you already answered a very similar question, anyway I leave this one in case there is anything else you would like to add. Apologies!

 

The one thing I encourage you to avoid is inheritance hierarchies. I think classes are okay as a form of organizing code, but work really poorly as a way to reuse the implementation through inheritance. I wrote about this here.

If you just inherit from React.Component or React.PureComponent there’s nothing wrong about using classes. Certainly, they can be unnecessary if your component doesn’t have any state or lifecycle. In this case a functional component would use a tiny bit less memory. However, it is annoying to convert them back and forth when you want to add state and/or lifecycles later 🙂. So that’s really up to you—it doesn’t matter that much either way.

TLDR: don’t create your own React base component classes and hierarchies.

 

One notable difference between functional components and class components is that refs (references to underlying DOM elements) can't be used with functional components - has forced me to use a class a few times, even when the component has no state/lifecycle.

A small price to pay for a great library - awesome work Dan!

 

Hey Dan, what do you think about mobx and mobx-state-tree? As state management solutions. Actually I knew about mobx because you tweeted about it, but not sure if you are familiar with mobx-state-tree.

Thanks for all your hard work and patience to answer so many questions in so many places

 

I think it’s great that people find them useful! Personally I’m not a fan of APIs relying on mutability because they make certain fundamental problems harder. For example we’ll need to work with MobX to figure out how to keep them compatible with async rendering in future React versions. It’s probably solvable but mutability makes such problems harder.

I’m also not a fan of wrapping real JS objects and arrays into shims that pretend to be them. I understand why MobX does this but I’ve always considered the ability to work with “raw” objects one or the biggest strengths of React, and I don’t want to give that up.

As for mobx-state-tree, I haven’t looked much at it so I can’t really say. The “fluent” API style is offputting to me but that’s just a knee-jerk reaction so I may have missed important benefits behind it.

 

Is there a set of libraries that are recommended for people once they finish the official React tutorial?

I'm not talking Redux, but maybe React-Form, that sort of thing?

Once I know what I'm doing and start doing small PoCs and move from lear-how-this-works to see-how-productive-it-can-be, I'm not sure where to just go with React and maybe native browser promises / fetch / forms etc, or there're de-facto options that can speed me up and everyone is using, and I just miss on them because I don't know what I don't know.

 

I don’t know 🙃

When I started with the React ecosystem most of these libraries didn’t exist in the first place so I had to write my own components from scratch. That’s the best way to learn too.

For forms, I’ve heard people rave about github.com/jaredpalmer/formik so maybe I’d try that. For routing, I’d use React Router. As for other purposes, I’d probably start by trying to write my own, and if it takes longer than I want, picking something with the closest API to the one I imagined.

 

Hi, Dan!

Really nice of you posting this thread. Great questions, great answers.

One question from me:

Any plans on creating a router or approving some of the existing routers as the "React Core Team approved router"? Seems like this is painful part of the existing React ecosystem.

 

I think we’ve been fairly open about liking React Router 4 🙂 It’s not perfect for every situation but I’d recommend it as a default choice.

 
 

Does Facebook use React with Redux?

 

Some internal teams use Redux, I don't think there's any public-facing Facebook pages that use it though. Most internal apps use FluxReduceStore from facebook.github.io/flux/docs/flux-..., which is similar-ish.

 

When is it time to stop managing state at the component level and switch to something like Redux?

 

This is a tough one; I think it really depends on whether you consider your app a React app or a Redux app. It’s also kind of fluid: you might still use Redux-like reducers for implementing local state, like at the end of this article.

I might use Redux for:

  • Data caches (note: there might be better solutions than Redux for this)
  • Things that are like “global variables” (e.g. authentication)
  • Things that have very complex update logic (e.g. a multimedia post editor)
  • Things that many distant components care about
  • In general, when the state tree shape is too different from the UI tree shape

Note that these use cases can be divided into:

  • Variables that are annoying to explicitly pass down the React tree
  • Update logic that is too complex to express with a bunch of setState()s
  • Data fetching and caching

The first use case really just means React doesn’t have a good way to do “global-ish” updates that directly update leaf nodes in the tree. So people use Redux to work around it, but it’s not really Redux per se that is useful to them, but the ability to broadcast updates. We plan to solve this with a new officially supported context API.

The second use case is also not as much about Redux, but about the setState() API. It is hard to keep a component with dozen setState()s readable. Redux gives you a paradigm to split that logic into independent parts (reducers), but it’s not obvious to most people that you can apply the exact same approach to the React state. I think we can solve this by making React state API slightly different, and it’s something we plan to look at in the future.

The third use case just means React doesn’t have a good solution for simple data fetching. You don’t usually want to keep it in the state because the data needs to be cached between mounting and unmounting components. So folks use Redux for this. We have some fun ideas about how to solve this with a first-class data fetching API in React, so watch that space.

Finally, when would I really prefer to use Redux? When its tradeoffs are useful. For example, for complex workflows where I want to reproduce bugs by “replaying” user actions. For distributed games that benefit from expressing everything as serializable actions. For extensible APIs where we want to let user hook into the update logic, like in Hyper. Etc. Where it really makes a difference.

The most important part is that the paradigm (actions and reducers) is not “bound” at all to Redux-the-library. You can take your reducers and use them to drive React local state in individual components, or vice versa.

 

Thanks so much for your response Dan! Your community efforts are impressive and tireless :)

 

Thanks for the honest recommendation Dan!!

 
 

Only when you share the same data with another component, Redux comes in.

 

But isn't that just a case where you make the container of both hold the state and pass it down. I suppose when it gets more complex than that you'd use Redux.

Personally, I'd say correct. When it feels wrong, that's when a state management comes in.

 

When we use state and lifecycle methods, the component identity becomes important. On a form with two buttons, two instances of a Button component are independent because each has its own state, and may mount, update, or unmount at different times.

For better or worse, classes are how the vast majority of people think of “identity” in JavaScript (and many other languages). You can design your own bespoke system that creates objects through factories, uses prototypical inheritance directly and whatnot, but you’ll most likely end up with something that feels a lot like using classes. Except that it’s a dialect nobody else is familiar with so you have to educate your users about your pseudo-class system (and maintain it). This is basically why went away from the createClass() helper. We’re in a business of UI libraries, not class abstractions. Sebastian goes into this here: youtu.be/4anAwXYqLG8?t=21m33s.

We might not want to keep using classes forever though. They have their own problems (and I don’t mean stylistic ones). Our two big directions to explore in 2018 are async rendering and compilation. Classes make both of them harder because you can put any field on the this instance and mutate it at any given time. For async rendering, this is a problem because changes can be “stashed” and “reapplied” later (much like Git) but React only knows what to do with props and state rather than arbitrary objects you put on the instance. For compilation, this is a problem because classes are too hard to “fold” statically because you can just do too many things in a class.

So, considering these real issues, we might introduce a different, more functional API for components in the future. However, it is important that it will be informed by actual problems we experience with classes, and not just a stylistic or dogmatic preference.

 

Oooh acync rendering and compilation both seem exciting.

 

Welcome Dan, definitely a lot of React folks happy to have you around.

We run a thread like this on Reddit but to be honest I'm finding Reddit hard to use and very impersonal so I don't hang out there much.

This definitely jives with the reason we're here in the first place.

Note this is an experiment.

This is great. We'll be following this post for cues on how to build on this sort of post and any feedback from you or anyone is really appreciated.

Now for a question: What are your thoughts on Preact, how does the React team/community interact with spinoff projects like this?

 

What are your thoughts on Preact, how does the React team/community interact with spinoff projects like this?

I think it’s cool that people want to stay within the React paradigm even if their tradeoffs don’t match ours.

At Facebook, we typically use React for applications that are truly dynamic and need to scale well with the application size. We don’t use it for stuff like landing pages or extremely thin apps. So in our case the difference between 3 and 30 kB gzipped is less pronounced because the vast majority of the code comes from the application itself.

For our use cases, supporting older browsers consistently and having great runtime performance is more important. We're also still working on React, and as we enrich its capabilities we're hoping to bring down the repetitive code in the product (e.g. for data fetching). We think will be more impactful because, unlike the library, the product code keeps growing over time.

We don't really interact with these projects as much, but we hope they continue to be useful to the folks who rely on them, and will happily welcome these users back if they decide React better answers their tradeoffs later. 🙂

 

What is the best alternative of binding this in the constructor?

 

I tend to use class properties:

class Button extends React.Component {
  handleClick = (e) => {
    // no binding
  }
  render() {
    return <button onClick={this.handleClick}>hi</button>;
  }
}

Note they're not standardized yet. But they're so widely used that if the syntax changes or proposal gets dropped, there's definitely going to be an automated migration path (i.e. a codemod).

 

Although it looks quite cool I'm really not at ease with class properties because of how they could be confusing, scope wise.

A fat-arrow function is supposed to be bound to the lexical scope in which it is defined and that is very much not the case here, which could lead to some confusions.

I don't know exactly where to stand :D

We’ve been using them in production at Facebook for about a year now, and haven’t seen much confusion in practice.

 

As a React newbie this is a game-changer for me. No more headaches with debugging just because I forgot to bind this to functions in the constructor!

 

Can't believe how old this comment is now! I still check it all the time for syntax lol - It's literally become it's own google search for me! Thanks for the (probably)10+ times this has helped!

 

i go for following

  1. bind only if you need it in children Component or Event
  2. Re-using same function ? try to use "Call" if that becomes complex then use bind.
 

Hey Dan, thanks for doing this. What would you say is the latest best practice for approaching CSS/styling in React?

 

Liana, I don't know if this could be considered a "latest best practice", but it is something I've started doing for my own projects, which is to import CSS files as modules import "./component-style.css" inside the component file, then use Webpack to compile it.

You can avoid errors during testing using ignore-css module.

If you research a bit there are very interesting articles on the topic, and it has helped me to keep my CSS modular and clean.

You can even keep your CSS file close to your component.js and component.test.js files in the same folder, which for me at least is very practical when working on any particular component.

Hope it helps!

 

Or you can just use styled-components and all that will be very natural with zero dead CSS code :P

 

I'm not a Dan Abramov :D But still, react is lightweight library so I'm not sure that they will add any "CSS-in-JS thing" to it that is more complex than inline-styles that they have now.

About best practices now and what community is fascinated about is surely CSS-in-JS libraries.
Such as styled-components, jss, glamorous.

They have automated out all styles isolation problems keeping the ability to work with 3rd party CSS styled components.
At the end, we have:

  • perfect props dependent styling
  • isolation
  • styles encapsulation within the component

And many other things like discoverability of usage, modularization of the styles, so you don't have any unnecessary styling applied to the page, dead simple theming support, lot's of reusable functions, mixins, shortcuts and everything you can imagine cause it's just JS.

You can analyze it using way more tooling than CSS have, you can programmatically do tons of stuff etc.

If you want an example of usage of styled-components which is the most popular solution, for now, go ahead here.
codesandbox.io/s/21nx9pw8jr

I highly recommend styled-components.

About more traditional things, well, postcss with CSS modules and cssnext preset is a nice thing for old-fashioned people, but is way-way-way-way weaker than styled-components and jss and glamorous in terms of natural use with React and component way of doing things.

 

Hey! I don’t think there any “best practices” because the field is still evolving and there are many unsolved problems. If I were to create a project I’d probably still use plain CSS 😅 Facebook uses something similar to CSS modules (but with a different syntax) and that works okay-ish too. In side projects I’ve enjoyed using glamor but I don’t really have any opinions there.

 

What characteristics (if any) do you think describe apps for which React isn't suitable? I'm guessing particularly small/simple apps wouldn't benefit, but does anything else come to mind?

 
  • Apps where hundreds of things on the page constantly update at the same time over a very small interval. For example stock trading apps. You don’t need the expressiveness provided by React for most such apps, and optimized templates (e.g. Angular AOT, Glimmer) will be faster for these use cases because they skip the component abstraction.

  • Primarily static websites. However that really depends on how you use React. For example we actually do find it very helpful for the (mostly static) reactjs.org website but we can do this because we use it through Gatsby which generates a static website from React components. This is very different from just adding using client-rendered React components for everything.

  • Embedded widgets. By nature they’re supposed to be as tiny as possible, and there isn’t much of an “application” in them anyway. I guess you could use something like Preact but perhaps plain JS or something like Svelte would still be best for these cases.

 

Hey Dan, thanks a lot for doing this!

Are there any resources you would personally use if you were a standard React user who's trying to learn the library in-depth?

 

Depends on what aspect of React you're trying to learn. There's differences between trying to learn the core APIs, some of the flexible ways you can compose components together, or how React works internally.

The official React docs are the best place to start. After that, my React/Redux links list points to many good tutorials and articles to help learn React further. In particular, you might want to check out the React Component Patterns, React Component Composition, and React Architecture sections.

 

Agreed with that. There's also good community content here: reactjs.org/community/courses.html

 

How do you structure a container component in a React app that uses local state (no Redux)? Do you create a HOC for it?

 

I don’t quite understand the question. I think people take the distinction between “presentational” and “container” components waaaay too seriously. When I wrote an article about them I mentioned this is a pattern I noticed organically in a codebase, not a set of rules to follow.

If I were writing a component I wouldn’t think about whether it’s a “container” at all. I’d just write a component. It might use local state, or it might not. That doesn’t really matter to me. Later, I might split it into a few components, or I might actually “inline” it into a larger component if I realize it was extracted prematurely.

I would definitely not create HOCs except for very rare cases where a single HOC is useful across many many components. I would never create a HOC only for one component to use it.

 

Definitely check out github.com/acdlite/recompose/blob/... if you're into keeping everything an SFC, especially check out withStateHandlers.

 

I've done a lot of Web UI work in the past, but have yet to work with React. I'm familiar with the basics, but one question I haven't yet answered for myself is the Why of React.

So, in a nutshell, what would you say is the main problem that React is trying to solve?

I know that could get fairly philosophical, but I'm really looking for something just a level or two deeper than "It's better than X!"

Thanks!

 

Same problem that functions are trying to solve in regular programming languages, but applied to UI. Does this help? (Let me know if it’s too brief and I can expand. I was going for “a-ha” but maybe this just confused you more.)

 

Also unfamiliar with React and have read some stuff about it and been largely unsure and this summary is seriously golden in my book and legit seals it on me checking it out more--because that's an explanation that makes total sense.

 

Actually, if I understand what you're getting at, that helps a lot. I can definitely see the value in making the mental model of assembling a large, dynamic UI be similar to that of assembling a "normal" (for lack of a better word) program.

Thanks!

Yep, that’s about it.

The interesting difference from “normal functions” is that the “React functions” (we call them “components”) can be stateful. For example a Checkbox component doesn’t just “return” something unlike a normal function, but can be toggled on and off. We call this “state”.

The state in "React functions" (components) resembles C++'s local variables, defined inside functions using the static keyword. Such variables keep their value between function calls. If something similar existed in JS, you would be closer to being able to use functions to implement components exclusively, and avoid downsides of using classes that give you a hard time working on async rendering and compilation.

 

Do you have any plans for using ReasonML in react development any time soon?

 

If you mean in development of React itself, I don’t really see it happening over the next few years. It significantly raises the contribution barrier but being able to compile React itself into native code is not that valuable IMO. And a solid type system doesn’t really buy us that much with a relatively small React codebase. However, it may be valuable for something like WebAssembly in the future. So I don’t know.

If you mean for development of products with Reason, we’re already using React for Messenger. I don’t know if it will be used more widely in the future, we’ll see!

 

How does the React team work? Are you split up into multiple small teams that focus on a certain area? Do you have project/product managers? Who decides what you will be working on? Does the React team use Scrum?

By the way, really appreciate the time you take for answering questions and sharing your knowledge :)

 

Are you split up into multiple small teams that focus on a certain area?

The “React core” team takes care of the React repository and how it is used at Facebook. It currently consists of:

There are other teams that work on React Native, Relay, Jest, and other projects. We often chat with them but don’t work directly together.

Do you have project/product managers?

Yes, Sophie took over team management from Tom Occhino in the second half of this year. The manager’s job is to sit in the boring meetings with higher-ups so we don’t have to (at least that’s how I imagine it 😄), help with planning, remove roadblocks, and enable people on the team to do their best work.

Who decides what you will be working on?

Our main goal is to help developers create great apps. We have brainstorming sessions two times in a year where we consider what seems like most impactful things to work on next. They are informed by the challenges we see at FB and other companies using React, and by our own intuition. When we agree on the directions, there’s generally quite a bit of wiggle room on the specifics. At Facebook engineers are trusted to make their own decisions about what they think is valuable to do.

Does the React team use Scrum?

I don’t really know what Scrum is. We have a weekly hour-long team meeting where everyone gives brief status updates and then discuss anything that somebody on the team put on the agenda (e.g. some API decision, bug, etc). Everybody also has weekly 1:1s with their manager that last for 30 minutes. Apart from that, we don’t really have a lot of process around anything. Sometimes we do more specific meetings around a particular topic with folks from other teams at Facebook or our open source contributors.

 

Another question I had about the React team dynamic: Are you all at the same office location, or are some of you working remote?

Most of the team works together in Menlo Park (USA), but me and Dominic work from the London office (UK). We don’t really have remote positions at Facebook, but we do occasionally work from home if we don’t have any meetings.

Hello Dan and the rest of the Dev.to community!!

I am new to react and started with it last month. I searched for react tutorials and docs and related articles over the internet and found you contributing directly or indirectly somehow at all the great places I found.

Me and many more people appreciate your efforts! Thanks a lot and enjoy your holidays! :-)

 

Weekly 1:1s? And I thought my fortnightly 1:1s were too frequent 😂. Can you explain at a high level what kind of things you would talk about at your 1:1s?

  • What I’m working on
  • What I’m struggling with
  • What’s worrying me
  • What others are doing
  • Technical roadblocks, decisions, planning
  • Just chatting

I must use this list for my next 1:1. Thanks for answering and enjoy the holidays!

 

How do you bind Redux to React so the component would be updated when the Redux store change?

 

You use the react-redux utility with the mapStateToProps function, which does the thing as it's called, so that whenever the state (of the store) changes, the props changes as well. And it triggers the re-render of react components.

 

Thanks, Chang! I think I wasn't clear enough, I'm sorry! I meant the details of the implementation of such patterns.

Internally React Redux works by calling store.subscribe() when the component mounts. Every time the Redux store changes, the subscription callback fires. Inside it, React Redux calls React setState() by taking Redux store state and passing it through mapStateToProps().

Here’s a simple version: gist.github.com/gaearon/1d19088790...

Thank you so much! That's exactly what I wanted to know :D

Thanks Dan, the code example is really helpful. Also I found your video talk about react-redux very inspiring and straight-forward as well. For those who are interested, you can go to
youtube.com/watch?v=VJ38wSFbM3A. <3

 

For example I am working on a white-label product. And one component should look different for different environments. CSS and HTML also may differ. How would be a right way to make, kind of, interface for a component, and use a specific implementation for a environment.
I tried to make something like this, it seems to work. But is this the right way?

app.js
MyCmp/
  index.js
  env1.js
  env2.js
  ...

// index.js
const MyCmp = require(`./${process.env.MY_ENV}`)
export default MyCmp

// app.js
import MyCmp from './MyCmp'

process.env.MY_ENV gets assigned depending on env.

 

It's a pretty abstract question. It's not clear what you mean by "environments", what actually gets deployed, whether there is any common code (and if there is, what differs between environments). It would help to see a more specific (small) example.

 

When devloping a white-label product, and have more customers with their own brand books. You want to make UI to look different for each one. And sometimes just CSS does not help. You need to have different markup so component could look different for each customer. I know it's pretty abstract :)

github.com/iamandrewluca/white-lab...

Now if I change REACT_APP_CUSTOMER in .env file I get different src/components/customer

Why not export a component that takes props? In your example, <Customer name="Dan" /> or <Customer name="Andrew" />. Then you can have different apps render the same component with different props.

Of course in practice you'd have more props, but you can also pass a whole object with them, e.g. <Customer brandData={{name: 'Andrew', color: 'red'}} />. If it’s too cumbersome to pass it down the tree to every component you can also use context for this.

The reason I dislike your solution is that you end up bundling all variations for every single deployment. So your bundle for a baby powder brand would also contain all the strings you use for a vodka brand. Not great.

Actually I looked into compiled sources and is not bundling all variations.
Thanks for your reply!

Good to know! I guess webpack is smart enough to do the replacement earlier :-). This is still not a great future-proof approach because it relies on requires whereas the ecosystem has been moving to ES modules. It’s also much harder for any other tools to understand what’s going on in your modules.

 

Not quite relevant, but I'd like to share some experience on that because I believe this kind of problems is quite rare.

When my team was building a white-label product (not entirely in React and no variations in component behavior and HTML markup, mostly styles and texts in different languages, texts included HTML in a few places), we made a build system that spits out separate bundles for each "partner" and an app loader that loads the respective bundle given the "partner" identifier in runtime.

We split the bundled code into the core bundle which contained all the component implementations and the core component styles, a "partner" style bundle which included partner style overrides (we relied on CSS cascade to apply the overrides), and a messages bundle which included the translations compiled for the "partner" from the base and the overrides during the build.

This happened before the CSS modules came into play, so this might not be the best possible implementation, but it works for several years now, and gradual introduction of React into the app didn't change the approach. We used the BEM naming methodology for our components' CSS class names and LESS mixins provided by the components to ensure theming uses the appropriate style overrides in the "partner" bundles.

 

As someone that comes from a Vue background, conditionally rendering things in React look a bit cumbersome to me. In Vue, I just use a v-if directive in the element and I'm good to go, but I'm react I see myself constantly doing stuff like using the ternary operator { obj.attr ? <Stuff></Stuff> : null }.

Is there a better solution? Am I approaching things in the wrong way, maybe?

 

React seems easier than Vue for conditional rendering in my opinion, in the end it's just javascript and you can do it in many different ways!

 

I completely agree with Camilo.

The main problem for me why Angular and Vue is quite meh is because you need to learn another domain specific language. So you need to know some gotchas here and there, some limitations etc. So at the end of the day, maybe ternaries starts to become cumbersome (than you probably need to decompose component to smaller pieces to abstract this away) but at least you surely 100% know how it works.

About make it more beautiful, you can use just shortcut like
{obj.attr && <Stuff/>}

Or just use some simple high-order-component, or decompose things and move this clutter to the component itself.

 

This is one of the big philosophical and opinion differences between people who prefer Angular/Ember/Vue and people who prefer React.

React users generally point to the phrase "it's just Javascript" as a positive thing. Flow control and conditional rendering uses normal JS if statements and conditions, rendering lists is normal JS loops and array methods, and so on. There's no special templating mini-languages needed. Render methods also give you the full power of JS to write whatever logic you need.

People who prefer template-based rendering usually emphasize things like the ability to have designers edit HTML directly, and finding templates easier to read.

Both are valid approaches, and it really is a dividing line based on your own preferences. I personally am very happy with using JS-based rendering logic, and have no interest in using templates, but YMMV.

 

I see why you might find this cumbersome although to be honest I got used to it pretty quick and it stopped being a problem for me a few months into React.

In fact I found the ability to use any JS constructs liberating because as soon as the condition got more complicated I could extract it in a variable, a function call, a switch statement, an object property lookup, or any other valid JS code.

That said we do have some ideas about allowing something like

return (
  <div>
    *{
      if (obj.attr) {
        yield <Stuff />;
      }
    }
  </div>
)

to work (see this proposal).

 

Interesting... Yeah, I can totally see how abstracting complex conditions into a variable can be useful. I guess it makes a lot of sense - it's all just javascript in the end.

Thanks for the answer!

 

Hi Dan,

First, let me thank you for making this. At this point you and your ideas are kind of a basic reference in part of the industry so, being able to kind of dig into your head through this questions is just plain awesome.

Now, my question is regarding your article on Presentational and Container components, I would love to know your opinion about one thing.

Imagine that you had an app where all the state is stored in redux, from all the dynamic contents of any div to the actual state of the UI (checkboxes, inputs, form errors, menu structures, etc...), simply everything.

In that case, when all your components can be stateless because they will be grabbing everything they need from redux and dispatching everything as actions to it (and you're not building a component library that you want to be storage agnostic, of course), would you say that the whole idea of splitting components that way still makes sense or is it maybe a little bit too artificial?

Thanks in advance!

 

Hi Dan, I don't know if question I am going to ask is too simple but want to hear your views on it.

For state management in ReactJS I am using mobx but I have heard about Redux too.

So according to you which is better to use with ReactJS, Mobx or Redux?

 

Both are useful tools that try to solve state management in very different ways.

I suggest checking out these comparisons:

I also have links to additional Redux vs MobX comparisons as well.

 

Thanks I will check them out☺️

 

I've mentioned this before, but this course really helped me get a deeper understanding of state management, Redux vs. Mobx in particular:
dev.to/dudeinthemirror/comment/1nb6

 

They’re just different. If one was obviously better than the other one then everybody would use it.

 
 

Hi Dan !

I come from the angular world where we heavily use services and dependency injection. This makes the code easy to test by mocking dependencies. But when it comes to react, I cannot find a clean way to achieve the same. Is there a proper way to inject dependencies in your components ?

Thanks :)

 

I tend to either use context for this, or something like jest.mock() (that is, if you use Jest).

 

What are the best practices to organize state in Redux. I notice the we left many objects orphans inside the state and also some objects inside other objects. I know tat this is a poorly coding, but when teams are getting bigger seems to happen more. I was thinking to use something like minimongodb or other tools to validate objects. Is this a moronic idea?

 

Try to see how big apps using Redux organize their state (using Redux DevTools or by looking at storeState of connected components in React DevTools). For example Mobile Twitter.

I think in general instead of nesting you’ll want to normalize the data and keep it relatively flat. I wrote a library for this that was rewritten and is now maintained by Twitter: github.com/paularmstrong/normalizr

I don’t know what minimongodb is and I don’t understand what you mean by validating or orphan objects.

 

Minimongodb is a mongodb that is used in app that uses meteorjs. I was thinking introduce a db for the state so I can keep it normalize.

That wouldn’t be related to Redux though, would it?

 

I want to implement offline support on my React project I built with the YouTube API. Do you have any suggestions on how I can get started with this implementation?

 

You might find something like this helpful: developers.google.com/web/tools/wo...

You could also use Create React App which by default lets your app work offline: github.com/facebookincubator/creat...

 

Okay and if I may ask will Workbox be able to cache the fetched videos from the YouTube API but only rerender the app when the API makes a new call for another video?

I don’t know but I’d be very surprised if it could. Workbox is for caching your own assets, not downloaded assets. I don’t know if it’s possible to cache videos from YouTube but my guess would be no.

 

Try to post this question on the Google Product forums or in Twitter. I had questions about Google OAuth APIs and got very fast response via Twitter and e-mail...

 

I learned a lot from your egghead's redux course especially the second one, are you planning to make more courses? also, where can I find similar advanced good practices and guides as mentioned in your second course?

 

I have a few ideas about future courses in mind but haven’t worked on materializing those. Maybe some time next year.

I don’t know about advanced materials. Maybe @markerikson has links?

 

I'd suggest checking out my list of suggested resources for learning Redux, and my React/Redux links list.

I also just submitted a PR that adds a "Learning Resources" page to the Redux docs, with links to some specific suggested articles on different Redux-related topics. I hope to merge it into the Redux docs and republish them within the next couple days, at which point the new page will show up in the Redux docs at redux.js.org .

 

I highly recommend Steve Kinney's course: Advanced State Management in React frontendmasters.com/courses/react-...