While building our app it became clear how useful this package has become for us. Almost all of our application logic is now handled by processes. Each is encapsulated and has a specific function or purpose. Things that used to be a mess have become clean and simple to compose.
That being said, the original version has a few major faults which were more just apart of the initial design and concept of the processes. So many things are all combined into one which makes it hard to abstract a lot of the concepts and adds more bulk than is needed.
As a result, we have completely re-written the package to be lean, mean, and much nicer to work with!
What's more is we have been able to reduce the overall source by a significant amount. Our parent class (Process) has been reduced to:
// process.js
import { IS_PROCESS } from './context'
export default class Process { static isProcess = IS_PROCESS }
As you can see, extending the process is really just about identification.
Building a process is also much cleaner in the next iteration. One of our main goals here was to make processes more encapsulated, more modular, and more reusable.
One major opportunity here is the ability to turn processes into npm packages. This way we can just add them in and (optionally) configure them -- resulting in a complete solution for reusing a processes logic.
Geolocation Process Example
See this Gist for a redux-saga process implementing the geolocation api!
Asynchronous Loading, Code-Splitting, Hot Reloading
In addition to that -- we wanted to make sure code-splitting with the redux-saga was not only possible, but absolutely simple! Sure enough, the process concept makes this simple to handle!
While building our app it became clear how useful this package has become for us. Almost all of our application logic is now handled by processes. Each is encapsulated and has a specific function or purpose. Things that used to be a mess have become clean and simple to compose.
That being said, the original version has a few major faults which were more just apart of the initial design and concept of the processes. So many things are all combined into one which makes it hard to abstract a lot of the concepts and adds more bulk than is needed.
As a result, we have completely re-written the package to be lean, mean, and much nicer to work with!
What's more is we have been able to reduce the overall source by a significant amount. Our parent class (Process) has been reduced to:
As you can see, extending the process is really just about identification.
Building a process is also much cleaner in the next iteration. One of our main goals here was to make processes more encapsulated, more modular, and more reusable.
One major opportunity here is the ability to turn processes into npm packages. This way we can just add them in and (optionally) configure them -- resulting in a complete solution for reusing a processes logic.
Geolocation Process Example
See this Gist for a redux-saga process implementing the geolocation api!
https://gist.github.com/bradennapier/57bdc528bdc8e53d709e6d2800c63ea2
Asynchronous Loading, Code-Splitting, Hot Reloading
In addition to that -- we wanted to make sure code-splitting with the redux-saga was not only possible, but absolutely simple! Sure enough, the process concept makes this simple to handle!
https://gist.github.com/bradennapier/4f8afd43215327304fddf27c819ad035
Reduced Library Size
The library itself reduces to just a few Kb vs almost 25 Kb compressed!