return promises from mutators
Description
Environment
Potential Workaround
blocks
is duplicated by
Checklist
hideTestRail: Results
Activity

Mike Taylor September 8, 2017 at 1:27 PMEdited
(I removed this comment, as it is superseded by )

Jakub Skoczen September 8, 2017 at 1:21 PM
, could you provide an example of how to chain mutations of two different resources A and B using promises, where B mutation required data from resource A?

Jason Skomorowski August 20, 2017 at 9:12 PM
The goal of stripes-connect was for components not to have to conditionally render changes based on callbacks. Instead, they are passed props representing all relevant state and only need concern themselves with representing that moment in time. Changes to state are made via the props.mutators
object and will trigger the component to re-render with the new state. In addition to being more straightforward to write, this will be handy for testing as you only need verify the expected output is obtained for some given input and the expected mutations triggered for some given interaction.
In reality we're running into some shortcomings with this model:
third party software doesn't have any idea about stripes-connect and tends to, as in the case of redux-form, expect promises for async operations.
we want to trigger something external to the component (eg. closing a modal, issuing a notification, whatver) upon the success of a mutation, while remaining at the component and presenting the failed state otherwise. This might be addressed eventually by improvements to the mutation API to allow for chaining, at the moment there is no design for that, let alone implementation. And it's questionable if that could even handle all eventualities without just being a non-standard promise implementation.
And so, reluctantly, mutators need to return promises too. Almost have this done (in the moments I've snatched here and there during a bit of a weird week) but not quite ready to go yet as it turns out to be mildly more fiddly than expected to add this while maintaining the existing functionality (needs to re-throw so HTTP errors can be caught this way which changes the way resources.failedMutations is handled, took a bit of rolling it around to see what to return so we can have a catch()
inside stripes-connect but still allow for an optional additional one outside, etc.)
Jason and NE will provide more information.