You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a real problem or use-case?
Add support for an error field to createAction so it is compliant with Flux standard action specification.
This will open the possibility to use typesafe-actions with other solutions or applications that are relying on that pattern.
Describe a solution including usage in code example
How it would work type-wise?
Most probably an optional error field added to the base Action type:
typeAction={type: string;error?: boolean;}
How it would work at runtime?
I would go with a forced convention by having a payload to be an instance of Error (easy to implement, backward compatible does not change API and I think that's the most popular option)
This would automatically set the error property to true, but also it could allow leveraging conditional types to refine Action type even further to show or hide error property from the action type. That would be the most optimal solution.
Who does this impact? Who is this for?
All users
Describe alternatives you've considered (optional)
When I started working with your library, I naturally tried to pass an instance of Error to the createAction and I was secretly hoping that the boolean error was automatically set, but it wasn't.
So when I'm reading this:
I would go with a forced convention by having a payload to be an instance of Error (easy to implement, backward compatible does not change API and I think that's the most popular option)
This would automatically set the error property to true, but also it could allow leveraging conditional types to refine Action type even further to show or hide error property from the action type. That would be the most optimal solution.
Is your feature request related to a real problem or use-case?
Add support for an
error
field tocreateAction
so it is compliant with Flux standard action specification.This will open the possibility to use
typesafe-actions
with other solutions or applications that are relying on that pattern.Describe a solution including usage in code example
Most probably an optional error field added to the base Action type:
I would go with a forced convention by having a payload to be an instance of Error (easy to implement, backward compatible does not change API and I think that's the most popular option)
This would automatically set the
error
property to true, but also it could allow leveraging conditional types to refine Action type even further to show or hide error property from the action type. That would be the most optimal solution.Who does this impact? Who is this for?
All users
Describe alternatives you've considered (optional)
Additional context (optional)
Related #108
The text was updated successfully, but these errors were encountered: