-
Notifications
You must be signed in to change notification settings - Fork 9
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
Consider all-uppercase exports as components #11
Comments
Yeah when I wrote it the first time I knew this could be improve by looking at what is the value type. I though I would need type info from eslint-typescript but actually I think allowing any function and disabling the rest should be ok. I will change this :) |
Return value analyzation would be awesome, yes. |
The rule is still giving me trouble when the component is wrapped: These work: export function SVG() {
return <svg/>;
} export const SVG = () => {
return <svg/>;
}; These all fail: export const SVG = forwardRef(() => {
return <svg/>;
}); export const SVG = memo(forwardRef(() => {
return <svg/>;
})); export const SVG = memo(forwardRef(function SVG() {
return <svg/>;
})); |
Added in 0.4.1 (I've decided to not use type analysis because this could block a lot of people (not the default with TS-ESLint), so I need to add cases one by one) |
Why not consider uppercase exports as components? I for example have one like this:
It's mostly stylistic, but a
Svg
looks suboptimal to me.Another idea may be that such a component could just be automatically detected as one because it returns JSX content, e.g. don't purely rely on export name, but actually analyze the return value of the function.
The text was updated successfully, but these errors were encountered: