State structure and organization when using signals

[rawrmonstar]

Has anyone come up with strategies / patterns to help manage your state when using signals? Libraries like Redux and Mobx-State-Tree offer strong recommendations about structure which IMO ultimately leads to less spaghetti state all over the place.

I still would use signals though, I just haven't seen any pattern that provides an organizational strategy when it comes to managing state.

Signals right now feel to me like alternatives to useState instead of a larger state management library.

[rschristian]

Signals right now feel to me like alternatives to useState instead of a larger state management library.

That's essentially the goal, yes. Signals are a new state primitive (well, new to preact/react) and as such are best compared to the existing state primitives like useState. Redux and MST are opinionated tools that build upon existing primitives, hence why they come with such strong suggestions around patterns. They work on a different layer to signals.

Classes (both for components or just data models) work really well with signals and quite a few of us use them very heavily throughout our apps. Can then stick the class instance into a context provider to access it from anywhere within your app.

class DataModel {
    foo = signal('foo');
    bar = signal('bar');
    baz = computed(foo.value + bar.value);
}

const Model = createContext();

function App() {
    return (
        <Model.Provider value={new DataModel()}>
            {...}
        </Model.Provider>
    );
}

[rawrmonstar]

Quick follow up, in your example, you wrote new DataModel() inside the App component. Do you actually inline it like that or was that just because it's a quick example?

Curious because with this pattern, I am worried about stable references. value would receive a different DataModel if App ever rerendered.

Do you normally wrap these class instantiations in a useRef or useMemo? I know in react at least you aren't supposed to assume useMemo is stable, so I guess that leaves useRef

class DataModel {
    foo = signal('foo');
    bar = signal('bar');
    baz = computed(foo.value + bar.value);
}

const Model = createContext();

function App() {
    return (
        <Model.Provider value={useRef(new DataModel()).current}>
            {...}
        </Model.Provider>
    );
}

[rschristian]

Quick follow up, in your example, you wrote new DataModel() inside the App component. Do you actually inline it like that or was that just because it's a quick example?

Wouldn't matter either way for the example I gave, App shouldn't rerender.

value would receive a different DataModel if App ever rerendered.

Do you normally wrap these class instantiations in a useRef or useMemo? I know in react at least you aren't supposed to assume useMemo is stable, so I guess that leaves useRef

Just hoist the object initialization if rerenders are a concern, there's no reason to start using useRef or useMemo (and you really shouldn't ever use them inline like that).

class DataModel {
    foo = signal('foo');
    bar = signal('bar');
    baz = computed(foo.value + bar.value);
}

const dataModel = new DataModel();

const Model = createContext();

function App() {
    return (
        <Model.Provider value={dataModel}>
            {...}
        </Model.Provider>
    );
}

[rawrmonstar]

I was thinking about in a deeper component (not the very top of the app) and in cases where you want the potential for multiple instances. I suppose using a class component would be pretty straight forward

class DataModel {
    foo = signal('foo');
    bar = signal('bar');
    baz = computed(foo.value + bar.value);
}

const Model = createContext();

class MyComponent extends Component {
  dataModel = new DataModel();
  
  render() {
    return (
        <Model.Provider value={this.dataModel}>
            {...}
        </Model.Provider>
    );
  }
}

[rschristian]

Sure, that's uncommon of a need (having multiple instances of a global store), but if you do need that then refs or class properties work great.