Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[DataGrid] Fix valueGetter sorting #348
[DataGrid] Fix valueGetter sorting #348
Changes from 3 commits
8a10c75
54a9022
28900e8
6b9b70f
f714ea0
0c931c2
fc48512
775816b
e1fcbda
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we have to stick to a convention between arrow functions and named function. The current one is named function when possible, e.g. for the top-level scope and arrow functions for nested scopes, when inlining is simpler.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you. I prefer the simple and concise syntax of arrow functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, time for a conversation about it then. @mui-org/core-team.
The problem:
There are two ways to write functions: arrow or named. Defining one convention could avoid noise during refactorization (depending on who writes which line), increase consistency (easier to browse codebase) and avoid having to discuss it in reviews.
The question to answer:
When should we use named function vs arrow function? Should we even care? Meaning leaving it up to what the person prefers to be when he writes a line of code or refactor one.
For instance, right now, the
styles
object is always an arrow function when components are always (or almost) a function.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the main problem of named function is that they lose the context. And the syntax is more verbose.
If you define a class in TS, then it's better to use named function as they get attached to the prototype.
if it's a function component then arrow functions are fine.
I think it's important to be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't matter we shouldn't enforce either style if it's not auto-fixable. If a lint rule can find and fix it we can configure it however you like. But I don't want to argue every time why I prefer one over the other and I don't want reviewers wasting their time nitpicking code style. There's enough substance to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if you use implicit return. Once you have to use explicit return (and this is something I end up using anyway once you have to debug) the function declaration actually requires one less character.
Another type related downside:
const
arrow function expressions can't be generic.I think it's fairly obvious that there isn't a rule to use one or the other. Eventually you have to use function declarations anyway so why disallow them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so we are leaning toward: no rules, use whatever you find best in the given context?