Effector Storage Skill
Use this skill to design, implement, and debug effector-storage integrations with predictable runtime behavior.
Workflow
- •Classify the request:
- •
adapter-choice: pick the right adapter for environment and data behavior. - •
integration: wirepersist/createPersistinto 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.
- •Load references progressively:
- •Start with
references/core-patterns.md. - •Add
references/adapter-matrix.mdwhen adapter selection/configuration is needed. - •Add
references/tools-and-composition.mdforasync,either,farcached, or composition recipes. - •Add
references/contracts-and-errors.mdfor contracts and error channels. - •End with
references/pitfalls-and-checklist.mdbefore finalizing.
- •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-storagev7.x behavior. - •Prefer explicit
keyover 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
keyand store name. - •Do not use
source === targetfor non-store units. - •Do not assume
pickupstill 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
broadcastas durable storage; it is sync-only messaging.
Practical Extras Boundary
For adapters from effector-storage-extras, reuse the same adapter contract and decision flow from this skill, but verify exact API/options in that repository before coding.