Hey everyone, just dipping my toes into Store5 and...

# store

[Jeffrey Dawes]

Hey everyone, just dipping my toes into Store5 and wondering what pattern most people follow when it comes to writing Repository interfaces. I see some examples where people leverage StoreResponse as their returns types and others where they use their own types. In this case, I'm specifically curious about Flow return types. What is the guidance on this topic, if any?

I was planning to map the StoreResponse to my Result type class to simplify since it only has a loading, success, and error state. But then I would lose the nice things like the response origin. What has been other people's experience with this? Do you commit to exposing Store classes from your repositories or do you map to a similar or identical local class?

[Matthew Ramotar]

My preference is for Store to be an implementation detail of the Repository. My repository APIs don't expose any Store APIs. My general approach: https://store.mattramotar.dev/guides/get-started/quickstart#using-the-store

[Matthew Ramotar]

(This means Repository APIs are standardized across the codebase, but implementation details are flexible)

[Jeffrey Dawes]

Thanks, Matt! I saw the example was for suspend functions and not Flow. Do you have a monad class that you map to for Flow return types as well?

[Matthew Ramotar]

I'll add an example with a Flow too, but same idea of abstracting StoreReadResponse as an implementation detail of the generic Repository that you own

[blakelee]

At my job I'd use the same Result obj you are talking about. At home I just want to build stuff so I use the StoreResponse in my repository then finally convert to a UI model in my VM equivalent.

[Jeffrey Dawes]

Yeah that’s an understandable choice as well! My plan is to map to a result object in my project for now just for muscle memory so it transfers nicely to work life 😁