Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support different data sets for the same resource #327

Open
mrotaru opened this issue Nov 23, 2017 · 2 comments
Open

Support different data sets for the same resource #327

mrotaru opened this issue Nov 23, 2017 · 2 comments

Comments

@mrotaru
Copy link

mrotaru commented Nov 23, 2017

Seems like currently there is no way for an endpoint to be used by multiple components, with different query params.

Something like:

<PostList limit={10} tags={['foo']} />
<PostList limit={10} tags={['bar']} />

This will result result in two API requests being made, each having a different set of items in their response. However, due to how the store works currently, this would reslut in a race condition, with the slowest API response eventually "winning" and it's items being fed to both components.

@diegohaz
Copy link
Owner

Hey, @mrotaru.

That's how the example works. You need to modify the store to be able to accept multiple lists.

If you find a non complex way to handle both cases, a PR is very welcome. :)

mrotaru added a commit to mrotaru/arc that referenced this issue Nov 26, 2017
@mrotaru
Copy link
Author

mrotaru commented Nov 26, 2017

So I had a stab at this, as visible above. Essentially, you'd somehow give each such component a unique identifier, and then use that throughout the store (reducers, sagas, etc) to build a separate list for each of them:

      <PostList limit={5} listId="1" />
      <PostList limit={5} listId="1" />

In the example, I'm building the query params by just taking listId and passing it as the userId param, so the two PostList components have different data sets. The query params could be passed as a separate prop, of course.

I'm not happy with this, as it's a leaky abstraction - see how in PostList container you have to know how to build the strings for hasFailed etc. I think the correct solution would involve abstracting these issues, with unique list id's generated automatically - perhaps by hashing the params object.

However, this is quite simple and I'll base something off this for our project at work. Not sure if it's worth merging though, let me know if you want it and I'll add some more tests (existing ones pass, but no new ones) and make a PR or feel free to close this issue, as it might be going beyound the scope of the examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants