app.state.tsto manage the HMR state, but it has nothing to do with the Redux’ app state interface… I suggest you to rename it to prevent confusion
src/app/storeas that defines the app’s global state
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