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 Request] Store without a Fetcher #536

Open
fardavide opened this issue Mar 13, 2023 · 5 comments
Open

[Feature Request] Store without a Fetcher #536

fardavide opened this issue Mar 13, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@fardavide
Copy link

Is your feature request related to a problem? Please describe.
I would like to be able to create a (Mutable)Store for local-only data.
The goal is to replace the Repositories with Stores; the issue comes when I can't write directly to a Store that is not Mutable, but to create a MutableStore I need an Updater and a Bookeeper

Describe the solution you'd like

val localStore: MutableStore = 
  StoreBuilder
    .from(sourceOfTruth) // no fetcher
    .build() // it returns a MutableStore, because no Fetcher is declared

Describe alternatives you've considered

  • Keep repositories for local only data -> different approaches in the code-base
  • Pass local data source directly to the use case -> no 🙅🏻‍♂️
  • Create a LocalStore in the project, which would be a clone of Store, but with local data only -> it would be confusing, it would still behave differently from the original Store, without in-memory cache and it would need to be maintained "manually"

Additional context
none

@fardavide fardavide added the enhancement New feature or request label Mar 13, 2023
@fardavide fardavide changed the title [Feature Request] Store without a Fetcher [Feature Request] Store without a Fetcher Mar 13, 2023
@matt-ramotar
Copy link
Collaborator

Hey there @4face-studi0 - Thanks for raising!

@digitalbuddha - Thoughts on a special MutableStore without Fetcher, Updater, and Bookkeeper? MutableStore delegates to Store. On first thought I think we should not change Store to handle this, but have no concern about introducing a new special MutableStore that is effectively OfflineMutableStore.

@digitalbuddha
Copy link
Contributor

Interesting idea, what functionality would this store give you that dealing directly with a source of truth would not?

@fardavide
Copy link
Author

@digitalbuddha from the top of my experience, the main benefits I see are:

  1. performance benefits, trough the built-in in-memory cache
  2. API benefits, since one would already have a Store that matches the pattern used elsewhere in the project, with steam and get methods.

The second one doesn't give a strong practical benefit, but I don't like the idea of having a clone of Store built in the project.
Once you committed to framework, you committed 🙂
As now, the best solution I found for myself, is just using a Store for local/remote data and the classic Repository pattern for local-only one

@digitalbuddha
Copy link
Contributor

Got it thank you for the explanation. Let me give it some thought as edge cases and breaking of the usual unidirectional flow are concerns

@matt-ramotar
Copy link
Collaborator

#556

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
Status: Investigating
Development

No branches or pull requests

3 participants