Okay finished, great work. I would love to see a follow up on unit testing. I am going over this now. I find it strange that you spoke about the importance being able to easily test your service layer but then made your service a singleton. Singletons are hard to test.
It appears you intend to only use your SpotifyService as a wrapper around the SpotifyApi and then test your service only through the store. Do you agree with this?
Also why do you need the service to be in the store? Why not just use the service directly in your component?
Thank you for taking the time to write this. It's the best article I have found so far on enterprise grade design patterns for MobX. Everyone else has half backed solutions that don't scale well.
What is about SpotifyService, I want to use my wrapper around the Spotify API client in the first version of the application, you're right. If I change dependency for my solution, I need to change the only layer and don't rewrite tests.
We can use service directly in our containers (in practice, this turned out to be true) and we can separate business logic between Stores and Containers. My structure has changed after several months of work, I will update this article with the new architecture later. Shortly, new architecture includes two types of stores: Domain Stores & Local Stores. Domain Stores - stores with shared info (responses from backend, some data for many components, etc) in src/stores/, Local Stores - small stores are in the components directory for many components (containers) src/pages/status/ for example. And yes, you can use services inside components in a new architecture approach.
And I switched to Mobx 6 and some examples are outdated... I need time to rewrite the article and update code examples, architecture approaches, etc
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Okay finished, great work. I would love to see a follow up on unit testing. I am going over this now. I find it strange that you spoke about the importance being able to easily test your service layer but then made your service a singleton. Singletons are hard to test.
It appears you intend to only use your
SpotifyServiceas a wrapper around the SpotifyApi and then test your service only through the store. Do you agree with this?Also why do you need the service to be in the store? Why not just use the service directly in your component?
Thank you for taking the time to write this. It's the best article I have found so far on enterprise grade design patterns for MobX. Everyone else has half backed solutions that don't scale well.
Hi Stephen, could you tell me what RootStoreModel looks like and where it fits in? Thanks
Thanks for your feedback!
What is about
SpotifyService, I want to use my wrapper around the Spotify API client in the first version of the application, you're right. If I change dependency for my solution, I need to change the only layer and don't rewrite tests.We can use service directly in our containers (in practice, this turned out to be true) and we can separate business logic between Stores and Containers. My structure has changed after several months of work, I will update this article with the new architecture later. Shortly, new architecture includes two types of stores: Domain Stores & Local Stores. Domain Stores - stores with shared info (responses from backend, some data for many components, etc) in
src/stores/, Local Stores - small stores are in the components directory for many components (containers)src/pages/status/for example. And yes, you can use services inside components in a new architecture approach.And I switched to Mobx 6 and some examples are outdated... I need time to rewrite the article and update code examples, architecture approaches, etc