so for whatever action that needs to change the redux store (not the
component state) and is asynchronous we better to use thunk or saga
but we do not have to and if not using it still it is valid. right?
First and foremost, redux-saga or redux-thunk are libraries built on top of Redux's middleware, which is used to handle concerns unrelated to the main data flow of redux, e.g. API calls, logging, routing. You can obviously write your own middlewares to handle async flow instead of using those libraries, which might lighten your app size a lot. However, redux-thunk and especially redux-saga have many syntax-sugar APIs to deal with complex usage of async flows, such as racing, sequencing API calls, cancelling API call based on condition and so on, which reduce a lot of working implementing equivalent logics by yourself.
Also when we say redux is syncronous flow by nature still we can swait
for the call and then proceed. So how is that different from saga or
thunk?
It's more personal opinion, but I think the main reason of using those libraries is separation of concerns. With middleware implementation to handle all async flows, we can have 3 logical parts in a react/redux app: redux part consisting of pure functions for synchrounous data flow, redux middleware part (can be redux-thunk or redux-saga) which deals with all API calls and side-effects from redux and react part to handle user interaction and communication with redux store. This way the code will be more manageable and easier for unit testing.
Am I right to say if I do not use saga then if I click 1000 times my
code will rin the asnc code and wait for result 1000 times but with
saga I have a way to control over it either run all in parallel(fork)
or just run the last one?
Again, a self-implemented redux middleware can be use to throttle all but the last call. However, redux-saga already has an API for this case, and many more for other common async problems.
