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

feature: Multiple indices in EntityStore #43

Closed
j2L4e opened this issue Aug 1, 2018 · 6 comments
Closed

feature: Multiple indices in EntityStore #43

j2L4e opened this issue Aug 1, 2018 · 6 comments
Labels
enhancement New feature or request

Comments

@j2L4e
Copy link

j2L4e commented Aug 1, 2018

edit: I just realized, this isn't the best example, because you could already have the needed index in the tags EntityState. But you get the gist.

Example: you might want to look up items by a tag that's attached to it. Say we have an EntityStore with items where each item can have one or several tags (by id, assume a normalized state).

const items = [
  {id:1, tags: [1, 2]},
  {id:2, tags: [1]}
  {id:3, tags: [2, 3]}
];

The resulting State looks like this:

{
  entities: {
    1: {id:1, tags: [1, 2]},
    2: {id:2, tags: [1]}
    3: {id:3, tags: [2, 3]}
  },
  ids: [1,2,3]
}

Filtering or finding items by tag is cumbersome and slow. It'd be nice to get the possibility of indexing items by one or more keys different from id to get a state similar to this one:

{
  entities: {
    1: {id:1, tags: [1, 2]},
    2: {id:2, tags: [1]}
    3: {id:3, tags: [2, 3]}
  },
  entitiesByTag: {
    1: [1, 2], // just the ids for brevity, actual entities should be here
    2: [1, 3], 
    3: [3]
  },
  ids: [1,2,3]
}

Implementing this reactively isn't feasible as you'd have to either diff or reindex the entire thing on every state change.

@NetanelBasal
Copy link
Collaborator

Actually you can do it easily with the filterBy option:

selectAll({ filterBy: entity => entity.tags.includes(tagId) })

As for the performance, I don't think there should be a significant problem. Browsers are highly optimized when it comes to for loops. Did you experience a performance issue?

@NetanelBasal NetanelBasal added the enhancement New feature or request label Aug 1, 2018
@j2L4e
Copy link
Author

j2L4e commented Aug 1, 2018

Thanks. You are right, this might be a case of premature optimization. It does have its place though, when you handle larger amounts of normalized data, especially on less powerful clients.

@NetanelBasal
Copy link
Collaborator

Agree, but I think it's hard to develop something that will satisfy all cases.

@hiepxanh
Copy link
Contributor

I think that your case is very good example for the document @j2L4e then should we close this issue?

@NetanelBasal
Copy link
Collaborator

Yes. Closing for now.

@oleersoy
Copy link

There's Relational Pouch so if the store is persisted to pouchdb it might be a good solution performance wise. Hoping to get time to play with it soon.

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

No branches or pull requests

4 participants