This week concludes the first month of my internship at 9cv9 as part of the NUS Overseas College (NOC) Southeast Asia programme. One of the key libraries that both projects share and that I had to learn to use is Redux-Saga, which forms the backbone of the project as it handles most things related to data, from getting data from APIs to providing a central storage for all data to reside. Redux-Saga is actually composed of two parts, Redux, the state management library and Saga, the middleware. For this reflection, I will be going over a high level overview on Redux-Saga.
Redux follows 2 crucial patterns. “Single source of truth”, where there is only one place, known as the store, where the application’s state is stored and “Immutability”, where the state object is never changed directly and instead a new object is created and the application’s state is updated with it. Below is a diagram of the data flow in the Redux cycle as well as a brief explanation of the important terminologies involved in the Redux cycle.
1) Action Creator
- A function that is going to create or return a plain javascript object (the action)
2) Action
- The plain javascript object returned. An action typically has a type property (mandatory) and a payload property (optional). The Type property in the action describes some change that we want to make inside of our data. Payload property describes some contexts around the change that we want to make.
3) Dispatch
- Take in an action, make copies of that object and then pass it off to a bunch of different places inside of our application.
4) Reducers
- A pure function that is responsible for taking an action, looking at the action and its type and then based on that type, decides how to update its data and return it so that it can then be centralized in some other location (the store).
5) Store
- A central repository of all information that has been created by our reducers. Makes it easy for react app to reach into the Redux side of the app and get access to all of the data of our application.
Redux’s capability can be further improved with Middleware, which adds extra functionality to the Redux dispatch function and is executed before each dispatched action reaches a reducer. This is where Redux-Saga comes into play. Redux-Saga is 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, more efficient to execute, easy to test, and better at handling failure. It can be thought of as a separate thread in your application that is responsible for side effects.
Redux-Saga uses an ES6 feature called Generators to make those asynchronous flows easy to read, write and test. Sagas are implemented as Generator functions that yield objects to the Redux-Saga middleware. The yielded objects are a kind of instruction to be interpreted by the middleware. The sagas are usually divided into two categories, worker sagas and watcher sagas. An simple example of such sagas are provided below:
// Our worker Saga: will perform the async increment task
export function* incrementAsync() {
yield delay(1000)
yield put({ type: ‘INCREMENT’ })
}
// Our watcher Saga: spawn a new incrementAsync task on each INCREMENT_ASYNC
export function* watchIncrementAsync() {
yield takeEvery(‘INCREMENT_ASYNC’, incrementAsync)
}
The watchIncrementAsync Saga listens for dispatched INCREMENT_ASYNC actions and runs incrementAsync each time. If a promise is yielded to the middleware Redux-Saga, it will suspend the Saga until the Promise is completed (after a delay of 1000ms in the example above). Once it resumes, it will execute the code until the next yield, where in the example above, put({type: ‘INCREMENT’}), which instructs the middleware to dispatch an INCREMENT action.
Credits:Both images sourced from: https://javascript.plainenglish.io/the-only-introduction-to-redux-and-react-redux-youll-ever-need-8ce5da9e53c6
