Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
IMO another thing that's easy to do "wrong" is to abandon a core idea of Redux / Elm -- that your app has a single set of named behaviors drawn from a "menu" of action constants. In Elm, you're basically forced to stick to that architecture, but in Redux, the side effect libraries offer various escape hatches.
Once you drop in redux-thunk, you get another place to stick app logic. That logic can be composed of multiple actions firing, with time-dependent (can't think of a better way to say it) data being passed between them.
With redux-saga, since the sagas are long-running, values living in the generators can act as implicit app state.
The closest thing to Elm's ideal that enables side effects is redux-loop. While it may not be the best choice for every app, IMO it's generally good to be cautious around things like: logic moving out of named actions, unnamed "meta-actions," and app state that lives outside of the store.
I'd argue that things like which files code lives in, or what variables get named, while good to get right, are less costly to fix than runtime behavior that works but is hard to reason about. Which is something that the combo of discrete, named actions & immutable state is meant to avoid.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
IMO another thing that's easy to do "wrong" is to abandon a core idea of Redux / Elm -- that your app has a single set of named behaviors drawn from a "menu" of action constants. In Elm, you're basically forced to stick to that architecture, but in Redux, the side effect libraries offer various escape hatches.
Once you drop in
redux-thunk, you get another place to stick app logic. That logic can be composed of multiple actions firing, with time-dependent (can't think of a better way to say it) data being passed between them.With
redux-saga, since the sagas are long-running, values living in the generators can act as implicit app state.The closest thing to Elm's ideal that enables side effects is
redux-loop. While it may not be the best choice for every app, IMO it's generally good to be cautious around things like: logic moving out of named actions, unnamed "meta-actions," and app state that lives outside of the store.I'd argue that things like which files code lives in, or what variables get named, while good to get right, are less costly to fix than runtime behavior that works but is hard to reason about. Which is something that the combo of discrete, named actions & immutable state is meant to avoid.