grimunit
commented
7 years ago Well we ended up just opting for using the vanilla backand sdk and are now just using the genereated redux actions/constants/reducers as a reference to copy and paste from. We're finding it easier to be able to just deal with the vanillabknd-sdk promises directly as opposed to having everything first dispatched to the store. Figuring out how to compose several calls together that depend on each other with that approach is pretty difficult. You end up relying too heavily on the different life cycle methods to manage dependent async calls.
Honestly this approach would probably work well with redux sagas because you could just dispatch actions and have your saga watchers communicate with each other without the need for promises. Anyhow, figured I'd update on what we ended up moving forward with.
Hey so we decided to pull in reduxbknd-sdk to our repo as a subfolder at the same level as node_modules instead of relying on it as a node module. That way we are able to commit all of our generated code and also move forward with making changes locally to the create methods in the callbacks. If you had another way in mind for people to consume this please let us know, because keeping it as a node_module doesn't seem very intuitive for changes since they'll be wiped out, and keeping them in sync with other members of the team wouldn't be very feasible.
So after we brought it in, we're having trouble with importing the vanillabknd-sdk since there probably needs to be some alias resolving within webpack. Will continue to try to figure out how to get it to point to the right dependencies, but in the meantime I figured I'd ask if were heading in the right direction with this, or did you intend for everyone to have to regenerate their objects every time you have to wipe out your node_modules directory, which is pretty frequent with how often you need to re install your dependencies when someone updates/adds dependencies.
As a quick illustration of our folder structure: