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
-
Reducer
convenience methodsI was experimenting with
BindingAction
on some screens that only useBindingAction
s. 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 soReducer
call siteAt the call site, I no longer needed to create named reducers. This flow works well when my reducers aren't particularly complicated:
A
CasePath
alternativeOne 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.Beta Was this translation helpful? Give feedback.
All reactions