SolidJS•3w ago

can't setup a basic state machine interactive quiz type of game

I am trying to make a quiz application. It has several states, like first it has to load the list of questions, then it has to load data for a specific question at play, it has to select the next question to play at random. It also displays previous solved attempts, when they are clicked, it has to display that specific question, and when the question list is empty display an empty message. This kind of app. I quickly learned createEffect is evil. But also I am trying to juggle how the state effects are called in order in this reactive system. Obviously I am creating this support ticket to get some tips and tricks on how to make this manageable in comprehension, because I am in the process of trying to tweak the order of calls or the batches, which I will quickly forget what is supposed to be calling who next time I open the code in a month or so. Currently the app doesn't work and I don't know how to fix it. The main problem is it's not just straightforward imperative state management and control flow. It's a big pile of SpaghettiOs. Ps. Oh I didn't mention the list of questions is reactive async state because it changes over time as well.

9 Replies

gsoutzOP•3w ago

I managed to track down a couple of re calculations happening , but one change leads to another and I end up in unstable state again.

peerreynders•3w ago

There is solid primitives State Machine but it's possible to integrate with libraries like XState. Planning with a State Chart might be helpful.

Solid Primitives

A library of high-quality primitives that extend SolidJS reactivity

Statecharts in User Interfaces

gsoutzOP•3w ago

Here's an example code showcasing how I achieved my success with this feature: So this kind of system basically works with no bugs at least visually as far as I could test it under 1 hour.

    type StateBoot = { state: 'boot', next: undefined }
    type StateLoadList = { state: 'load-list', next: undefined }
    type StateListNoItem = { state: 'list-no-item' }
    type StateSelectNext = { state: 'select-next', next?: ModelRepeatDueMove }
    type StateLoadNext = { state: 'load-next', next: ModelRepeatDueMove, is_previous_attempt: boolean }
    type StateLoadedPreview = { state: 'loaded-preview', next: ModelRepeatDueMove, is_previous_attempt: boolean }
    type StateLoadedIdle = { state: 'loaded-idle', next: ModelRepeatDueMove, show_previous_moves: boolean, is_previous_attempt: boolean }
    type StateAttemptResult = { state: 'attempt-result', next: ModelRepeatDueMove, attempt_result: RepeatAttemptResult, is_previous_attempt: boolean }
    type StateAutoGoNext = { state: 'auto-go-next', next: ModelRepeatDueMove, is_previous_attempt: boolean }

    const is_boot = (state: SomeState): state is StateBoot => state.state === 'boot'
    const is_load_list = (state: SomeState): state is StateLoadList => state.state === 'load-list'
    const is_list_no_item = (state: SomeState): state is StateListNoItem => state.state === 'list-no-item'



    type SomeState = StateBoot | StateLoadList | StateListNoItem

    const [state, set_state] = createStore<StoreState>({
        current_state: { state: 'boot', next: undefined }
    })

    createEffect(() => {
        if (is_boot(state.current_state)) {
            set_current_state({
                state: 'load-list',
                next: undefined
            })
        }
    })

    type StateBoot = { state: 'boot', next: undefined }
    type StateLoadList = { state: 'load-list', next: undefined }
    type StateListNoItem = { state: 'list-no-item' }
    type StateSelectNext = { state: 'select-next', next?: ModelRepeatDueMove }
    type StateLoadNext = { state: 'load-next', next: ModelRepeatDueMove, is_previous_attempt: boolean }
    type StateLoadedPreview = { state: 'loaded-preview', next: ModelRepeatDueMove, is_previous_attempt: boolean }
    type StateLoadedIdle = { state: 'loaded-idle', next: ModelRepeatDueMove, show_previous_moves: boolean, is_previous_attempt: boolean }
    type StateAttemptResult = { state: 'attempt-result', next: ModelRepeatDueMove, attempt_result: RepeatAttemptResult, is_previous_attempt: boolean }
    type StateAutoGoNext = { state: 'auto-go-next', next: ModelRepeatDueMove, is_previous_attempt: boolean }

    const is_boot = (state: SomeState): state is StateBoot => state.state === 'boot'
    const is_load_list = (state: SomeState): state is StateLoadList => state.state === 'load-list'
    const is_list_no_item = (state: SomeState): state is StateListNoItem => state.state === 'list-no-item'



    type SomeState = StateBoot | StateLoadList | StateListNoItem

    const [state, set_state] = createStore<StoreState>({
        current_state: { state: 'boot', next: undefined }
    })

    createEffect(() => {
        if (is_boot(state.current_state)) {
            set_current_state({
                state: 'load-list',
                next: undefined
            })
        }
    })

gsoutzOP•3w ago

full code is here https://github.com/eguneys/aidchess24/blob/rework/src/views/repetition/Show.tsx

GitHub

aidchess24/src/views/repetition/Show.tsx at rework · eguneys/aidche...

Contribute to eguneys/aidchess24 development by creating an account on GitHub.

peerreynders•3w ago

The main problem is it's not just straightforward imperative state management and control flow.

I think you need to maintain the transition function outside of the reactive graph. By all means store the finite (and perhaps extended) state inside of a store so that the UI can react to state changes but it's going to be easier if you manage state transitions with explicit , discrete events.

I quickly learned createEffect is evil.

The intent of createEffect is for effects that leave the reactive graph. That is not how you are using them:

 createEffect(() => {
  if (is_list_no_item(state.current_state)) {
    if (due_list_by_type().length > 0) {
      set_current_state({
        state: 'select-next',
        next: undefined,
      });
    }
  }
});

 createEffect(() => {
  if (is_list_no_item(state.current_state)) {
    if (due_list_by_type().length > 0) {
      set_current_state({
        state: 'select-next',
        next: undefined,
      });
    }
  }
});

Within the effect reactive state is directly changed. In this particular case it's probably not a problem but as the code gets larger and involves more complex conditions it gets difficult to understand what the effect really depends on at any point in time.

DEV Community

You don't need a library for state machines

State machines are an awesome way of modeling app logic. But do you need a library for state machines? Not necessarily, but there are more things to consider for more complex use-cases.

peerreynders•3w ago

Compare it to this:

// `on` explicitly lists reactive values being watched
// while anything in the function is untracked.
createEffect(
  on(dueList, (list, _lastList, lastEmpty) => {
    const empty = (list?.length ?? 0) < 1;

    // Was empty but isn't anymore
    // a state may be waiting for this
    if (lastEmpty && !empty)
      transition(state.current, { kind: 'due-list-available' }, setCurrent);

    return empty;
  }),
  true
);

// `on` explicitly lists reactive values being watched
// while anything in the function is untracked.
createEffect(
  on(dueList, (list, _lastList, lastEmpty) => {
    const empty = (list?.length ?? 0) < 1;

    // Was empty but isn't anymore
    // a state may be waiting for this
    if (lastEmpty && !empty)
      transition(state.current, { kind: 'due-list-available' }, setCurrent);

    return empty;
  }),
  true
);

This effect is watching dueList explicitly (and nothing else) and dispatches the due-list-available event only when it goes from nothing to something. We don't need to know whether the current state is actually waiting for this, that is for transition to sort out. Now transition can still mutate reactive state inside the effect but formulation of the event and having transition act on that can be considered “leaving the reactive graph”. So each createEffect watching very specific reactive dependencies to detect explicit events (independent of the current state) will make them much less evil.
https://playground.solidjs.com/anonymous/dad39a0e-2a3c-4f52-b21e-8ca5259b7da3 Now this is an extremely bare bones way of managing state but that is why libraries like XState exist, as they offer features (e.g. automatic transitions) to make the machine representation a lot more compact.

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template

XState Docs

Documentation for XState: State Machines and Statecharts for the Modern Web

Introduction to state machines and statecharts | Stately

Introduction to state machines and statecharts

dabac_•2w ago

Noobie here. I noticed your statement "I quickly learned createEffect is evil." Can you elaborate on this one please?

peerreynders•2w ago

createEffect() exists for one specific purpose: to "effect"/change something outside of the reactive graph in response to the change from within the reactive graph. When used strictly in that capacity createEffect isn't evil. When it is habitually used to change something inside the reactive graph, in response to change within the reactive graph, like setting one signal setter in response to a change in another's accessor things can derail pretty quickly—like where effects are responsible for an infinite reactive loop; effects feeding back change from within the reactive graph back into the reactive graph, triggering those effects all over again. Solid's core philosophy is unidirectional flow: - change enters the reactive graph via signals/stores and (async) resources - change propagates through derivations like memos - change propagation terminates in effects. In Solid's case the terminating effects are predominantly updating UI that was created via JSX. So in most cases createEffect() is simply not necessary. createEffect(() => console.log('my signal', accessor())) is perfectly benign because the accessor's value leaves the reactive graph (and the originating graph isn't changed as a result of the effect).

Meta Developers

YouTube

Hacker Way: Rethinking Web App Development at Facebook

Delivering reliable, high-performance web experiences at Facebook's scale has required us to challenge some long-held assumptions about software development. Join us to learn how we abandoned the traditional MVC paradigm in favor of a more functional application architecture.

createMemo - SolidDocs

Documentation for SolidJS, the signals-powered UI framework

peerreynders•2w ago

createEffect() is intended to be used to effect change outside of Solid and outside of its JSX. There are some edge cases where createEffect() is used to trigger change in a reactive graph but those cases have to be extremely carefully considered (and will be even less necessary with Solid 2.x). It's not unusual for people new to Solid to reach for createEffect() far too quickly because as they see it, they just want to “effect change” and they haven't as of yet fully explored the range of capabilities of all of the reactive primitives (or perhaps the community primitives for more narrow use cases) and the ways they can be composed to craft an effective reactive graph.

Solid Primitives

A library of high-quality primitives that extend SolidJS reactivity

GitHub

strello/src/components/Board.tsx at 9c9ae973d96cc045914e696757a1b5f...

Contribute to solidjs-community/strello development by creating an account on GitHub.

Gaming

Programming

can't setup a basic state machine interactive quiz type of game

Did you find this page helpful?