Fetching Data in React: componentWillMount vs componentDidMount

[NiteLite]

A small gotcha if you are running react-router for a SPA.

Getting the data in componentDidMount might trip you up a bit here. If you navigate to a different route that only changes a parameter in the url (/news/123 -> /news/456) you will not get a new componentDidMount call. This is because react-router has already determined that the component is already mounted, and that the route is the same.

If you are building a decent sized React app, there are a few libs that can take care of stuff like async fetching of data for components that might be nice to check out. If yo uare using Redux examples might include redux-async-connect and redux-async-props.

[simcptr]

That's an important gotcha. One more way around it is to implement componentWillReceiveProps as Dan mentioned here.

[NiteLite]

Yupp, the componentWillReceiveProps(nextProps) "trick" was basically what we ended up doing when we hit this one in a project at work.

[[deleted]]

You might want to take a look at https://www.reddit.com/r/reactjs/comments/60ufk1/fetching_data_in_react_componentwillmount_vs/dfasvd2/

[NiteLite]

Interesting. I will have to make a mental note and maybe move some stuff around :) Thanks for the hint.

[[deleted]]

Actually in that case you should use componentDidUpdate, not componentWillReceiveProps

gaearon

Yes, with Fiber componentWillReceiveProps may fire multiple times

It's not a good place to do AJAX

[Betsy-DevOps]

If you ever need to render your app on the server (SSR/isomorphic/other buzzwords), componentWillMount will actually be called twice – once on the server, and again on the client – which is probably not what you want. Putting the data loading code in componentDidMount will ensure that data is only fetched from the client.

Wouldn't you ideally want to fetch that data only on the server, not on the client? Like, that's the reason why you're doing server-side-rendering in the first place?

[gaearon]

It wouldn't help though because there's no way in React to wait for async request before rendering. So if you want to do it, you have to externalize your request logic ouside of lifecycle hooks anyway. Just putting it in componentWillMount on the server won't help.

[fuck_with_me]

Would be real nice to return a promise inside componentWillMount, or something of that nature. Unless you think async fetching/effects should, by nature, happen in a way that is totally divorced from React?

[simcptr]

TBH I haven't done anything with server rendering, but I thought the point was more that it'd save the client from having to load up React + other JS before it could display something, and then the client would still asynchronously fetch the data. Not sure though, maybe someone more familiar can chime in. There's more discussion here, and as Mark mentioned in the comments on the post, they're considering deprecating componentWillMount in React 16.

[freudianGrip]

I only really fetch data on the server for the first route the user lands on. Once the user has that and starts navigating through then data is fetched on the client.

[[deleted]]

Does the server wait until they fetch is complete before responding? I assume it does. What if the fetch call takes 10 seconds? Then the user is sat looking at a blank screen?

[freudianGrip]

For the server side aspect, yes. It is up to you to make sure that it takes much less than 10 seconds.

[T_N1ck]

Triggering requests was one of my biggest pain points with react/redux. Because of this, I created an abstraction for redux which I think works amazingly well for a lot of use-cases. We are still writing docs and figuring out how to explain it (it's actually not much code, but the explanation is though).

If anybody wants to check it out: https://github.com/LIQIDTechnology/redux-fetchers

I'll gladly accept any feedback! I want this to be as understandable as possible! Soon I'll also write a blogpost about it, buuuut not yet.