React Hooks - state and lifecycle methods without a class (React 16.7.0-alpha)


I saw a similar post yesterday from our local React group. And I’m asking the same question here: can you point me to any existing article/page saying that componentDidMount will be deprecated?




@ralpheiligan: not sure I undestrand your question ?


@yched, nowhere in the blog post that mentioned that componentDidMount will be deprecated. Are you referring to other lifecycle methods?


Doh ! Sorry, I meant componentWillMount, it’s componentWillMount / WillUpdate that get deprecated.
I edited my post above with the correct method names… Sorry for the confusion :-/


i like it, but i see a potential concurrency problem on SSR with meteor, see

how i understand the hooks is, that they store some caller–>hook dependency. So on every render call of a component, they set some global state to the current calling component, so that every hook/effect call knows which component it belongs to.

this work fine, with normal javascript environments, as long as you don’t use asynchronous callbacks (like setTimeout)

on meteor servers, however, you have fibers. and fibers can stop/yield execution of code on certain points (like on a Collection.findOne() call).

This could potentioally break hooks/effects in a similar way like it breaks React.createContext (see link above) when doing server side rendering.

its probably not a big problem with more recent apps that use apollo, where the whole <App /> has no fiber-yields, but it can be, if you use pub/sub.

I don’t know the exact implementation, so this is only guessing. Maybe there will be also a fix involving Fiber.current like i did for the context api (



At this stage of the alpha hooks are not supported on the server yet, so that’s hard to say for sure.

For the specific case of “provide reactive Meteor data to React components through a hook”, though, I’d say it’s likely not going to be a problem : the current implementation of the withTracker(reactiveFun) HOC basically just does if (Meteor.isServer) return reactiveFun(props), and a useTrackerHook(reactiveFun) will probably do the same (that’s what my PR linked above does, for example). So if you had no problem running the withTracker HOC on the server, I don’t think a useTracker hook will cause more issues.

Not sure how the other hooks used by your components will behave on SSR, since that’s not implemented yet in React.


Tracker is not the problem, but yielding functions are.

renderToString(<App />) is no longer synchronous if you use e.g. Collection.find() in one of your components, so another call to renderToString(<App />) might happen before the first one has completed.

if React relies on some globals to keep references for hooks (like they use globals to keep the current value in React.createContext, we will get into troubles, because these references might change because of a concurrent rendering


Sure, what I’m saying is : There are actually no hooks involved on the server. The current implementation of the useTracker hook does nothing more than the withTracker HOC when Meteor.isServer is true : it just runs the callback you give it, once, non-reactively, and not involving any react hooks.

So if your code has no problem currently with withTracker(callback_that_yields) on the server (and I assume that’s the case ?), then it shouldn’t have problems with useTracker(callback_that_yields) either.

Maybe the issue you mention will appear with components using other hooks (useState, useEffect…) directly, but not with useTracker. Definitely worth keeping an eye on, but not really related to the existence of a useTracker hook :slight_smile:


aaah, yes. i referred to the topic here, to react-hooks :wink:


@macrozone right, sorry, I forgot that this thread was initially about “react hooks” in general, and that I later kind of hijacked it with “hey, we can probably have a hook for Tracker data” :slight_smile:

Apparently React 16.6.3 contains a couple fixes around context and SSR. Dunno if they affect the issues your seeing with yields and Fibers ? (or your fix package, for that matter…)


yes, i saw that as well and did a first attemp to upgrade to react 16.6.3. First result is, that SSR is now even more broken then before with meteor :wink:


Yawn. I’m not against incremental improvements. At the same time, this is another one of those changes that only the react maintainers and language purists care about. In the grand scheme of building digital products, whether your declare you component with the word class or not isn’t going to move the needle.