[DataGrid] Implement base foundation for editing a cell

[dtassone]

This PR establishes the basic foundation of editability in the grid. This includes the api methods, the hook and the basic edit input component for the basic column types.

https://deploy-preview-1025--material-ui-x.netlify.app/storybook/?path=/story/x-grid-tests-rows--edit-rows-control
https://deploy-preview-1025--material-ui-x.netlify.app/storybook/?path=/story/x-grid-tests-rows--edit-rows-basic

TODO

• fix serverside edit, control mode switch.
• fix params passed in new handlers
• add handlers on apiRef
• add api description, gridOptions, api...
• add tests
• add docs

One iteration on #203.

[oliviertassinari]

Once we are done with the POC. I think that the next step should be about aiming for merging, with the smallest chunk of value possible. We could break it down into smaller PRs if needed but not necessarily. I think that simply saying we have done enough for this first iteration, adding docs, tests, etc. so we can merge should do it.

I'm repeating it because the last large feature (filter) didn't go well. We have blocked merge on master for a week. Do docs, tests in different PRs. We didn't get the chance to do real code reviews, hence we couldn't self-reflect on improving the code. The first time to get the learning experience is normal, twice is not. It's important we move in small be solid steps, even if it feels slower with a short-term lense. I think that the quality of the solution should always come first, it's a great way to differentiate ourselves in this mature market :). If we have to trade, we can trade by solving fewer problems, not on the quality of the solutions.

There is still a place for YOLO, especially when saying solution X is good enough. On the process, I think that we should be rigorous.

[dtassone]

Should we implement double click to edit a cell natively?

[oliviertassinari]

Should we implement double click to edit a cell natively?

What do you mean by "should we"? Do you mean in this first pull request or in the customization demos or in the grid itself?

[oliviertassinari]

It would be great to rebase, it would de-risk conflicts (it has been open for 2 weeks). It would also fix the Argos flakiness

[dtassone]

It would be great to rebase, it would de-risk conflicts (it has been open for 2 weeks). It would also fix the Argos flakiness

I rebased many times already ;)
I will do again

[oliviertassinari]

Things I have noticed, we are close:

• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936. If you enter in edit mode and scroll enough for the cell to be unmounted by the virtualization, it crashes (deep freeze protection we added to hedge leaks)
• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936. When you try to edit a cell, it crashes (deep freeze protection we added to hedge leaks)
• I would like to work on the UI of the editable cell, if it's ok with you.
• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936 When emptying a field by keeping the backspace key hold, it lags (e.g. when editing the "Status" column).
• We should add documentation for the new methods available :)

[dtassone]

Things I have noticed, we are close:

• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936. If you enter in edit mode and scroll enough for the cell to be unmounted by the virtualization, it crashes (deep freeze protection we added to hedge leaks)
• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936. When you try to edit a cell, it crashes (deep freeze protection we added to hedge leaks)
• I would like to work on the UI of the editable cell, if it's ok with you.
• https://codesandbox.io/s/material-demo-forked-dt55t?file=/package.json:0-936 When emptying a field by keeping the backspace key hold, it lags (e.g. when editing the "Status" column).
• We should add documentation for the new methods available :)

updateRow mutate the underlying object for perf reason. The deep freeze is just for the docs sandbox issue

[oliviertassinari]

updateRow mutate the underlying object for perf reason.

What do you think about taking the performance hit in (I guess it's limited since it's a single row) and gain in exchange the immutability of the data?

I assume it could create nasty bugs for the developers, for instance, if the data is shared somewhere else. We had a taste of what non-immutable data lead to with #974. I would be in favor of never allowing the data grid to mutate the args provided by developers.

[oliviertassinari]

From what I understand, we currently need the following follow-up

• add documentation for this new feature
• open an issue about the capture phase event
• improve the UI of the editable field

I also suspect that developers will complain about the edit performance, but we can wait to see. Otherwise, looks good.

[dtassone]

From what I understand, we currently need the following follow-up

• add documentation for this new feature

The feature is incomplete, we have to integrate the default behavior... Do we want it visible in the next release?

• open an issue about the capture phase event

Done

• improve the UI of the editable field

Not a blocker, can be done separately, along with the rest of the feature, what do you think?

I also suspect that developers will complain about the edit performance, but we can wait to see. Otherwise, looks good.

can be tested and fixed separately ??

[oliviertassinari]

I have noticed a bug. When the edit mode is exited, the focus isn't restored to the cell.