Learn Functional Programming Design from Redux
1–10 of 48 posts
Re: Learn Functional Programming Design from Redux
#2Side note: I just published a brand-new "Redux Essentials" core docs tutorial. It teaches beginners "how to use Redux, the right way", using our latest recommended tools and practices, including Redux Toolkit for writing your Redux code, the React-Redux hooks API for interacting with Redux in your components, and use of single-file "slices" for a given feature's Redux logic. I'd encourage folks to check it out:
https://redux.js.org/tutorials/essentials/part-1-overview-co...
My next step will be to rewrite the existing "bottom-up" tutorial sequence to simplify explanations, remove outdated references, improve the explanation flow, and add more running examples.
Re: Learn Functional Programming Design from Redux
#3In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g., Elm.
JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy.
There's a reason why someone had to write The Good Parts. I don't buy the idea either that modern JavaScript is somehow devoid of the kinds of problems that existed when Crockford wrote that book. I mean, how many people still think that `const` gives you an immutable value?
n.b. I'm not sure why the Haskell snippet was included. It's confusing, and doesn't even make sense given that `main` is defined twice.
Re: Learn Functional Programming Design from Redux
#4In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…
Thanks for your time reading my article!
> it's far easier to learn FP with a language which is actually designed for it, e.g., Elm.
I strongly agree with you on that. Pick up the right tool for the right task.
I understand that Javascript isn't designed for FP. But it doesn't block us from borrowing ideas from FP.
Re: Learn Functional Programming Design from Redux
#5In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…
I think it depends. It's hard to learn more than one thing at once; if you already know JS well, learning about functional programming using it makes sense to me. It's tricky to learn both a new language paradigm and a new syntax at the same time.
Of course there are limitations to how functional you can really be in JS; that said, I like the idea of introducing some basic concepts with JS. If people like the idea, they can pursue a "functional first" language.
Re: Learn Functional Programming Design from Redux
#6Side note: I just published a brand-new "Redux Essentials" core docs tutorial. It teaches beginners "how to use Redux, the right way", using our latest recommended tools and practices, including Redux Toolkit for writing your Redux code, the React-Redux hooks API for interacting with Redux in your components, and use of single-file "slices" for a given feature's Redux logic. I'd encourage folks to check it out: https…
I'd recommend caution when adopting redux-toolkit in large & rapidly-evolving projects.
I recently (2 months back) moved a medium sized project (~240 branch reducers, ~600 actions) away from redux-toolkit.
My primary complaint is that the recommended setup doesn't work well with changing requirements where we often have to move away from branch-local state handling to something that needs access to wider state.
We started out with a number of slices and our reducer logic was local to these slices and used only the state within that slice. However as our application evolved, for processing a number of these actions (which were previously slice-local) we needed access to state from other branches. So now we had a couple of options:
A. Dispatch thunks instead of actions: This gets ugly real fast because now your action handling logic is split across thunks & reducers, and is hard to follow. This also needs refactoring across every dispatch site.
B. Use something like redux sagas to intercept actions: We found this to be "too" flexible and felt that we were better-off without the entire machinery of spawning sagas on the fly. We wanted it to be easy to reason about what happens when an action is dispatched looking at the code without having to debug what all sagas could be running at that particular point of time.
C. Move the action handling higher up: requires extensively refactoring the reducers.
The solution we settled on was redux-loop [1]: A port of elm's effect system to redux. This was neat because we could easily convert the reducer to return loops instead of states, and thereby easily get access to full state and dispatch while retaining the ability to follow through the complete action handling flow from a single starting point that didn't change.
TypeScript support in redux-toolkit is also kind'a bolted on and users are recommended different approaches when they care about type-safety. It proved to be a pain to communicate junior devs multiple times that you should use leave the reducers as empty object and instead use "extraReducers" with builder API.
We found using immer[2] (for managing immutable state) and unionize[3] (for handling discriminated union of action types) directly to be a much better solution than redux-toolkit's abstractions.
[1]: https://github.com/redux-loop/redux-loop
Re: Learn Functional Programming Design from Redux
#7IMO Redux is a terrible way to start learning functional programming. There is too much boilerplate code and other code (ie. reducer, selectors, side effects, react components) that will confuse beginners and make the goal of learning functional programming harder.
It's like telling someone who wants to learn to drive, here's the road laws book, car manual, car service manual, offroad rally driving guide and engine tuning manual.
Re: Learn Functional Programming Design from Redux
#8In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…
I think it depends. It's hard to learn more than one thing at once; if you already know JS well, learning about functional programming using it makes sense to me. It's tricky to learn both a new language paradigm and a new syntax at the same time. Of course there are limitations to how functional you can really be in JS; that said, I like the idea of introducing some basic concepts with JS. If people like the idea, t…
Learning new syntax really isn't hard. Bear in mind that quite a lot of supposedly "modern" JavaScript is new syntax.
Re: Learn Functional Programming Design from Redux
#9In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g. , Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts . I don't buy the idea either that modern JavaScript is somehow devoid o…
Indeed. Programming with Functions != Functional Programming.
FP is predicated on referential transparency. FP decides the order of operations, not the programmer. If you don’t have that, you don’t have FP: you’ve got procedural programming with closures. Which is nice, but claiming you’re doing “Functional Programming” smells of this:
http://calteches.library.caltech.edu/51/2/CargoCult.htm
An effective tool is defined as much by what it cannot do as by what it can. In FP’s case, forbidding the unpredictability of mutable-state-over-time permits the automation of higher-level mathematical reasoning, enabling both compiler and runtime to make their own optimizations as they see fit: stronger guarantees of program correctness, deferring costly operations until/if they’re needed, caching the results for fast cheap reuse, parallelizing calculations without fear of races. Powerful stuff, as long as you’re willing to cede a bit of control.
If C and its procedural ilk are all a Swiss Army hammer, declarative programming systems (functional, logic, dataflow, etc) are these:
https://www.reddit.com/r/specializedtools/
A good craftsman should know when to use which; alas, we all too often end up seeing this instead:
Re: Learn Functional Programming Design from Redux
#10Earlier quoted context omitted.
I think it depends. It's hard to learn more than one thing at once; if you already know JS well, learning about functional programming using it makes sense to me. It's tricky to learn both a new language paradigm and a new syntax at the same time. Of course there are limitations to how functional you can really be in JS; that said, I like the idea of introducing some basic concepts with JS. If people like the idea, t…
Learning new syntax really isn't hard. Bear in mind that quite a lot of supposedly "modern" JavaScript is new syntax.
Learning new syntax really isn't hard.
When you make an absolute claim like "Learning new syntax really isn't hard." you're really saying "I find it easy therefore everyone else must too." That's poor quality thinking at best, and actively toxic to your peers at worst.
In my twenty+ years as a mentor to developers I've learned that objective statements about what is and isn't hard in programming are always going to fail when it comes to some set of devs. Some people find it trivial to move from one mental model to another. Other people find it really hard. This is true for every aspect of development - there is nothing that everyone finds easy or that everyone finds hard. If you don't take that in to consideration when you talk about programming you're always going to be failing at least one group.