We’ve all had that sinking feeling. There are multiple crash reports from production. We have the exact input parameters that caused the failures. We have the stack traces. Yet, when we run the code locally, it works perfectly.
We know where it broke, but we can’t see why. Was it a race condition? Did a database read return stale data that has since been overwritten? To find the cause, we have to mentally reconstruct the state of the world as it existed milliseconds before the crash. Welcome to debugging hell.
If we could simply rewind time and watch the code execute exactly as it did for those failed requests, life would be a lot easier.
In Testing Side Effects Without the Side Effects, we explored a JavaScript Effect System where business logic doesn’t execute actions directly. Instead, it returns a description of what it intends to do in the form of a simple Command object. For example:
const validatePromo = ( cartContents ) => { // Define the side effect, but don't run it yet const cmdValidatePromo = () => db . checkPromo ( cartContents ); // Define what happens with the result const next = ( promo ) => ( promo . isValid ? Success ({... cartContents , promo }) : Failure ( 'Invalid promo' )); return Command ( cmdValidatePromo , next ); };
outputs:
{ type : 'Command' , cmd : [Function : cmdValidatePromo ], // The command waiting to be executed next : [Function : next ] // What to do after the command finishes }
We often compose multiple commands in a pipeline to make the most of our Effect system:
const checkoutFlow = ( cartSummary ) => effectPipe ( fetchCart , validatePromo , ( cartContents ) => chargeCreditCard ( cartSummary , cartContents ) )( cartSummary );
Our effect pipeline handles the Success and Failure cases automatically. If a function returns Success , the subsequent function in line will be called. In the case of a Failure , the pipeline terminates.
... continue reading