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

Strategy updates: passive and active #71

Open
daffl opened this issue Oct 3, 2017 · 2 comments
Open

Strategy updates: passive and active #71

daffl opened this issue Oct 3, 2017 · 2 comments

Comments

@daffl
Copy link
Member

daffl commented Oct 3, 2017

Currently, the smart strategy removes entries when they get deleted and tries to add them to lists (in the right spot) if they match the query.

There are some edge cases that currently are not covered:

  • If the entry is smaller or larger it will get added to the beginning or the end of the list respectively. This might not necessary be the case (e.g. when you $skip and $limit there is no certain way of determining if it is in the list or comes at a position after/before)
  • If an entry gets deleted, it gets removed from reactive lists. If you set $limit they can end up smaller than what you would expect.

If you wanted to cover those edge cases you would use the always strategy which is less than ideal (ultimately I'm not sure it should exist at all).

This is where I think it makes sense to introduce two new list strategies (and remove the smart strategy):

Passive

The passive strategy will update exiting entries in the list (and re-order accordingly) and remove deleted entries but otherwise not modify it (new or updated entries that match the query will not be added).

Active

The active strategy will request a window slightly larger than $limit to be aware of its surrounding entries. That way it will be able to determine for any matching entry where it fits in. If the window gets too small (e.g. because entries were removed from the list) it will re-request a new list.

@j2L4e
Copy link
Collaborator

j2L4e commented Oct 5, 2017

I recently cleaned up the strategies a little further and made the source a real cold observable (https://github.com/j2L4e/feathers-reactive/blob/cleanup/src/utils.js#L10).
With this we can just switch the stream to the source to refetch data from the server. Implementing the above should be way easier that way. Check how 'always' does it now: https://github.com/j2L4e/feathers-reactive/blob/cleanup/src/strategies.js#L25

To requery when there's not enough data available we could do something like this:

// (pseudoish)
smartStream$
  .do(page => {
    if(lessThenExpected(page.data)) throw `someError`;
  })
  .catch((err, caught$) => caught$);

@j2L4e
Copy link
Collaborator

j2L4e commented Feb 14, 2018

A solution for the second (and easier to solve) edge case and requerying in general:

https://github.com/feathersjs-ecosystem/feathers-reactive/compare/autoretry#diff-2b4ca49d4bb0a774c4d4c1672d7aa781R87

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

No branches or pull requests

2 participants