TIDEFI turns to Stately to build a resilient financial platform that prioritizes user-friendly transactions and investments.
The Stately team had the pleasure of sitting down with Parker McMullin, Senior Frontend Lead at TIDEFI, to discuss how our logic modeling and visualization tooling helped him manage app complexity and onboarding in TIDEFI’s financial services platform. Parker was so kind as to provide his experiences below, covering the very beginnings of his project from design to development as well as the challenges encountered and how other Stately users came to his aid. He shares his firsthand experiences applying modern software design patterns to his project, engaging with the technical community, and proving instrumental in shaping the direction of XState V5. We’re honored to have Parker in our community, and we hope his words can inspire teams to better navigate complexity in their own apps!
Customer spotlight: TIDEFI​
TIDEFI, an amalgamation of “Tide” and “Defi”, is a decentralized wallet for our custom blockchain. It facilitates deposits, withdraws, transfers, trading, staking, and more for users, and is especially known for making the user experience simple so that anyone can use it no matter their previous exposure to the world of cryptocurrency. To ensure correctness for this financial/investment product, we did extensive research to choose the right tools for the job. Below we will cover part of our story of how the XState library and Stately tools were crucial to managing the complexity of such an application.
From design to dev​
As with most projects, we started with the design. The user flows were outlined and after some iteration, we had a polished construct to work with!
Because of my previous experience using XState, I knew it could help manage certain aspects of complexity better than other state management tools. It provided visualization (helpful for thinking) and constraints (helpful for deciding), and is flexible enough to fit many challenges.
The first part we tackled was the multi-step Onboarding flow. I implemented the smaller parts of the design first, creating the form components, tiles, and imagery. Then as I worked on the state machine to control it, my hunch about managing complexity paid off. Thanks to clean state matching (like state.matches('chooseSecurityMethod.newAccount.choosePassword')) conditional logic and views were able to be flat and easy to reason with instead of being riddled with nesting and edge cases. Since this multi-step form had several directions the user could take, the final states were well-documented, and completely foolproof.
I was able to showcase the machine visualizer to the rest of the company, which was a delight. This helped convey the complexity of the UI pieces, and also helped to discuss how we should handle specific use cases in conjunction with the design mockups.
Challenges encountered and solutions provided​
Several months down the road, our team was running into some challenges of transmitting data between pages. Most pages had a machine that controlled the flow, and then there were other machines meant for data subscriptions, connection handling, etc. I decided to model a traditional hub-and-spoke actor system by:
- nesting actors underneath a root actor
- broadcasting an INIT event to register actors and facilitate storing references
- handle some communication via broadcasts, and others as direct events or data queries
In the XState Discord, this concept came up several times, and my implementation was tweaked until it was fairly easy to reason with, and performant. To my delight, the XState team created an RFC to introduce actor systems and the “receptionist” pattern! It was a joy to have real-world experience to contribute to the discussion and prove or challenge parts of the API. Now it is a built-in part of XState v5! I can remove dozens of lines of code and instead utilize my root actor as a system with individually named actors in a tree underneath.
Communicating the complex: moving forward with Stately​
As I brought more people on to the frontend team, they needed to understand the app architecture. We all know that components have their own props, events, and minor internal logic. We have a design system for styling, and the core app logic is written in state machines. Just as with any new technology, after learning the XState API each developer is given a smaller task to implement so they can make that paradigm shift. One of our teammates expressed how it was hard to go back to the “old way” of modeling things because this was so nice!
Overall, choosing XState was a tremendous boon to this app’s success, and I have loved working with such a great API. Version 5 builds upon the needs the community has expressed and I’m excited to see where the project goes!