When we built Auxo, we wanted to integrate a number of the lessons learned from building previous DApps and products in PieDAO. In any frontend web app, how you manage the data (the state) is critical to keeping your app maintainable and performant.
Recently, the tendency has been to move more and more of the application code into the front end application, as operations on the blockchain are 💰 (expensive) and 🐢 (slow), compared to what we can do in the user’s browser with a framework like React, Vue, Svelte or Angular.
At some point though, you have to interact with the network. So, in order to create a great user-experience for a DApp, we as developers need to have a very clear conceptual framework for managing the kind of long-running transactions that are typical in Web3. We also need to ensure we are giving plenty of user feedback and are able to accurately reflect the state of the app, in relation to the network, at a given time.
This post explains our approach in Auxo, in particular some of our early discussions on what doesn’t scale as an approach to managing transactions, and how we can use the tools in the popular state management library Redux to create a clear separation between our components, blockchain transactions, and user journeys.
A core feature of any DApp is the ability to submit transactions through the UI and have them be resolved on chain.
The basic workflow of a transaction, using ethers JS and react:
Part 1 is a simple UI interaction. Part 2 puts the application in an extended, pending state, but importantly here, the user is engaged elsewhere (they are signing the transaction).