Closed franciscomorais closed 3 years ago
Hi @franciscomorais, thanks for the feedback and for making a PR. I appreciate the proactivity.
This is by design and documented in the wiki:
...when you resolve with
null
orundefined
, the payload property is not included. It would be redundant to include it.
I'm OK with revisiting the design, but can you elaborate on why this is important to you? What's the goal of this change / the problem you're solving? Is it a philosophical argument about the design or is there a technical argument / use case?
Hi @franciscomorais, just following up.
Hi @pburtchaell, we have a "REST API request middleware" build over redux-promise-middleware
that we use to simplify creating request actions. We resolve the API request response which is then stored in a reducer.
In cases where endpoints respond with 204
and no data we're forced to make the promise resolve with an empty object, while we'd like to resolve null
, as that would make more sense, but doing so makes the reducer throw, as redux doesn't allow reducers to have undefined
as their state.
Version: 6.1.2
Actually, the
getAction
util could be response to an object without payload property. It should return an object with payload property.However, I think that this property should return the payload with null if he receives a null or undefined knowing that one reducer can't be undefined. What do you think?
Steps to Reproduce
Expected Behavior
Actual Behavior