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

Add no-context rule (fixes #455) #736

Closed
wants to merge 2 commits into from
Closed

Conversation

zachguo
Copy link

@zachguo zachguo commented Aug 3, 2016

Fixes #455

@ljharb ljharb added the new rule label Aug 3, 2016
@@ -0,0 +1,51 @@
# Prevent usage of context (no-context)

[Context](https://facebook.github.io/react/docs/context.html) is an advanced and experimental feature. The API is likely to change in future releases. Most applications will never need to use context. Especially if you are just getting started with React, you likely do not want to use context. Using context will make your code harder to understand because it makes the data flow less clear. It is similar to using global variables to pass state through your application.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to point people toward things like higher order components if they want to use context.

@zachguo
Copy link
Author

zachguo commented Aug 3, 2016

@lencioni thanks for reviewing, all fixed. I gonna test this rule against my project a bit and let you know how it goes.

message: 'Using context is not allowed.'
}]
}]
});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to include examples where:

  • component is an SFC that uses function syntax (not arrow function)
  • context is destructured in the signature
  • the second argument has a name that is not context
  • access of context via shenanigans
    • (...args) => { args[1] }
    • function Hello() { arguments[1] }
    • this['context']
    • var foo = 'context'; this[foo]
    • const { context } = this;

Copy link
Author

@zachguo zachguo Aug 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how to capture these shenanigans.... 😞

@zachguo
Copy link
Author

zachguo commented Aug 4, 2016

@lencioni @ljharb Everything done except tests of context via shenanigans. Advice needed on how to capture those. I also tested it against my project, it's working well.

@zachguo
Copy link
Author

zachguo commented Aug 4, 2016

I found a false positive in my project.

<div>
  {menuItems.map((e, i) => <MenuItem value={e.path} key={i} primaryText={e.text}/>)}
</div>

My current rule for stateless functional component is that, for any React component detected, if it has a second argument, then it uses context.
Is something wrong with /util/Components's detection, or with my rule?

* @returns {Boolean} True if node is a stateless functional component,
* false if not.
*/
function isStatelessComponent(node) {
Copy link
Author

@zachguo zachguo Aug 4, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Component.detect seems to be not working, so I tried detecting stateless functional component manually. However, utils.isReturningJSX didn't work as expected, it's returning false no matter what.

@zachguo
Copy link
Author

zachguo commented Aug 9, 2016

@ljharb @lencioni I'm now stuck at the fact that I cannot reliably detect stateless function(see #741). What should I do now?

@lencioni
Copy link
Collaborator

lencioni commented Aug 9, 2016

@zachguo It sounds like utils.isReturningJSX might need to be fixed? That seems like a good area to focus your efforts and would likely help a lot of other people.

@ljharb
Copy link
Member

ljharb commented Apr 7, 2017

@zachguo are you no longer interested in completing this PR?

@zachguo
Copy link
Author

zachguo commented Apr 7, 2017

Probably yes for this PR.
When I have time I may try to fix #741 first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

3 participants