[DataGrid] Fix valueGetter sorting

[dtassone]

No description provided.

[oliviertassinari]

Ok so the approach is to fix the demo in the documentation and we will wait to consider altering the RowModel object with the valueGetter() returned value.

[oliviertassinari]

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.

Suggested change

	const getFullName = (params: ValueGetterParams) =>
	`${params.getValue('firstName') || ''} ${params.getValue('lastName') || ''}`;
	function getFullName(params: ValueGetterParams) {
	return `${params.getValue('firstName') || ''} ${params.getValue('lastName') || ''}`;
	}

[dtassone]

Up to you. I prefer the simple and concise syntax of arrow functions.

[oliviertassinari]

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.

[dtassone]

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.

[eps1lon]

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.

[eps1lon]

And the syntax is more verbose.

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?

[oliviertassinari]

Ok, so we are leaning toward: no rules, use whatever you find best in the given context?