Optimized useTracker hook

[CaptainN]

This PR is a roundup of the discussion (and builds on the work) in #262 and #271, and supersedes: #242, #252, #256, #263, #266, #267, #268.

It does the following:

• Create a base hook, useTracker to for use as an alternative to withTracker in hooks based projects.
  Rewrites withTracker on top of useTracker (issues Unsafe lifecycle methods were found within a strict-mode tree #256, React 16.3 => migration from componentWillMount and componentWillUpdate #252, componentWillMount vs componentDidMount #242 / PR [WIP] Update lifecycle methods for newer React #261)
• Updates docs!
• Removes deprecated createContainer.
• Above Expose useTracker hook and reimplement withTracker HOC on top of it #262, this PR retains the synchronous rendering behavior in withTracker and in useTracker if no deps are specified, but also allows asynchronous reactivity after firstRun if deps are supplied, and properly responds to deps changes. This implementation is compatible with Concurrent Mode, React Suspense and Error Boundaries.
• I wrote new TinyTests for the hook, and ported back the old ones.
• Above Create useTracker hook and reimplement withTracker HOC on top of it  #271, this PR fixes a number of issues raised in that PR.
• It also switches the underlying deps compare functionality from a fork of React internals to using useRef. There was some concern that results from that may be randomly tossed, but for now (react 16.8.6) they are stable. Even if they are tossed, the only effect this will have on our implementation is that it'll recreate the computation on the next render.
• This PR also adds a third param to the hook, which is a computation lifecycle hook. This method is structured like the method passed to useEffect. The main function runs when a new computation is created (before reactiveFn) and then if it returns a function, that function is run right before the computation is destroyed. I don't know if this is really all that useful in real world use cases, but it is useful for testing some internal behaviors. I left it undocumented for now.
• This PR also now passes a reference to the current computation to the reactiveFn.
• Compatible with SSR.

Since this bumps the react version requirement to 16.8, there has been some discussion about how to properly release this with a major version bump. One suggestion was to bump the old version to 1.0.0 which can receive updates separately, then release this update as 2.0.0.

I believe this is ready for review. (Third time's a charm!)

CC @hwillson @menelike @yched

[CaptainN]

I also recommend silencing the warning by switching to the UNSAFE prefixed lifecycle methods for v1.0.0

[benjamn]

@StorytellerCZ @dburles Feel free to ping me if you don't hear back soon (say, this week). Seems good for Tiny to go through the exercise of publishing a core package, but of course I can do it too if need be.

[dburles]

@StorytellerCZ @dburles Feel free to ping me if you don't hear back soon (say, this week). Seems good for Tiny to go through the exercise of publishing a core package, but of course I can do it too if need be.

I think so too. There's a bit to take in here, but we have a fairly good idea on the process to release now so we can help with that side.

@CaptainN I think it would make sense to open a new PR for v1 (named v1) including any changes we feel makes sense to include. We may have to maintain a v1.0.0 release track but I don't think it's essential. At the very least the v1 branch can then serve that purpose if we ever need to publish updates. Thoughts?

Edit: I forgot this is a monorepo, that is a bit of a pain. I think there was some discussion around moving this package into its own repo as it's by far the most used, if not the only one these days. Perhaps react-meteor-data-v1 will do.

[CaptainN]

I agree about keeping a v1 branch maintained, and maybe even backward compatible with older react version (somehow detect and use the UNSAFE prefixed for newer versions of react)?

It is a mono repo, but the main grouped tests don't seem to have been wired together for a while, and I've ported the tests into the package directly in this PR, so it's ready to be split out.

[CaptainN]

Another forum post about using state within withTracker.

[filipenevola]

Hi @CaptainN and all, now that 1.8.2 is published we can start working on publish this new version.

Do we have any pending issues here? Any reported issue in the forums/slack that should be included in this conversation?

[Floriferous]

This is very helpful for all of us using React! Awesome :)

Would it be worth it to briefly think of a path forward towards supporting Suspense and concurrent mode with this hook? At least make sure that the current API would not have to be reworked and that it could be a minor release in the future?

[CaptainN]

@filipenevola There is nothing outstanding that should prevent a review. There are some additional features I might like to add (specifically an API to specify a "shouldUpdate" method), but nothing that would hold up a review of at least the general approach we've taken here.

[CaptainN]

@Floriferous Great care was taken to make sure this hook will work with Suspense, concurrent mode and Error Bounds (time slicing based features) without leaking memory or resources. Supporting Suspense API directly is a bit more of an effort, and probably not suitable for this hook because of it's generic nature. That said, there's no reason someone couldn't build a solution which supports Suspense for Meteor.subscribe for example on top of this.

[filipenevola]

Great work, README content is amazing 😉

[filipenevola]

Version 2.0.0 of react-meteor-data is published 🎉

[remarcable]

@filipenevola It would be awesome to close the corresponding issues linked in the PR description. Thanks a lot for merging! 🎉

[filipenevola]

@lightningboss done.

if some of them are still pending we can open again, no problem.

[dburles]

Great stuff! We should also now cut a v1 branch and publish it as 1.0.0 too.

[yched]

Awesome to see this committed and released, thanks @filipenevola, and congrats @CaptainN !

Just : since this went through so many attempts, approaches and refactorings through 3 successive PRs and 150+ commits in total, it would be best to squash into one commit ?
Right now this PR represents the full first 4 pages on https://github.com/meteor/react-packages/commits

[filipenevola]

@dburles I just created the v1 branch #274 (comment)

Are you going to use v1? I would like to find someone that is going to use v1 then this person can lead the PR that we are going to merge and publish as 1.0.0

[filipenevola]

@yched I personally like to see all the changes then we can understand how we ended up in this state but maybe just me hehe 😉

[CaptainN]

There was a lot of discussion in 3 PRs and a lot of commits that lead to the way the current code is. It's actually enough that maybe I should write a summary and store that somewhere.

Most of the work for V1 will be in documentation. There is already aPR to rename the deprecated methods.

[filipenevola]

Yes, I already sent a message there also #274 (comment)

[ghost]

Hi there,

do you have a readme files for this?
I mean a clean interface definition?
since it looks like quite some effort u put into this.

regards

[CaptainN]

It looks like the meteor guide is still recommending withTracker - maybe we should update that. As always, PRs are welcome!

There is a readme, and there is a blog post about useTracker.