ok. would this be more accurate then?
src/app src/app/store src/app/store/entityType1 src/app/store/entityType1/entityType1.actions.ts src/app/store/entityType1/entityType1.reducers.ts src/app/store/entityType1/entityType1.state.ts src/app/store/entityType1/entityType1.models.ts
src/app src/app/feature1 src/app/feature1/feature1.module.ts src/app/feature1/feature1.component.ts src/app/feature1/feature1.template.ts src/app/feature1/subfeature/ src/app/feature1/...
seamless-immutableis also better because it respects the exact object signature… you can use the arrays and objects with the exact same methods and they work perfectly, while with ImmutabeJS everything is different from standard
hi @dancancro in my case, I used Swagger to generate an API client and that’s the only API service I have. It is generated outside of
src by a
postinstall npm entry.
Indeed the service is anyhow closer to the application state, but I don’t see them together, as the app state include other stuff that aren’t coming from API, such as calculated values, temporary stuff, cached data, user interactions, etc… I’d better keep the API service in something like
@dancancro I think the idea of a “global app state” is quite plastic. I think most of it is like a local backend, indeed, but not completely, and you probably will find people with different understandings implementing it in different ways.
I’m not very experient on Redux either, so, I’m always curious to see how other people are doing too