I am fairly new to redux-toolkit but I am quite partial to using their slices. They seem like an easy enough way to create reducers.
I do not know, however, how to execute async operations after an action has been dispatched. My use-case is, that I need to update the state and then execute an async operation (or more generally an operation with side-effects).
How would one do this?
Use redux saga for that. It will basically be listening to your action and call the async function whenever action is dispatched
Related
As redux-saga describes itself as
a library that aims to make application side effects (i.e.
asynchronous things like data fetching and impure things like
accessing the browser cache) easier to manage.
The select effect is just used to get a slice of the current Store's state. It doesn't produce any side effect at all (no I/O operation, no mutation,etc). It's just a purely functional operation. Why a purely functional operation was designed to be an effect ?
Because none of your saga code is supposed to be interacting with the store directly overall. Whatever your saga needs to do, whether it be making an AJAX call, dispatching an action, or anything else, gets done by yielding an effect description and asking the middleware to do that work for you. Your saga doesn't have access to the store directly to call dispatch(), so there's no reason for it to have access to getState() directly either.
Without redux-thunk, your action creators can still take dispatch as an argument and seemingly do whatever a thunk would:
https://stackoverflow.com/a/33892505/378622
So what's the motivation for redux-thunk, exactly?
Dan Abramov's answer here How to dispatch a Redux action with a timeout? explains it in detail.
This summary is probably not complete, but my take from it is:
No need to have dispatch as a prop in components and passing it around
Async control flow is more convenient, you can treat other actions like promises without having to wrap them in new Promise() yourself
Additional argument getState in actions to read from state
I use react + redux with multiple reducers.
I figured out that every dispatched action goes through every reducer, although there's only one relevant reducer for this action.
Is there an option to force every dispatched action to go only to its reducer?
If not - why? Surely I misunderstand something.
I do not have enough points to mark it as such, but this looks like a duplicate, please see:
Why a dispatch to a reducer causes all reducers get called?
All reducers will be invoked when an action is dispatched?
Short answer: it is normal and intended, there is no such option to prevent it because when you have a complex state tree, you should not have to care to compute and check what needs to be changed manually, this is the role of redux and unless you have a huge application, performance will not be an issue (reducers are often just simple multiple lines pure function).
If you are worried about performance, check out https://github.com/reactjs/reselect mentionned in one of the other question.
Per the Redux FAQ entry on "calling all reducers", you really only have one root reducer function. If you generated that root reducer using the built-in combineReducers function, then yes, it will always run all of the slice reducers you've provided for every dispatched action, because that's how combineReducers works.
If you want other behavior, you can write your own reducer logic for your specific use case. See the Redux docs section on "Structuring Reducers" for more information on various ways to organize reducer logic.
I'm learning redux and am struggling to understand why state has to be immutable. Could you provide me with an example, in code preferably, where breaking the immutable contract results in an not so obvious side effect.
Redux was originally invented to demonstrate the idea of "time-travel debugging" - being able to step back and forth through the history of dispatched actions, and see what the UI looks like at each step. Another aspect is being able to live-edit the code, reload it, and see what the output looks like given the new reducer logic.
In order to be able to properly step back and forth between states, we need to make sure that reducer functions have no side effects. That means data updates need to be applied immutably. If a reducer function actually directly modifies its data, then stepping back and forth between states will cause the application to behave in an unexpected fashion, and the debugging effort will be wasted.
Also, the React-Redux library relies on shallow equality checks to see if the incoming data for a component has changed. If the data references are the same, then the wrapper components generated by connect assume that the data has not changed, and that the component does not need to re-render. Immutable data updates means that new object references are created, and thus connect will see that the data has changed and the UI needs to update.
Two Ideas
There are two ideas about immutability that you need to understand:
Mutate the state only in the reducers
Using an immutable data structure
Mutate the state only in the reducers
Redux tries to ensure that you only mutate the state in the Reducers. This is important because it makes easier to think about your application data flow.
Let's say that a value is not displayed in the UI as you expected or that a value that should have changed still showing its original value.
In that case, you could just think about which reducer is causing the mutation and see what went wrong.
This makes thinking about Redux issues very simple and makes developers highly productive.
Sometimes you can mutate the state in a view or in an action by mistake. If you think about the life-cycle:
Action -> Reducer -> Views-> Action
If the state changes in a view and then an action is triggered the state change could be override. This would make very hard to find out what is going on for developers. We solve this by mutating state only in the reducers.
Note: another nice thing is that reducers are pure functions and all the async stuff takes places in the actions/middleware. So all side effects take place in the actions/middleware layer. Actions are our connection with the external world (HTTP, Local Storage, etc.).
Using an immutable data structure
As I have already mentioned, sometimes you can mutate the state in a view or in an action by mistake. To reduce chances of this happening we can make state mutations explicit by using and immutable data structure.
Using immutable data structures also has performance benefits because we don't need to perform deep equality checks to check for mutations.
The most commonly used provider of immutable data structures is immutable.js.
I think the key ideas would be
Easy to replay any given situation/test flow - you can replay with the same actions starting from the same initial state
Fast component re-rendering - because the reference is changed and not its values, it is much much faster to test the change
Of course, there are other aspects and I suggest this nice article which explains in more details.
As this question is huge, I will give my view on this question so that you can simply tell me whether I am right or not. If not, where to correct. If my view is superficial, please present an overview of F# async usage. In mu understanding, to write async program, you need to put async code into "async" block like async{expression}, and use "let!" or "use!" to bind names to primitives, then you need to use method to run this async expression like "Async.Run". In addition, you can use exception handling to deal with exception, and cancellation to cancel when necessary. I also know there are several primitives that defined in F# core libraries, and F# extension of I/O operation. I just need to make sure the relation between these things. If you think my view on async workflows is superficial, please give an overview usage like what I have mentioned above. Thank you very much!
This question is huge, so at best, I can highlight some ideas and point you to learning resources and examples.
The description in the question isn't wrong (though there is no Async.Run function). But the main point about Asyncs is how they execute and why the way they execute is useful.
An async block defines a piece of code that becomes an Async<'T> object, which can be seen as a computation that can be executed at a later time. The Async returns an object of type 'T when its execution has completed -- if it has neither failed nor been cancelled.
let!, do! and use! are used inside of an async block to run another Async and, in the cases of let! and use!, bind its result to a name inside the current async. Unlike for example normal let, which simply binds any value to a name, the versions with an exclamation mark explicitly "import" the result of another async.
When an Async depends on another and waits for its result, such as with a let! binding, it normally does not block a thread. Asyncs utilize the .NET thread pool for easy parallel execution, and after an Async completes that another Async depends on, a continuation runs the remainder of the dependent Async.
The Async functions offer many ready-made ways to run Asyncs, such as Async.Start, which is a simple dispatch of an Async with no result, Async.RunSynchronously, which runs the Async and returns its result as if it were a normal function, Async.Parallel, which combines a sequence of Asyncs into one that executes them in parallel, or Async.StartAsTask, which runs an Async as an independent task. Further methods allow composition of Asyncs in terms of cancellation, or explicit control over continuation after an exception or cancellation.
Asyncs are very useful where waiting times are included: otherwise blocking calls can use Asyncs to not block execution, for example in I/O bound functions.
The best introductions to F# Asyncs I know are written, or co-written, by Don Syme, the lead designer of F#:
The chapter Reactive, Asynchronous, and Parallel Programming in the book Expert F#
A blog post with examples for asyncronous agents
The blog post introducing Asyncs in late 2007