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
I was experimenting with BindingAction on some screens that only use BindingActions. I wrote some convenience methods that simplify the reducers. Let me know what you think:
extensionReducerwhere
Action ==BindingAction<State>{publicstaticvarbindingAction:Reducer<State,BindingAction<State>,Environment>{Reducer.empty.binding()}publicfunc binding()->Self{Self{ state, action, environment in
action.set(&state)return.none
}}}
View actions
With this convenience API, we can use BindingAction<State> as the action in the reducer:
One alternative I considered was to create a generic action that embeds BindingAction like the below block of code and use that for actions, but I preferred the above API and call site.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Reducerconvenience methodsI was experimenting with
BindingActionon some screens that only useBindingActions. I wrote some convenience methods that simplify the reducers. Let me know what you think:View actions
With this convenience API, we can use
BindingAction<State>as the action in the reducer:The alternative would be to wrap
BindingAction<State>inside of an enumeration like soReducercall siteAt the call site, I no longer needed to create named reducers. This flow works well when my reducers aren't particularly complicated:
A
CasePathalternativeOne alternative I considered was to create a generic action that embeds
BindingActionlike the below block of code and use that for actions, but I preferred the above API and call site.Beta Was this translation helpful? Give feedback.
All reactions