Add basic support for custom HOCs #60
Conversation
| { | ||
| name: "should be invalid when custom HOC is used without adding it to the rule configuration", | ||
| code: "const MyComponent = () => {}; export default observer(MyComponent);", | ||
| errorId: ["localComponents", "anonymousExport"], |
There was a problem hiding this comment.
I had to add support for multiple error IDs since we don't have a dedicated message for HOCs. I'm unsure how difficult it would be to detect HOCs while differentiating them from other types of exports and create a dedicated message ID
There was a problem hiding this comment.
Looks great!
I dont think the redux connect pattern works though, init.callee.type with be another call expression in that case I think.
For the part custom message suggestion, I think it can make sense to have a dedicated message when:
- At least one local component was found (keep the name of first one in a variable, or all in a list)
- The default export is a call expression, and one of the arg is an identifier of a local component
While this will not work when the default export is first, I think it should allow the common case to work without too much false positive
Both this improvements are totally optional and can be either done in this PR, by you in another PR or later when someone request it (I've been using only hooks for 5 years so this cases are not my priority) and we can merge this as is, your call!
|
Let's merge it! If someone else needs this maybe we can look into adding those improvements as well 😄 |
Fixes #59 for MobX's
observerand other custom HOCs that follow the most common pattern.HOC pattern covered (simple HOCs):
HOC patterns not covered because we would need to refactor to look for component identifiers in other argument positions (not just the first), and most likely generalize the implementation for redux's
connectHOC.Adding support for simple HOCs brings the most value because HOCs with weird implementations, such as the one with multiple parameters and the component coming last, might be rare (we have some of those in my work codebase, but we'll replace these with hooks).
As follow-up work, it might be nice to detect exported components with HOCs that aren't in the
customHOCslist and raise a particular error message that tells the developer about thecustomHOCssetting.Thoughts? cc @ArnaudBarre