Fix issue with multiple code branches in hooks linter #14661

Yurickh · 2019-01-23T01:39:06Z

I changed the algorithm to a simple DFS so we can find the correct number of possible paths from the hook to the start of the function.

I'm not sure I should change the other (similar) functions as I couldn't think of a breaking example for them.

Fixes #14362

facebook-github-bot · 2019-01-23T01:39:10Z

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 up 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 the corporate CLA signed.

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

Yurickh · 2019-01-23T01:40:15Z

...ages/react-reconciler/src/__tests__/__snapshots__/ReactIncrementalPerf-test.internal.js.snap

@@ -396,30 +396,30 @@ exports[`ReactDebugFiberPerf supports Suspense and lazy 2`] = `
 "
 `;

-exports[`ReactDebugFiberPerf supports portals 1`] = `
+exports[`ReactDebugFiberPerf supports memo 1`] = `


I'm not really sure why this changed, as I just run the tests, and didn't ask for snapshot updating at any time.

hg-pyun · 2019-01-23T02:59:36Z

packages/eslint-plugin-react-hooks/src/RulesOfHooks.js

-              return 0;
-            }
+        function countPathsFromStart(segment, visited = new Set()) {
+          if (codePath.thrownSegments.includes(segment)) {


Is it okay includes method without polyfill?
https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/includes

I guess so, since the linter always runs in a node environmemt.

Also, IIRC, thrownSegments isn’t an array here, it’s just array-like.

Assuming this is an eslint@5 plugin, then yes as it's supported since node 6.

(Unless there are specific rules against it here?)

Since it is a direct extract from the original code, this shouldn't really be an issue.

Okay, It looks good.

facebook-github-bot · 2019-01-23T19:59:47Z

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

calebmer · 2019-01-24T21:08:34Z

packages/eslint-plugin-react-hooks/src/RulesOfHooks.js

         */

-        function countPathsFromStart(segment) {
-          const {cache} = countPathsFromStart;


Hi 👋
I’m the original author of this ESLint rule popping in for a review.

The reason I used a cache here is that in complex components, time complexity can really start to spike up. Consider:

function MyComponent() { if (a) {} else {} if (b) {} else {} if (c) {} else {} useHook(); }

Here we have 2³ = 8 paths from useHook() to the start of MyComponent. Representing the following combinations of a, b, and c.

a b c

true true true

false true true

true false true

false true false

true false false

false true false

false false true

false false false

So we have a 2ⁿ exponential relationship, fun. Now remember that every && and || (in the future perhaps also ??) introduces a condition since false && expensive() will not execute expensive().

Let’s say we have a complex component that has 5 conditions placed in the component before 6 hooks all in the same segment. Without a cache we have to call countPathsFromStart() on 2⁵ paths 6 times. With a cache, we only need to call countPathsFromStart() on 2 × 5 segments because we cache the value for every segment so we only need to visit each segment once.

In big-O notation where “n” is the number of conditions and “h” is the number of hooks, we have O(2n) time complexity with a cache and O(2ⁿ × h) without a cache.

To see what I mean in practice try adding the following component to the test suite. On this branch, I became impatient after waiting about 10s for the test to finish. When I switched back to master the entire ESLint test suite finished in about 3s.

It’s up to the React team (cc @gaearon) to determine whether or not this performance regression is acceptable. 20 conditions and 10 hooks were fine for me on this branch, but 40 conditions and 10 hooks were not. If this performance regression is not acceptable then I recommend adding the below component to the test suite.

function MyComponent() { // 40 conditions if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} if (c) {} else {} // 10 hooks useHook(); useHook(); useHook(); useHook(); useHook(); useHook(); useHook(); useHook(); useHook(); useHook(); }

Hi! Thanks for the chime in, explaining the original rationale behind this piece of code, that was really enlightening.

Unfortunately, I'm not sure there's a way to work around this performance regression. Using the cache as it is proved itself faulty and could lead to false negatives, as issue proved.
I could just remove the item from the cache once we finished visiting it, but the complexity of the overall algorithm would be the same.
I guess the complexity of the problem of finding the number of paths between two nodes on a graph can't really be reduced here.

I'll think about how we could improve it for the case of multiple hooks, so the complexity is not so high.

I added some comments below with a possible solution and the rationale behind that solution. TL;DR when countPathsFromStart() breaks a cycle it gives a temporary result of 0 to avoid looping forever.

calebmer · 2019-01-24T22:08:13Z

@Yurickh I found a fix for the problem that does not involve removing the cache. In countPathsFromStart() make the following change:

               paths += countPathsFromStart(prevSegment);
             }
           }
-          cache.set(segment.id, paths);
+          // If our segment is reachable then there should be at least one path
+          // to it from the start of our code path.
+          if (segment.reachable && paths === 0) {
+            cache.delete(segment.id);
+          } else {
+            cache.set(segment.id, paths);
+          }

           return paths;
         }

If you choose to use this fix, I encourage you to think about why this is the correct solution. In theory, segment.reachable && paths === 0 is a correct invariant to have for countPathsFromStart() but not for countPathsToEnd(). So if we detect a violation to this invariant we “forget” the computation which allows it to be re-computed later when we’ll get the correct result. (This has to do with how cycles are treated.)

Perhaps there is a more principled fix in the if (paths === null) { code. Since all we’re doing here is saying “we don’t like this result you gave us so try again later”.

If you choose to use this fix I also recommend adding the test case I included above to prevent future performance regressions.

calebmer · 2019-01-24T22:18:31Z

A more in-depth look at this problem. To debug I added to the top of the countPathsFromStart() function. It will log the segment’s id along with some indentation so we can see the nesting of our calls. (I got this idea from one of Sophie’s tweets, actually)

console.log('  '.repeat(i) + segment.id);

That gives us:

s2_6
  s2_2
    s2_1
    s2_5
      s2_4
        s2_3
          s2_2
  s2_3

@LosYear’s diagram from #14362 is really helpful for understanding this output, so I’ll include it:

Adding some annotations to the log:

s2_6
  s2_2
    s2_1              <---- first segment
    s2_5
      s2_4
        s2_3          <---- first call to countPathsFromStart(s2_3)
          s2_2        <---- cycle broken
  s2_3                <---- second call to countPathsFromStart(s2_3)

Our first call to countPathsFromStart(s2_3) looks at the segment which comes before it, s2_2. However, we’ve already visited s2_2 so we’ve found a cycle! We break the cycle by returning 0 which means s2_3 gets a count of 0. However, 0 is not the correct value for s2_2! You’ll see that the first time we visit s2_2 it has two previous segments: s2_1, our initial segment, and s2_5. s2_1 is the initial segment so it gives us 1 path. s2_5 cycles back to s2_2 so it gives us 0 paths. Therefore the correct number of paths for s2_2 is 1, not 0. But we got 0 in our first call to countPathsFromStart(s2_3) because we were breaking the cycle.

So that’s why we delete the result when segment.reachable && paths === 0 is violated. We know that if we call countPathsFromStart(s2_3) again that this time s2_2 will have the correct value, 1, instead of 0.

Yurickh · 2019-01-24T22:24:29Z

Looks like this really solves the problem for good, without significant performance loss.
I'm feeling bad for taking the authorship of the PR now haha!

Thank you so much for the insight! This turned out being a great solution after all.

sompylasar · 2019-01-25T01:07:36Z

I apologize in advance for the off-topic irrelevance of my question to this PR; there is no true "code review" feature of arbitrary piece of code at arbitrary time in GitHub yet, only "diff review".

I was curious and looked around the code of the eslint rule, and found this comment which raised a question in me:

        // Gets the function name for our code path. If the function name is
        // `undefined` then we know either that we have an anonymous function
        // expression or our code path is not in a function. In both cases we
        // will want to error since neither are React function components or
        // hook functions.
        const codePathFunctionName = getFunctionName(codePathNode);

and then:

            } else if (codePathFunctionName) {
              // Custom message if we found an invalid function name.
              const message =
                `React Hook "${context.getSource(hook)}" is called in ` +
                `function "${context.getSource(codePathFunctionName)}" ` +
                'which is neither a React function component or a custom ' +
                'React Hook function.';
              context.report({node: hook, message});

I reviewed the function getFunctionName(node) { and it looks like it's only concerned with use cases of finding a function name of a hook, not a function component.

In particular, I may write a function component this way, using an anonymous function:

const MyComponentWithStyles = withStyles((props) => {
  // some useAnyHook() code here
});

Would it become a problem that the anonymous function inside a call argument is meant to be a React function component, but it's not annotated to be that? Is this a rule now to not use anonymous functions to define React function components?

Yurickh · 2019-01-25T02:21:59Z

Hi, @sompylasar. In fact, you'll find an issue about your discoveries on #14404 (comment)

sompylasar · 2019-01-25T02:55:34Z

@Yurickh Thanks! It's exactly that. I searched for eslint hooks issues but missed this one (oh I realized I might have had is:pr in the filters).

gaearon · 2019-01-25T17:06:35Z

Thank you!

@calebmer

* Fix issue with multiple code branches * Add solution by @calebmer * Add performance test * Undo unrelated change

Fix issue with multiple code branches

cb1e8a5

Yurickh commented Jan 23, 2019

View reviewed changes

hg-pyun reviewed Jan 23, 2019

View reviewed changes

facebook-github-bot added the CLA Signed label Jan 23, 2019

hg-pyun approved these changes Jan 24, 2019

View reviewed changes

calebmer reviewed Jan 24, 2019

View reviewed changes

Yurickh added 2 commits January 24, 2019 20:21

Add solution by @calebmer

d3ad6e5

Add performance test

8928f8a

Undo unrelated change

0ad2940

gaearon merged commit e19c9e1 into facebook:master Jan 25, 2019

Yurickh deleted the fix/eslint-hooks branch January 25, 2019 18:19

n8schloss pushed a commit to n8schloss/react that referenced this pull request Jan 31, 2019

Fix issue with multiple code branches in hooks linter (facebook#14661)

3d68002

* Fix issue with multiple code branches * Add solution by @calebmer * Add performance test * Undo unrelated change

snyk-bot mentioned this pull request Aug 24, 2019

[Snyk] Upgrade react-dom from 16.2.1 to 16.9.0 Watemlifts/wagtail#53

Open

This was referenced Sep 11, 2019

[Snyk] Upgrade react-art from 16.5.2 to 16.9.0 JoeyFenny/react-native-expo-web#12

Open

[Snyk] Upgrade react from 16.6.3 to 16.9.0 JoeyFenny/react-native-expo-web#13

Open

[Snyk] Upgrade react-dom from 16.6.3 to 16.9.0 JoeyFenny/react-native-expo-web#14

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix issue with multiple code branches in hooks linter #14661

Fix issue with multiple code branches in hooks linter #14661

Yurickh commented Jan 23, 2019 •

edited

facebook-github-bot commented Jan 23, 2019

Yurickh Jan 23, 2019

hg-pyun Jan 23, 2019

Yurickh Jan 23, 2019

Yurickh Jan 23, 2019

Jessidhia Jan 24, 2019 •

edited

Yurickh Jan 24, 2019

hg-pyun Jan 24, 2019 •

edited

facebook-github-bot commented Jan 23, 2019

calebmer Jan 24, 2019 •

edited

Yurickh Jan 24, 2019 •

edited

calebmer Jan 24, 2019 •

edited

calebmer commented Jan 24, 2019

calebmer commented Jan 24, 2019

Yurickh commented Jan 24, 2019 •

edited

sompylasar commented Jan 25, 2019

Yurickh commented Jan 25, 2019

sompylasar commented Jan 25, 2019

gaearon commented Jan 25, 2019

a	b	c
true	true	true
false	true	true
true	false	true
false	true	false
true	false	false
false	true	false
false	false	true
false	false	false

Fix issue with multiple code branches in hooks linter #14661

Fix issue with multiple code branches in hooks linter #14661

Conversation

Yurickh commented Jan 23, 2019 • edited

facebook-github-bot commented Jan 23, 2019

Yurickh Jan 23, 2019

Choose a reason for hiding this comment

hg-pyun Jan 23, 2019

Choose a reason for hiding this comment

Yurickh Jan 23, 2019

Choose a reason for hiding this comment

Yurickh Jan 23, 2019

Choose a reason for hiding this comment

Jessidhia Jan 24, 2019 • edited

Choose a reason for hiding this comment

Yurickh Jan 24, 2019

Choose a reason for hiding this comment

hg-pyun Jan 24, 2019 • edited

Choose a reason for hiding this comment

facebook-github-bot commented Jan 23, 2019

calebmer Jan 24, 2019 • edited

Choose a reason for hiding this comment

Yurickh Jan 24, 2019 • edited

Choose a reason for hiding this comment

calebmer Jan 24, 2019 • edited

Choose a reason for hiding this comment

calebmer commented Jan 24, 2019

calebmer commented Jan 24, 2019

Yurickh commented Jan 24, 2019 • edited

sompylasar commented Jan 25, 2019

Yurickh commented Jan 25, 2019

sompylasar commented Jan 25, 2019

gaearon commented Jan 25, 2019

Yurickh commented Jan 23, 2019 •

edited

Jessidhia Jan 24, 2019 •

edited

hg-pyun Jan 24, 2019 •

edited

calebmer Jan 24, 2019 •

edited

Yurickh Jan 24, 2019 •

edited

calebmer Jan 24, 2019 •

edited

Yurickh commented Jan 24, 2019 •

edited