-
Notifications
You must be signed in to change notification settings - Fork 0
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
Clarification about: When using arrow functions as named exports, explicit return should always be used to maintain consistency with regular functions. #57
Comments
Hi, thank you for your report. This is actually just my personal coding style 😂 👇 Please see the example below: // A simple function with named export
export const getUser = async () => fetch('/api/user').then(res => res.json())
// A React component with named export
export const User = ({ user }) => <u className="no-underline font-medium">{user.name}</u>
// ---
// Compare regular functions, I think they are more intuitive.
export async function getUser() {
return fetch('/api/user').then(res => res.json())
}
export function User({ user }) {
// I can add things here at any time.
return <u className="no-underline font-medium">{user.name}</u>
} When used as named exports, it proves that they are reusable. I hope to maintain a consistent function style, which will also make it easier to add code in the future. My idea is that although implicit return is concise, it is not conducive to expansion, so it is best to use it only in very simple anonymous callback functions. If you really don't like this, I can add an option to allow disabling it. |
I see what you mean, it mostly make sense. But yeah, a config option for this could be nice |
Hmm, yes, after all, everyone has different habits. I will add it. |
https://github.com/u3u/eslint-plugin-arrow-return-style/releases/tag/v1.3.0 |
Thank you, that's perfect! |
Can you expand in the docs what you mean by this, and what is the purpose?
The text was updated successfully, but these errors were encountered: