Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the experimental Hooks proposal behind a feature flag #13968

merged 19 commits into from Oct 29, 2018


Copy link

@sebmarkbage sebmarkbage commented Oct 25, 2018

Hooks let you use all React features (such as state and lifecycle) without writing a class.

We have presented the Hooks proposal at React Conf 2018. This pull request implements all proposed built-in Hooks behind a feature flag, both for the client and the server renderer.

This is a very early time for Hooks and this proposal is experimental. We're merging it into master now so we can iterate on it. It is turned on only in the 16.7 alpha release so that you can try it and provide your feedback.

We have been using this code for a month in production so while the APIs are not stable, we don't expect the implementation to contain major bugs.

Please keep the feedback and discussion contained in the Hooks RFC (and not in this PR) so that everyone can discuss it in a single place without checking multiple GitHub threads.

Copy link

@sizebot sizebot commented Oct 25, 2018

Details of bundled changes.

Comparing: 5045763...5045763


File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
scheduler.development.js n/a n/a 0 B 19.17 KB 0 B 5.74 KB UMD_DEV
scheduler.production.min.js n/a n/a 0 B 3.16 KB 0 B 1.53 KB UMD_PROD

Generated by 🚫 dangerJS

Copy link

@NE-SmallTown NE-SmallTown commented Oct 25, 2018

I'm so sorry to say this in this thread but I notice this:

committed on 6 Sep

Oh guys, the last time you do this is the Suspense. 😄

Great work !

-------- I will remove this comment if it causes spam

aweary approved these changes Oct 25, 2018
Copy link

@aweary aweary left a comment


Copy link

@acdlite acdlite left a comment

Wait wait I want to approve it, too!

Copy link

@jamiebuilds jamiebuilds left a comment

Hold up, but I also want to approve it

Copy link

@TrySound TrySound left a comment

Great stuff

Copy link

@sophiebits sophiebits left a comment

wow, great idea

Copy link

@philipp-spiess philipp-spiess left a comment



it('flushes passive effects even if siblings schedule a new root', () => {

This comment has been minimized.


philipp-spiess Oct 26, 2018

I wonder how you came up with all of those edge cases. 😉

This comment has been minimized.


gaearon Oct 28, 2018

Ran into bugs in the first implementation by trying it on the product code.

'Calling useContext(Context.Consumer) is not supported, may cause bugs, and will be ' +
'removed in a future major release. Did you mean to call useContext(Context) instead?',

This comment has been minimized.


Jessidhia Oct 27, 2018

Interesting; this also means that you can't use the usual const { Provider, Consumer } = React.createContext() pattern with hooks.

This comment has been minimized.


trueadm Oct 27, 2018

There’s no reason to use that pattern anymore with hooks.

This comment has been minimized.


Andarist Oct 28, 2018

@trueadm actually this could be useful for libraries wanting to hide their providers 🤔

This comment has been minimized.


gaearon Oct 28, 2018

It's plausible one of returned values would be a Hook itself in the future.

Copy link

@gaearon gaearon left a comment

seems okay

acdlite and others added 11 commits Sep 5, 2018
- useState
- useContext
- useEffect
- useRef
- useReducer
- useCallback
- useMemo
- useAPI
Effects scheduled by useEffect should not fire until after the browser
has had a chance to paint. However, they should be fired before any
subsequent mutations.

Also adds useMutationEffect and useLayoutEffect. useMutationEffect fires
during the host update phase. useLayoutEffect fires during the post-
update phase (the same phase as componentDidMount
and componentDidUpdate).
Co-authored-by: Alex Taylor <>
Co-authored-by: Andrew Clark <>
Before the fix, the passive effect in the test is never executed.

We were previously waiting until the next commit phase to run effects. Now, we run them before scheduling work.
Previously, flushPassiveEffects (called by scheduling work) would overwrite rootWithPendingPassiveEffects before we had a chance to schedule the work.
wow, writing code is hard
This was referenced Sep 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet