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

Operator to support AJAX persistence and multicasting #2013

Closed
benlesh opened this issue Oct 6, 2016 · 12 comments
Closed

Operator to support AJAX persistence and multicasting #2013

benlesh opened this issue Oct 6, 2016 · 12 comments

Comments

@benlesh
Copy link
Member

benlesh commented Oct 6, 2016

Currently, there's a PR to remove cache #2012. The original intention of cache was to support use-cases, mostly coming from the Angular 2 community, revolving around wanting to persist successful AJAX requests, but still enable retry and retryWhen on failed AJAX requests.

This operator should

  1. Multicast the source observable
  2. Keep all values and "replay" them after a successful completion
  3. Enable "retrying" on error

Stuff to consider, and unanswered questions:

  1. What are the behaviors when applied to a never-ending observable (Observable.interval(100), for example)
  2. How will this operator behave when applied to another hot observable?

Possible Solutions

  • Re-add the cache operator but rename it to something more descriptive of it's purpose.
  • Add a simplified operator that takes no arguments called shareResults proposed here

For sake of discussion, we'll call this operator persist.

@StephenFluin
Copy link
Contributor

I love the cache operator. The name doesn't matter to me, but I hope it exists somewhere. I'm aware that I can manually do this with publishReplay and connect, but cache was simpler and cleaner.

I often use it to share data across components/routes when making HTTP requests that don't need to be refreshed often:

https://github.com/sjtrimble/fluin.io/blob/master/src/app/shared/post.service.ts

Or I used it to eliminate re-processing of incoming data from data streams.

https://github.com/StephenFluin/ames/blob/e5502d1d0aadb44d44ec1fde659ed94ebf74057f/src/app/shared/auth.service.ts#L33

@benlesh
Copy link
Member Author

benlesh commented Oct 11, 2016

@StephenFluin it should be noted that publishReplay()/connect() can't be "retried", really. On failure, it's just done.

@benlesh benlesh changed the title Operator to support AJAX persistence and mulitcasting Operator to support AJAX persistence and multicasting Oct 11, 2016
@benlesh
Copy link
Member Author

benlesh commented Oct 11, 2016

What if we simplified it to always persist all values and multicast and we called it shareResults? I think that implies that even after all value have arrived, all of them are kept as "results" and shared amongst all subscribers. There would be no arguments.

Observable.ajax.getJSON('http://something.com/whatever').shareResults();

Thoughts?

@benlesh
Copy link
Member Author

benlesh commented Oct 11, 2016

I also think shareResults keeps some similarity to the share operator, which has a similar behavior, retry-wise, but adds that little extra to imply result persistence.

@alex-novikov-1990
Copy link

Use-case to consider (shared auto-updating value, which should not be updated in periods without subscribers):

if (cache) { return cache; }

let serviceCall = Observable.ajax.getJSON('http://something.com/whatever')
    .retryWhen(errors => errors.concatMap(() => Observable.timer(period)));

cache = serviceCall
    .expand(() => Observable.timer(period).concatMap(() => serviceCall))
    .cache(1, period);

return cache;

@benlesh
Copy link
Member Author

benlesh commented Oct 11, 2016

@newsash I think we'll introduce a cache with more robust cache insertion and eviction logic for scenarios like that. It's probably out of scope for this common use case.

@StephenFluin
Copy link
Contributor

@Blesh shareResults sounds great, any chance it will land in RC2? I'm trying to avoid building my own.

@IgorMinar
Copy link
Contributor

+1 for shareResults or even shareResult - we currently don't have usecases where we would want to replay more than the most recent result/value.

@StephenFluin
Copy link
Contributor

Any update on when this might land? It's a highly desirable operator.

@christianacca
Copy link

Would it be possible to include a parameter that will control how many previous emissions are replayed?

That would also satisfy @IgorMinar request.

benlesh added a commit that referenced this issue May 9, 2017
`shareReplay` returns an observable that is the source multicasted over a `ReplaySubject`. That replay subject is recycled on error from the `source`, but not on completion of the source. This makes `shareReplay` ideal for handling things like caching AJAX results, as it's retryable. It's repeat behavior, however, differs from `share` in that it will not repeat the `source` observable, rather it will repeat the `source` observable's values.

related #2013, #453, #2043
@benlesh
Copy link
Member Author

benlesh commented Jan 25, 2018

This is shareReplay, really. Closing.

@benlesh benlesh closed this as completed Jan 25, 2018
@lock
Copy link

lock bot commented Jun 6, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants