Keep one custom registry to make it usable with own implementation

[exls]

I checked your code and the implementation is awesome. But has few disadvantages. Since I found your code the most best, I suggest to change it lit a bit to support custom user/developer registry to make it work with combination of own store mutators/actions.

You use the trick to exclude collisions between instances. Different instance = almost(if I am not mistaken) every time is different registry. But instead of using different registries you can use only one (associate version {id: item}). So, you will need to store only ids in somewhere. This is somewhere is an instance state. In this case you will be able to restore any data as you did before with registry annd instead of indexStart and indexEnd it will be simple Array.map function.

The benefit of this is that you can now use user's registry instead of your internal implementation. For example: I might want to use normalizr.

The disadvantages of your implementation now is that it is difficult to update registry state if I have additional actions. I have to foreach each registry, find an item and update it. Also how to grab/getter one item(from wich registry)? How to update the specific item in the registry...

[MaxGfeller]

Thank you for the feedback, @exls.

This is a very interesting point and i was thinking about that while developing the library. The reason why we didn't do that was because the store doesn't have to have a concept of how data inside looks (it's just lists of elements) and, even more importantly, because data can look different depending on the arguments that were passed. As an example: if you are developing a multi-tenant application and all logged-in users should be able to fetch, let's say, their products, those can look different depending on the user that made the request.

However, you are completely right and i would love to have something like that in v2 of vuex-pagination.

Do you have any concrete idea of how it could look like? It has to be some kind of parameter when creating a new resource and i guess you'd have to pass the id field of the data.

[exls]

May be it should be like this. I can help, but I know only Typescript ;)
createResource creates the store, but instead of this we need to upgrade the store.

I think the package should exports mutators/getters and the base State class. Skillable programmers will be able to join your packacge into any project without breaking...

For lazy developers it might be the function.
upgradeStore(store, 'action to fetch data', 'getter name to take by ids')
behind it will extend the store state, attache the getters and mutators...
UpgradeStore has 2 string parameters:

1. the action name to dispatch to fetch data.(this action should set items in the store, as developer wants). action should return the server data wich is related to the Response iterface
   interface IResponse<T> { total: number; data: T[]; }
   Or we can ask third parameter - callback to take uniq ids from response... Or it can be the name of our specific action wich return only ids and total
   interface IResponse { total: number; ids: any[]; }
2. The getter to return the data by ids(or it can be the call function with state object in arguments)
   The code of getByIds should be simple
   (state: State<any>, ids: number[]) => ids.map(id => state.items[id])
   or like this for normalizr
   (state: State<any>, ids: number[]) => denormalize(ids.map(id => state.items[id]), schema, {entites: {items: state.items}})

All related to the request/response data(specially the fetched ids) will be stored in the instance config.

The interface for the instance ....

interface IInstance { page: number; pageSize: number; total: number; ids: any[]; //... }

By the way, I think there is no need to store instance configurations in the store... It is relevant only for the current component... You do not share it between components and pages...

[exls]

Small mistake. The instance configuration also should be in the store for the SSR .... It means, once server will render and fill the store, on the client side it will be the same and there is no need to fetch data again. This is what I have now... , because do not store instance data in the store

[marianomd]

+1, this would be great.