The downside of this is that the cost of rendering is multiplied. We know it’s an existing workaround but it’s not a good long term solution. We want to enable something better.

>Removing componentWillMount will force us to rewrite everything to the suspense API.

This is not accurate. The blog post states that `UNSAFE_componentWillMount` is here to stay so you can keep using that until we have a first-class data fetching solution that works both on the client and the server. You can also use the constructor for this (it’s technically equivalent to `componentWillMount`).

While it contradicts what I said earlier (avoid side effects in constructor) you’re already using a hack (rendering twice) and I’d argue this is no worse as a temporary solution. Don’t forget that `componentWillMount` is equivalent to the constructor for all intents and purposes, and only exists because it predates ES6 classes (and the ability to define a constructor). So you were already doing side effects in what is effectively a constructor.

Still, the upcoming Suspense API mentioned in the blog post is the intended long term solution to this. It will work both on the client and the server, and it will allow you to remove the double rendering hack. But to prepare for Suspense, we need to make components compatible with async rendering (which is what the blog post is all about).

We added a section to the blog post which I hope clarified it:

>When supporting server rendering, it’s currently necessary to provide the data synchronously – componentWillMount was often used for this purpose but the constructor can be used as a replacement. The upcoming suspense APIs will make async data fetching cleanly possible for both client and server rendering.

So you can keep using `UNSAFE_componentWillMount` or constructor for now, and migrate to Suspense when it’s ready (and render your app in a single pass).