Signal Store — Series 2

Preview — 3 of 10 questions

What do these four blocks contribute?

javascript

export const HeroStore = signalStore(
  withState({ heroes: [] as Hero[], query: '', loading: false }),
  withComputed(({ heroes, query }) => ({
    visible: computed(() => heroes().filter((h) => h.name.includes(query()))),
  })),
  withMethods((store, api = inject(HeroApi)) => ({
    setQuery: (q: string) => patchState(store, { query: q }),
  })),
  withHooks({ onInit: (store) => store.load() }),
);

AThey are alternative syntaxes for the same thing

BOnly withState is required; the rest are for devtools

CwithComputed replaces withState

DState, derived state, behaviour and lifecycle — composed left to right, with each block seeing everything declared before it, and the result being an injectable class

Why is direct assignment impossible?

javascript

patchState(store, { loading: true });
patchState(store, (state) => ({ heroes: [...state.heroes, hero] }));

ABecause the state signals are exposed read-only: patchState is the single writer, which keeps every mutation traceable and lets features hook into updates

BBecause signals cannot be updated after creation

CBecause patchState is asynchronous

DBecause the state is frozen at runtime

What does store.user.name() return?

javascript

withState({ user: { name: 'Ada', email: 'a@b.c' } })

AA compile error; only top-level keys become signals

BThe whole user object

C'Ada' — state is exposed as deep signals, so nested properties are individually readable and individually tracked

DA promise

Answer all 10 questions (7 more), see explanations for every answer, and track your score.