Hey,
If possible I would like to take a look into this issue:)

@M-Izadmehr This issue is all yours! 😄

We've added the "good first issue (taken)" label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let us know so that we can remove the label and free it up for someone else to claim.

Cheers!

@M-Izadmehr Great! Thanks for taking a look. I think the first step is to look at our es-lint config and enable a canonical lint rule that already exists upstream.

After that you should be able to open a PR which should fail the lint rule. After that you could do a separate commit that contains the code fixes. I wouldn't start by fixing the code though as that risks rebase issues.

@sebmarkbage @bvaughn
I tried to check this issue and here are my findings:
First of all, we are never violating no-unreachable linting rule.
Based on MDN firefox never shows a warning, if a function declaration statement is following return. Also, based on ESLint it is also a valid code. As a result react code is safe, and never causes a warning.

Secondly, after a small search through the project, I see that we are using this approach in at least a dozen places. I can suggest two things, if we are on the same page, then continue with the PR:

1. Explicitly add no-unreachable to eslint config (this is already a part of default config, so adding it will have no effect, just helps with explicitly showing the purpose)
2. Although this pattern does not cause a warning (in either eslint/or browser), it can be confusing at times (however, it also results in cleaner functions, e.g. check below image)

Either way, if you agree with refactoring such cases I can move on with submitting the PR.

Bind