Refactor frontend stores for table-data

[pavish]

Purpose of this refactor:

1. Our tableData store handles colums, records and meta information needed for parameters and display purposes. It also includes the type definitions for all of them. This makes it cluttered, and there is an overlap of different concerns.
   A better approach would be to split it into separate stores, and have a parent store which maintains the rest.
2. Currently, logic of certain requirements such passing parameters to table record request, refetching table data when params change etc., are done on the component. This can be side stepped and done entirely by observing store values. This gives a cleaner view/data model.
3. We need to simplify certain display specific stores such as column position map, to improve readability.
4. General improvements, separate out cells from header and row as different components.
5. Update svelte, vite and related packages.

[dmos62]

While working on some things that used the stores namespace I too found it cluttered. I'm happy to see that the refactor isn't being put off.

I'll share some ideas I had.

I think semantically and modularly it would be nice to make the stores namespace thin, holding declarations of Readables and Writables and not much more, referencing the logic for their declaration from other namespaces. That would imply one or more other parallel namespaces that would sit between the stores and the HTTP client. This would give a central place for holding state and declaring its flow graph, without the mixing of logic.

It's desirable that the structure of the stores and the modularity of logic follow the spirit of the API (which may require a refactor as well).

Hope these thoughts are useful.

[pavish]

@dmos62 Thanks. Your comments make a lot of sense.

That would imply one or more other parallel namespaces that would sit between the stores and the HTTP client. This would give a central place for holding state and declaring its flow graph, without the mixing of logic.

This is a cleaner structure, and I did consider it while starting on the stores. But that would have been premature optimization. These were my reasons:

The major issue with making modules thin on the frontend is that it eventually leads to a larger build size. The approach module bundlers use to bundle frontend code results in a set of boilerplate code for each file when it's built. The more the number of files, the higher the bundle size.

The tradeoff here is between good user experience (with lower load time) and good developer experience(with thinner modules). As a team, we prioritize the user.

It was a calculated decision to keep all the stores and their respective api calls in one place. We only refactor when it becomes essential, as in this case, where each of the stores are better managed separately. However, separating the api layer would still be premature at this juncture. We can get to it when we reach the point where it becomes essential.

[mr-gabe49]

I'm so sorry, I don't know what I did. I was playing around. It says I modified the milestones: 06. 2021-09 Stability, 22. 22 Alpha Release. I fixed it :).

[kgodey]

@mr-gabe49 No worries.

[pavish]

This issue has the following tasks:

• Update svelte and vite to latest versions
• Handle segregation needed for views
• Create dedicated stores for columns, records, meta, display
• Handle records re-request directly in store bypassing component layer
• Handle column position recalc directly in store bypassing component layer
• Handle record deletion directly from store
• Use pagination instead of infinite scroll
• Handle URL sync from store instead of component layer
• Handle grouping on store response instead of component
• Fix errors reported by svelte-typecheck
• Separate cells from header and row

PRs that handle these:

• Tabledata store reorganization #654

Yet to handle:

• Handle URL sync from store instead of component layer

[kgodey]

@pavish It seems like there's one item left to do on your list, so I'm reopening this. Feel free to close if the URL sync is already done.

[pavish]

@kgodey Thanks. I missed the fact that the issue got closed. It's not yet been handled, I will handle it in future PRs.

[pavish]

@kgodey We have a dedicated milestone for Sharing.

I think URL sync belongs in that milestone. Let me know your thoughts.

[kgodey]

@pavish What is the current state of URL sync? If there's broken functionality, I think it would be better to fix it sooner.

[pavish]

@kgodey URL sync currently does not retain pagination, filters, groups and sort. Syncing for these parts need to be re-implemented based on the new stores. I was thinking it belongs more in the Sharing milestone, but now I agree that it's better to fix it sooner.

[kgodey]

@pavish I'll leave it in here then.