[core] Remove state.isScrolling

[m4theushw]

One of #820

[oliviertassinari]

One of #820

For this issue, I'm not sure that we need to remove things in the state. Would it work if we segment it instead? Meaning, have different top-level sections:

• state: the root
  • public: the part that developers can store in their DB
  • private: where we store private things

Another alternative is to add a getPublicState method that returns a subset. One downside with this issue is that it doesn't force us to think upfront about what's public and what's private. It's more or less what AG Grid for instance, by forcing developers to cherry-pick what they want to store: https://ag-grid.com/react-grid/column-state/.

If we think about it, what would developers want to store? Based on the duplicates of #820:

• Column reorder
• Column resized
• Column visibility
• Density mode applied
• Filter applied
• Sorting applied

Is there anything else? I don't see it.

[oliviertassinari]

Would it make sense to simplify even futher?

Suggested change

	useGridApiEventHandler(apiRef, GridEvents.columnResizeStart, handleColumnResizeStart);
	useGridApiEventHandler(apiRef, GridEvents.rowsScroll, handleRowsScroll);
	useGridApiEventHandler(apiRef, GridEvents.columnResizeStart, hideColumnMenu);
	useGridApiEventHandler(apiRef, GridEvents.rowsScroll, hideColumnMenu);

[m4theushw]

For this issue, I'm not sure that we need to remove things in the state.

@oliviertassinari I think we have two things to have in mind here. The first one being to solve #820 and another one which is the opportunity to clean the state. Besides the first one, removing data not widely used from the state might be worth it to reduce complexity. Now we have a good view of what kind of information must be in the state and what's used only in one hook. For everything that is not shared between hooks, we could use internal state.

Would it work if we segment it instead? Meaning, have different top-level sections:

My idea would be to have a single state. Having a private state seems that we're storing derived data. With a single state, developers only need to serialize the state and save in their DBs. To restore the session, we just replace the entire state with the newer one, doing some sanity check before (e.g. a column might not exist anymore).

If we think about it, what would developers want to store? Based on the duplicates of #820:

I can also think about pagination, selection and with features like #210 we might want to store other stuff (opened/closed nodes).

[oliviertassinari]

@m4theushw Cleaning the state sounds great.

For the "private state", this option is to use the public state as the source of truth and to use the private state to store intermediary or short-lived state there, stuff that could be recomputed at any time, the same way of how useMemo behaves "You may rely on useMemo as a performance optimization, not as a semantic guarantee.".

[flaviendelangle]

Yeah it's a great idea to remove this kind of data from the state, it will help a lot when trying to change the implementation of the state.