Posts Tagged ‘StateManagement’
[DotJs2024] Adding Undo/Redo to Complex Web Apps
Enhancing user agency in labyrinthine applications hinges on forgiving interactions, where missteps dissolve with a keystroke. Bassel Ghandour, a senior software engineer at Contentsquare, distilled this essence into a brisk yet profound primer at dotJS 2024. From Paris’s vibrant tech scene—now his U.S. outpost—Ghandour lamented a botched virtual Tokyo greeting, swiftly invoking undo’s allure. His focus: retrofitting undo/redo into state-heavy web apps, sidestepping snapshot pitfalls for action-centric resilience.
Ghandour commenced with state management basics in a todo app: frontend mirrors app state, enter-press morphs it—additions, UI ripples. Naive undo? Timestamped snapshots, hopping between epochs. Reality intrudes: actions cascade side effects, backend ops interweave, concurrency clashes. Rapid todo barrages spawn interleaved sequences; snapshot reversion mid-thread invites chaos. Solution: encapsulate sequences under UUIDs, treating batches as atomic units. Parallel: forge inverses—add’s delete, toggle’s revert—mapping each to its antithesis.
This duality—do and undo in tandem—preserves fidelity. User crafts todo: UUID wraps creation, displays; inverse queues deletion. Subsequent show-toggle: nested UUID, inverse queued. Undo invokes the stack’s apex inverse, state reverts cleanly; redo replays forwards. Ghandour’s flow: capture actions, inverse-map, sequence-bundle, command-apply. Backend sync? Optimistic updates, rollbacks on failure. Contentsquare’s engineering blog details implementations, from Redux sagas to custom dispatchers.
Ghandour’s brevity belied depth: this pattern scales to e-commerce carts, design canvases, empowering serene navigation amid complexity. By prioritizing actions over states, developers liberate users, fostering trust in intricate digital environs.
Encapsulating Actions for Resilience
Ghandour advocated UUID-wrapped sequences, neutralizing concurrency: todo volleys become discrete do/undo pairs, applied reversibly. Inverse mapping—add-to-delete—ensures symmetry, backend integrations via optimistic commits. This sidesteps snapshot bloat, embracing flux with grace.
Implementing Undo/Redo Commands
Stacks manage history: push do with inverse, pop applies antithesis. Redo mirrors. Ghandour teased Contentsquare’s saga: Redux orchestration, UI hooks triggering cascades—scalable, testable, user-delighting.
Links:
[KotlinConf2018] Taming State with Sealed Classes: Patrick Cousins’ Approach at Etsy
Lecturer
Patrick Cousins is a software engineer at Etsy with nearly 20 years of programming experience, passionate about new patterns and languages. He is known for his work on state management and seal-related puns. Relevant links: Etsy Code as Craft Blog (publications); LinkedIn Profile (professional page).
Abstract
This article examines Patrick Cousins’ use of Kotlin sealed classes to manage complex state in Etsy’s mobile apps. Contextualized in event-driven architectures, it explores methodologies for event streams with RxJava and when expressions. The analysis highlights innovations in exhaustiveness and type safety, contrasting Java’s limitations, with implications for robust state handling.
Introduction and Context
Patrick Cousins spoke at KotlinConf 2018 about sealed classes, inspired by his blog post on Etsy’s engineering site. Etsy’s mobile apps juggle complex state—listings, tags, shipping profiles—forming a “matrix of possibilities.” Sealed classes offer a type-safe way to model these, replacing Java’s error-prone instanceof checks and visitor patterns. This narrative unfolds where mobile apps demand reliable state management to avoid costly errors.
Methodological Approaches to State Management
Cousins modeled state as sealed class hierarchies, emitting events via RxJava streams. Using filterIsInstance and when, he ensured exhaustive handling of state types like Loading, Success, or Error. This avoided Java’s polymorphic indirection, where unrelated types forced artificial interfaces. Sealed classes, confined to one file, prevented unintended extensions, ensuring safety.
Analysis of Innovations and Features
Sealed classes innovate by guaranteeing exhaustiveness in when, unlike Java’s instanceof, which risks missing branches. Kotlin’s final-by-default classes eliminate Liskov substitution issues, avoiding polymorphic pitfalls. RxJava integration enables reactive updates, though requires careful ordering. Compared to Java, sealed classes simplify state logic without forced commonality, though complex hierarchies demand discipline.
Implications and Consequences
Cousins’ approach implies safer, more maintainable state management, critical for e-commerce apps. It reduces bugs from unhandled states, enhancing user experience. Consequences include a shift from polymorphic designs, though developers must adapt to sealed class constraints. The pattern encourages adoption in reactive systems.
Conclusion
Cousins’ use of sealed classes redefines state handling at Etsy, leveraging Kotlin’s type safety to create robust, readable mobile architectures.
Links
- Lecture video: https://www.youtube.com/watch?v=uGMm3StjqLI
- Lecturer’s X/Twitter: @patrickcousins
- Lecturer’s LinkedIn: Patrick Cousins
- Organization’s X/Twitter: @EtsyEng
- Organization’s LinkedIn: Etsy