profile
viewpoint
Dan Abramov gaearon @facebook http://twitter.com/dan_abramov Working on @reactjs. Co-author of Redux and Create React App. Building tools for humans.

acdlite/redux-router 2328

Redux bindings for React Router – keep your router state inside your Redux store

alexkuz/react-json-tree 975

React JSON Viewer Component, Extracted from redux-devtools

bvaughn/react-devtools-experimental 965

Experimental rewrite of the React DevTools extension

gaearon/ama 221

Ask me anything!

cavinsmith/bdsm.js 55

Background Dominant Stripe Manipulator

gaearon/awesome-made-by-russians 27

🇷🇺 The best open source projects that were made and mainly contributed by Russian developers

acdlite/react 23

A declarative, efficient, and flexible JavaScript library for building user interfaces.

gaearon/awesome-redux 17

Awesome list of Redux examples and middlewares

startedDanWahlin/Observable-Store

started time in an hour

startedgaearon/overreacted.io

started time in an hour

issue commentfacebook/react

Bug: React hijacks console functions that may cause unpredictable behavior.

But that is bad—It’s been tripping users up like what has been posted in comments on the original pull request:

The previous behavior has as well. Neither state is perfect which is why the devtools option is on the table.

At least, were the console suppression to be kept, it should be explicitly stated in the documentation.

Sounds great. Though we had the previous behavior documented as well and people were confused by it as well. This will just take some time until this knowledge proliferated enough through the community.

infinnie

comment created time in an hour

Pull request review commentreactjs/reactjs.org

Update strict-mode.md

 At first glance, this code might not seem problematic. But if `SharedApplication  By intentionally double-invoking methods like the component constructor, strict mode makes patterns like this easier to spot. +> Note:+>+> Currently, React automatically [modifies](https://github.com/facebook/react/pull/18547) the console methods like `console.log()` to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases, where [a workaround can be used](https://github.com/facebook/react/issues/20090#issuecomment-715927125).
> Currently, React automatically modifies the console methods like `console.log()` to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases, where [a workaround can be used](https://github.com/facebook/react/issues/20090#issuecomment-715927125).

The implementation isn't important for documentation as far as I can tell. It may even be misleading in case code moves around.

> Currently, React automatically modifies the console methods like `console.log()` to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where [a workaround can be used](https://github.com/facebook/react/issues/20090#issuecomment-715927125).

Not sure about that comma. Seems off to me but if you're sure then keep it.

infinnie

comment created time in an hour

startedkripod/react-polymorphic-box

started time in 2 hours

issue commentpmmmwh/react-refresh-webpack-plugin

Compatibility with webpack-dev-server@4

@billyjanitsch please see this thread https://github.com/pmmmwh/react-refresh-webpack-plugin/issues/126#issuecomment-736883538

It has to do with webpack-dev-server and we're currently waiting for https://github.com/webpack/webpack-dev-server/issues/2893

billyjanitsch

comment created time in 6 hours

pull request commentreactjs/reactjs.org

Update strict-mode.md

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

infinnie

comment created time in 6 hours

pull request commentreactjs/reactjs.org

Update strict-mode.md

Deploy preview for reactjs ready!

Built without sensitive environment variables with commit 958519cbb5302ca77825c4c8e0b806bb95ef4e94

https://deploy-preview-3426--reactjs.netlify.app

infinnie

comment created time in 7 hours

issue commentfacebook/react

Bug: React hijacks console functions that may cause unpredictable behavior.

Yeah we should definitely add it to StrictMode documentation. Would you be interested in adding a note there?

It’s been tripping users up like what have been posted in comments on the original pull request:

Yes, we understand it would trip users. Both behaviors trip users in different ways. From our experience so far, it is still net positive to silence the noise from the second log, but it does come with the tradeoff of confusing other people in other situations once in a while.

A pull request is opened in https://github.com/reactjs/reactjs.org/pull/3426.

infinnie

comment created time in 7 hours

pull request commentreactjs/reactjs.org

Update strict-mode.md

Hi @infinnie!

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

infinnie

comment created time in 7 hours

PR opened reactjs/reactjs.org

Update strict-mode.md

Add explicit documentation about modification to console behavior.

<!--

Thank you for the PR! Contributors like you keep React awesome!

Please see the Contribution Guide for guidelines:

https://github.com/reactjs/reactjs.org/blob/master/CONTRIBUTING.md

If your PR references an existing issue, please add the issue number below

-->

+4 -0

0 comment

1 changed file

pr created time in 7 hours

Pull request review commentfacebook/react

[Flight] Add getCacheForType() to the dispatcher

+/**+ * Copyright (c) Facebook, Inc. and its affiliates.+ *+ * This source code is licensed under the MIT license found in the+ * LICENSE file in the root directory of this source tree.+ *+ * @flow+ */++import type {Dispatcher} from 'react-reconciler/src/ReactInternalTypes';+import ReactSharedInternals from 'shared/ReactSharedInternals';+import invariant from 'shared/invariant';++const ReactCurrentDispatcher = ReactSharedInternals.ReactCurrentDispatcher;++function unsupported() {+  invariant(false, 'This feature is not supported by ReactSuspenseTestUtils.');+}++export function waitForSuspense<T>(fn: () => T): Promise<T> {+  const cache: Map<Function, mixed> = new Map();+  const testDispatcher: Dispatcher = {+    getCacheForType<R>(resourceType: () => R): R {+      let entry: R | void = (cache.get(resourceType): any);+      if (entry === undefined) {+        entry = resourceType();+        // TODO: Warn if undefined?+        cache.set(resourceType, entry);+      }+      return entry;+    },+    readContext: unsupported,+    useContext: unsupported,+    useMemo: unsupported,+    useReducer: unsupported,+    useRef: unsupported,+    useState: unsupported,+    useLayoutEffect: unsupported,+    useCallback: unsupported,+    useImperativeHandle: unsupported,+    useEffect: unsupported,+    useDebugValue: unsupported,+    useDeferredValue: unsupported,+    useTransition: unsupported,+    useOpaqueIdentifier: unsupported,+    useMutableSource: unsupported,+  };+  // Not using async/await because we don't compile it.+  return new Promise((resolve, reject) => {+    function retry() {+      const prevDispatcher = ReactCurrentDispatcher.current;+      ReactCurrentDispatcher.current = testDispatcher;+      try {+        const result = fn();+        resolve(result);+      } catch (thrownValue) {+        if (typeof thrownValue.then === 'function') {+          thrownValue.then(retry, reject);

This should retry in both cases. Rejecting a promise doesn't actually throw an error.

gaearon

comment created time in 8 hours

startedgaearon/suspense-experimental-github-demo

started time in 8 hours

issue commentfacebook/react

Mouseenter event not triggered when cursor moves from disabled button

This would be useful when implementing a SpinButton component. When hitting the max or min value, the corresponding button would be disabled. Trying to implement hover state on mouse enter for the opposing direction can be accomplished with mousemove, but it'd make more sense if it worked with mouseenter. For example: Screen Shot 2020-12-02 at 5 33 32 PM

stepancar

comment created time in 9 hours

startedpreactjs/wmr

started time in 9 hours

pull request commentfacebook/react

Disable console.logs in the second render pass of DEV mode double render

My underlying issue is that I had some other render side-effects that I thought were idempotent (useRef) but turns out not -- and the first instinct to pull out console.log made me super confused.

As always in software, there's the possibility of making this configurable, perhaps opt-out with a small start-up warning message letting people know it's a thing? I mean, the double-render behaviour is mentioned in the docs but I'm pretty sure many people miss it.

Yes the double render behavior is mentioned. But the console suppression isn’t.

sebmarkbage

comment created time in 9 hours

issue commentfacebook/react

Bug: React hijacks console functions that may cause unpredictable behavior.

This is intended behavior (introduced in #18547) that will be opt-out once #19710 lands in React devtools. Until then you can use a local workaround explained in #20090 (comment).

But that is bad—It’s been tripping users up like what have been posted in comments on the original pull request:

  • https://github.com/facebook/react/pull/18547#issuecomment-720493759
  • https://github.com/facebook/react/pull/18547#issuecomment-726866607

At least, were the console suppression to be kept, it should be explicitly stated in the documentation.

infinnie

comment created time in 9 hours

startedatotto/clipboard

started time in 10 hours

pull request commentfacebook/react

Remove unused bundles

I think it does apply here because they way you build modern is with RELEASE_CHANNEL=experimental yarn build (which happens to be the default).

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

The experimental !== modern thing is a separate issue that this doesn’t address. Our @gate experimental check is subtly wrong for the same reason.

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

Yeah I like the API of listing out every combination; I just don’t like how scattershot the implementation is later when we infer things about the underlying dimensions. It’d be cool we if we that in one place, immediately when we consume the bundle. Best of both worlds.

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

The RELEASE_CHANNEL flag makes most sense for open source. EXPERIMENTAL != MODERN and that keeps tripping me up. Especially for esoteric things like the Webpack plugin. I'm also not sure it actually works for those. Like what happens if we publish the Webpack package today in experimental? What tag will it get?

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

fwiw. I really like this change because it lists out every combination. It's so easy to understand.

The combinatorial thing makes you think about combinations that don't make sense.

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

I should be able to land most of the first commit without any issue, let me update.

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

Yeah, agreed. Re: complexity - one reason I liked this approach more is that the implementation was cleaner even though there's more bundle config. There's effectively three lines that change in the actual build script (I hear you though).

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

Yes, that's currently a file that needs to be removed while keeping the others.

CircleCI has a "matrix builds" feature that lets you exclude certain combinations. https://circleci.com/docs/2.0/configuration-reference/#excluding-sets-of-parameters-from-a-matrix. I suppose we could do something similar.

I do like the explicitness of listing out every combination for every bundle. (I can't even remember what the moduleType option means :D)

But I guess I was hoping that this would be as small a change as possible, given that our build script is so complex already.

should we bail out of this strategy and just add a filter to the sync?

Yeah probably. Getting too bikesheddy. One day we'll redo this whole pipeline from scratch and we can make it better then.

rickhanlonii

comment created time in 10 hours

pull request commentfacebook/react

Remove unused bundles

Is that actually a valid use case?

Yes, that's currently a file that needs to be removed while keeping the others.

rickhanlonii

comment created time in 11 hours

pull request commentfacebook/react

Remove unused bundles

There's a new problem where many of the files that we are skipping now have build tests that run on them, so it looks like we need to build them anyway? @acdlite should we bail out of this strategy and just add a filter to the sync?

rickhanlonii

comment created time in 11 hours

pull request commentfacebook/react

Remove unused bundles

How would you exclude ReactDOMServer-dev.modern.js while keeping ReactDOMServer-prod.modern.js and ReactDOMServer-dev.classic.js

Is that actually a valid use case?

A more realistic case that I think illustrates your point is that there's no such thing as a bundle that's both OSS_EXPERIMENTAL and FB_WWW_PROD. But I think that's fine; we'd just won't output combinations that don't make sense, like you already do here: https://github.com/facebook/react/pull/20369/files#diff-f05e9513ea1c7e83c66f63dc3a7a2e1d464c58c7beebe1c375a2845caa6b0bc4R776-R780

It may match more conceptually but without rewriting the entire config, I think it makes it harder to reason about what will be output based on a given config.

I agree that it's a bit harder to predict the final bundles — nothing's easier than listing out every single one in a flat list — but it makes the implementation harder to maintain, and encourages weird ad hoc workarounds like this isFBBundle check:

https://github.com/facebook/react/blob/504222dcd21c7ac43eb78df11226bab47ec03bb0/scripts/rollup/build.js#L545-L558

That could check the release channel instead.

rickhanlonii

comment created time in 11 hours

pull request commentfacebook/react

Remove unused bundles

Interestingly, I'm now making the same argument @sebmarkbage was making against the test-cli options. I think the difference there is in the test CLI we can still list common combinations and if you use invalid combinations, we can show warnings. But in this config, you want to minimize the mental grepping you need to do to know what's being bundled.

rickhanlonii

comment created time in 11 hours

more