Effector Storage Skill

effector-storage

Workflow

1. Classify the request:

• adapter-choice

  : pick the right adapter for environment and data behavior.

• integration

  : wire

  persist

  /

  createPersist

  into existing model flow.

• contracts-errors

  : validate storage payloads and route failures.

• sync-debug

  : investigate cross-tab/query/broadcast synchronization issues.

• ssr-fallback

  : make persistence safe across browser/server runtimes.

1. Load references progressively:

• Start with

  references/core-patterns.md

  .
• Add

  references/adapter-matrix.md

  when adapter selection/configuration is needed.
• Add

  references/tools-and-composition.md

  for

  async

  ,

  either

  ,

  farcached

  , or composition recipes.
• Add

  references/contracts-and-errors.md

  for contracts and error channels.
• End with

  references/pitfalls-and-checklist.md

  before finalizing.

1. Build answer contract:

• Start with a concrete adapter decision and why.
• Provide a minimal working snippet with explicit key strategy.
• List behavior caveats (init timing, sync limits, validation behavior).
• Add verification steps/tests for the chosen flow.

Defaults

• Target

  effector-storage

  v7.x behavior.
• Prefer explicit

  key

  over implicit store names for portability.
• Prefer declarative Effector wiring around

  persist

  (sample/clock/context units).
• Keep payloads plain and serialization stable (

  deserialize(serialize(x))

  ).

Guardrails

• Do not omit both

  key

  and store name.
• Do not use

  source === target

  for non-store units.
• Do not assume

  pickup

  still performs automatic initial restore (it disables it).
• Do not assume contract validation prevents writes; invalid values can be persisted and then reported via

  fail

  .
• Do not treat

  broadcast

  as durable storage; it is sync-only messaging.

Practical Extras Boundary

effector-storage-extras