Vuex structure for similar data in many places of UI

[lon9man]

Need advices about practice for the next case..
simple describe:

UI have saying N places with list of Users/xxxx/yyyy
Each! such place have different sorting, paging, where-clauses and etc, but all this rows are Users/xxxx/yyyy
Which way to use to build good maintainable extendable state architecture?

saying for example:

1. Table1 shows ALL users sorted by Nickname ASC (page 1 of 100)
2. Table2 shows ALL users sorted by Nickname DESC (page 1 of 100)
3. Table3 shows ONLY active users (where is_active = true, page 1 of 100)
4. Table4 shows FILTERED users by some clauses, selected in UI (where created_at > XXXX and sex = 'M' and salary > YYYY)
5. ...

so problem here are:

1. ALL data in these tables are USERS, so it requested by 1 API, but with different input parameters
2. responses from this 1 API should be saved in 1 store USERS to have one place of truth, BUT also each table should have own store with foreign keys to render this records with concrete sorting, filtering, paging and etc.

things become worse, when each USER have relations:

• User->Emails
• User->Addresses
• User->Friends
• ...
  these relations ALSO can be used in different places of UI, can have different sorting/paging/filtering, should have 1 store per each entity for 1 source of truth, each entity should be asked by unique separate API (Emails, Addresses, Friends, ...), but each UI-place should have own store to render data with correct order.

so all this logic in some way should be injected into structured vuex-store.
don't see some real interesting examples in the internet.

Thanks

[lmiller1990]

This sounds like a very domain-specific problem. Basically, a complex filtering engine.

I'd recommend normalizing the data as much as possible, then having specific functions to derive said data. It sounds like a spreadsheet - there's lots of information about building this kind of thing out there, maybe start searching based on that.

Depending on the size of the data, I might opt to handle this all on the backend, but it depends on your use case.