State Management in San: san-store Implementation and Time‑Travel Debugging

This article introduces the concept of front‑end state management, focusing on the San framework and its san-store implementation. It first explains why state management is needed, referencing Flux, Redux, and React's built‑in APIs, and discusses the benefits of unidirectional data flow.

It then describes the architecture of san-store , which follows the Flux pattern, and shows how actions, dispatcher, store, and view interact. Diagrams (omitted) illustrate data flow before and after using a store.

The article provides a concrete example of using san-store in a San application, including code for registering actions, connecting components, and updating state:

import {store, connect} from 'san-store';
import {builder} from 'san-update';

// register action
store.addAction('changeUserName', function (name) {
    return builder().set('user.name', name);
});

// component subscription
let UserNameEditor = connect.san({
    name: 'user.name'
})(san.defineComponent({
    template: '
{{name}}
',
    submit() {
        // trigger action
        store.dispatch('changeUserName', this.data.get('name'));
    }
}));

It explains the role of san-update for immutable updates and briefly compares it with immer .

The concept of “time travel” debugging is introduced, describing how developers can revert the application to a previous state by restoring a snapshot of the store. The implementation steps include logging state changes, retrieving a specific log by action ID, replacing the current state, computing a diff limited to subscribed fields, and firing view updates.

Key helper functions are shown, such as getStateFromStateLogs , decorateStore , replaceState , collectMapStatePath , getDiff , and travelTo . The diff algorithm only processes fields that components have subscribed to, achieving O(n) complexity instead of O(n³).

Finally, the article summarizes the benefits and limitations of the current time‑travel approach, noting challenges with non‑deterministic state (e.g., random data) and the overhead of storing visual snapshots.