Closed schuchard closed 4 years ago
Lets squash all the commits for this into one, with a proper commit message as described last night:
feat|fix|refactor: <message>
+ Additions
- Removals
* Other stuff
<related issues>
ready to go @jrista
What do you think about extending this pattern to the Load*
actions and expose the following?
LoadFailure
- key
LoadManyFailure
, LoadAllFailure
- criteria
LoadPageFailure
- page
LoadRangeFailure
- range
Another question, should we also be passing the criteria in the failure cases as well? There could be identifying information in there as well, but this could be in a later PR?
Just realized the types are not accurate for the action. entity
, entities
, key
, and keys
are not coming through no the action type. Need to make a few more changes.
false alarm, it turns out we need to explicitly type the action to pickup the properties.
ofEntityType<Customer, CreateFailure<Customer>>
What do you think about extending this pattern to the
Load*
actions and expose the following?
LoadFailure
-key
LoadManyFailure
,LoadAllFailure
-criteria
LoadPageFailure
-page
LoadRangeFailure
-range
Another question, should we also be passing the criteria in the failure cases as well? There could be identifying information in there as well, but this could be in a later PR?
Yeah, there is no reason we can't thread all the relevant information through the entire chain of actions.
We might as well go ahead and do that. One of the other stories is also to expand our action patterns from a two-stage to a three-stage patern. From Initiaor -> Result to Initiator -> Response -> Result. I guess it is up to you whether you want to make the changes you recommended here, or maybe wait for the three-stage pattern story, and make them when we make that change?
EntityActionTypes
, fix lint error in reducerfixes #115