Cyclic dependency between Store and Domain object #2474
-
Am I naïve to think cyclic dependency between store and domain object class is wrong or it is acceptable in JavaScript code? Please follow this link for the full code. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
I had a very similar reaction when I saw this. In our code base, we have actions in the store that modify the domain objects (we call them models) and make the API calls. |
Beta Was this translation helpful? Give feedback.
-
OK, I'm not a mobx author, but FWIW I agree with you. I read this before architecting our frontend and consciously decided not to follow this pattern. Our pattern is that only top-level views, and other stores, can directly access a store. Views can pass in store data to components through properties. Giving domain objects access to stores seems like recipe for spaghetti code. Also, this design assumes very simple REST APIs, which isn't true in our case. It also requires dispose() to be called on model objects or you have a leak. |
Beta Was this translation helpful? Give feedback.
-
Same answers as in #2483: MobX does technically zero care about how you organise your store. The documented pattern is just one of dozens approaches that could be taken in organising models / store / views / data. It was written because "we don't care" was too much freedom for many to handle. So the documentation is just a way in which it could be done, and you should definitely not read too much into it. If you have any argument to deviate from it, by all means do. So please don't read the docs as 'this is the best way to architect your application', but rather 'if you have no clue how to get started, here is a way'. That is what we tried to say in the intro:
If that can all be clarified better, feel free to PR on the docs |
Beta Was this translation helpful? Give feedback.
Same answers as in #2483:
MobX does technically zero care about how you organise your store. The documented pattern is just one of dozens approaches that could be taken in organising models / store / views / data. It was written because "we don't care" was too much freedom for many to handle. So the documentation is just a way in which it could be done, and you should definitely not read too much into it. If you have any argument to deviate from it, by all means do.
So please don't read the docs as 'this is the best way to architect your application', but rather 'if you have no clue how to get started, here is a way'. That is what we tried to say in the intro: