Earlier quoted context omitted.
This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…
Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.
Learn Functional Programming Design from Redux
41–48 of 48 posts
Re: Learn Functional Programming Design from Redux
#42Earlier quoted context omitted.
> JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. Not only that. If you use types, and then an FP library, and then immutability, these three are at always at odds with each other.
Very correct. In addition, it becomes a real pain when using generics with constraints in TS. TS doesn't support either type classes or module/namespace level generics so you end up duplicating the same constraints applied to generic parameters across several functions. It is often easier to just use stateless classes instead and incur the runtime overhead of instantiation even if that object serves no purpose.
Can you not simply `export type T` and use `f`?
Re: Learn Functional Programming Design from Redux
#43Side 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 st…
RTK doesn't change anything about how you write reducers and actions that need to interact across slices. Our recommendations have always been the same: reorganize slice reducers so they handle more state, put more data in actions, or coordinate via side effects [0].
The only thing that changes with RTK is that we now recommend using the single-file "slice/ducks" pattern for a given feature's Redux logic, and RTK's `createSlice` API makes it easier to write code that's organized that way. If you do have cross-slice dependencies, where slice A and B both want to respond to each other's actions, that _could_ potentially lead to cyclic dependency issues. Our RTK Usage Guide page specifically addresses that question [1], and resolving it is generally a matter of defining the relevant actions in a separate file again. But, having logic in a single file by default drastically simplifies things in most cases. This issue isn't unique to RTK - it exists any time you're trying to have different slices depend on each other, regardless of how the logic in those files are implemented.
Also strongly disagree that RTK's TS support is "bolted on". RTK is written in TS, and we've spent hundreds of hours trying to ensure our APIs work well with TS [2]. We test against multiple TS versions, design our APIs to minimize the amount of types you have to declare, and try to offer the best type safety possible with our preferred API structure.
The only time you would ever define `createSlice.extraReducers` as an empty object is if you are _only_ using that slice as a data cache and not adding any additional client-side logic that would manipulate that cached data. In that case, you'd probably be better suited to use `createReducer` directly.
Having said that, we are currently working on a PR to add the ability to declare async thunks directly inside of `createSlice` [3], leveraging our new `createAsyncThunk` API [4] so that their action types are automatically generated to match the slice name and the action creator name you specify. That will eliminate the need to call `createAsyncThunk` separately and pass its actions to `createSlice.extraReducers`.
Finally, RTK has been built around Immer since day 1, and it's used in `createReducer` and `createSlice` to allow you to write simpler "mutating" immutable update logic.
If you have any additional specific concerns, please ping me on Twitter or in the Reactiflux Discord. I'm always happy to answer questions and offer suggestions, and I would really be interested in seeing some details on the app you're working on to see if there's any ideas for improving RTK's APIs for your kind of use case.
[0] https://redux.js.org/faq/reducers#how-do-i-share-state-betwe...
[1] https://redux-toolkit.js.org/usage/usage-guide#exporting-and...
[2] https://github.com/reduxjs/redux-toolkit/pull/393
Re: Learn Functional Programming Design from Redux
#44Earlier quoted context omitted.
I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to. Point the OP was getting at: 'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value. Yes, the article you linked was u…
Yes precisely this. The person above you might be unaware of the fact but JavaScript (and all other languages that I’m aware of) does indeed make use of pointers albeit indirectly. When you use const and initialize it as a JS object the value in the variable is a “pointer” (call it what you will, it points to or references a memory location) and is indeed immutable. You cannot change the value of the variable. You ca…
You're missing the forest for the trees.
Do you think your 200-word explanation is easier for a beginner to understand than "this value is immutable — it will never change"?
My initial argument was that JavaScript is a terrible choice for learning FP, precisely because it has so many caveats and is notoriously poorly understood, even by people who use it every day. Your lengthy explanation proves my point.
Re: Learn Functional Programming Design from Redux
#45In 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…
even with es6 ?
Yes.
Re: Learn Functional Programming Design from Redux
#46Earlier quoted context omitted.
Yes precisely this. The person above you might be unaware of the fact but JavaScript (and all other languages that I’m aware of) does indeed make use of pointers albeit indirectly. When you use const and initialize it as a JS object the value in the variable is a “pointer” (call it what you will, it points to or references a memory location) and is indeed immutable. You cannot change the value of the variable. You ca…
You're missing the forest for the trees. Do you think your 200-word explanation is easier for a beginner to understand than "this value is immutable — it will never change"? My initial argument was that JavaScript is a terrible choice for learning FP, precisely because it has so many caveats and is notoriously poorly understood, even by people who use it every day. Your lengthy explanation proves my point.
I find this argument a bit disingenuous to be honest, I took the liberty of spelling things out in my reply because I assumed you wouldn’t otherwise be able to see the point. An explanation to a beginner, which doesn’t require memorizing any additional gotchas, would be something like “variables hold values. Strings, numbers, booleans, and references are values. Variables declared with const contain values that are immutable. An object is not a value.”
Re: Learn Functional Programming Design from Redux
#47Earlier quoted context omitted.
You're missing the forest for the trees. Do you think your 200-word explanation is easier for a beginner to understand than "this value is immutable — it will never change"? My initial argument was that JavaScript is a terrible choice for learning FP, precisely because it has so many caveats and is notoriously poorly understood, even by people who use it every day. Your lengthy explanation proves my point.
I find this argument a bit disingenuous to be honest, I took the liberty of spelling things out in my reply because I assumed you wouldn’t otherwise be able to see the point. An explanation to a beginner, which doesn’t require memorizing any additional gotchas, would be something like “variables hold values. Strings, numbers, booleans, and references are values. Variables declared with const contain values that are i…
Likewise, I think it's disingenuous to suggest that "an object is not a value" is not an "additional gotcha".
Differences in evaluation strategies is not really beginner material.
Re: Learn Functional Programming Design from Redux
#48In 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…
This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax…
I have written non trivial projects with ramda and I like it a lot. You have to use your judgement with readability. Some of the advanced functions are a little hard to grok at first, but most of the library is pretty straight forward.