docs(core): explain how to create dynamic store instances using defin…

[hdJerry]

✨ Description

This PR adds a concise section demonstrating how to create dynamic Pinia store instances using unique IDs with defineStore().
It introduces a practical pattern like:

export const useBroadcastStore = (id?: string) =>
  defineStore(`BroadcastStore-${id}`, {
    state: () => ({ messages: [] }),
    actions: {
      addMessage(msg) {
        this.messages.push(msg)
      },
    },
  })()

Each call to useBroadcastStore(id) returns an independent store instance that shares the same structure but maintains its own state.

---

Why

• Clarifies that store IDs can be generated dynamically.
• Documents a widely used but previously undocumented pattern.
• Keeps the example short and aligned with the existing tone of the Defining a Store section.

---

Example Use Cases

• Multiple chat rooms or broadcast channels
• One store per open document or tab
• Isolated stores for multi-session dashboards

---

Summary

This addition enhances the Defining a Store guide by showing how to use defineStore() dynamically to create multiple independent store instances with shared logic — a common need in real-world applications.

Summary by CodeRabbit

• Documentation
  • Added comprehensive "Dynamic Store IDs" guide covering per-instance store creation with dynamically generated identifiers, enabling isolated state management for multiple store instances
  • Includes detailed code examples demonstrating how to create and manage independent stores with completely separate state, actions, and data isolation

[netlify]

✅ Deploy Preview for pinia-official ready!

Name	Link
🔨 Latest commit	bfdf7d1
🔍 Latest deploy log	https://app.netlify.com/projects/pinia-official/deploys/68fc02409a9302000867ffc2
😎 Deploy Preview	https://deploy-preview-3056--pinia-official.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Walkthrough

Documentation additions explaining dynamic store IDs feature, introducing per-instance store creation using useBroadcastStore(id) with code example demonstrating isolated state across multiple store instances.

Changes

Cohort / File(s)	Summary
Documentation: Dynamic Store IDs packages/docs/core-concepts/index.md	Added new "Dynamic Store IDs" section explaining per-instance store creation and isolation, including practical code example with useBroadcastStore(id) demonstrating independent stores (roomA, roomB) with separate state management

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• Straightforward documentation addition with no logic changes
• Code example is illustrative and demonstrates existing functionality

Suggested reviewers

• posva

Poem

🐰 A store for each, dynamic and free,
Per-instance magic, as it should be,
roomA and roomB, isolated and bright,
Documentation blooms, making all things right! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "docs(core): explain how to create dynamic store instances using defin…" directly and accurately reflects the main change in the changeset. The title explicitly identifies this as a documentation update that explains how to create dynamic store instances, which precisely matches the PR objective of adding a new "Dynamic Store IDs" section with code examples. The title is concise, specific, and avoids vague language; it clearly communicates the primary purpose to someone reviewing the git history. The truncation with "defin…" is a common formatting limitation and clearly refers to defineStore(), the core mechanism being documented.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

packages/docs/core-concepts/index.md (2)

175-188: Clarify the pattern's mechanics and add safety for undefined id.

The trailing () invocation on line 188 could benefit from brief explanation—it converts the returned composable into a store instance. Additionally, since id is optional, stores could inadvertently share state when called without an argument (all resulting in BroadcastStore-undefined).

Consider either requiring the id parameter or providing a default:

-export const useBroadcastStore = (id?: string) =>
-  defineStore(`BroadcastStore-${id}`, {
+export const useBroadcastStore = (id: string = Math.random().toString()) =>
+  defineStore(`BroadcastStore-${id}`, {

Alternatively, add a note cautioning against omitting id if state isolation is critical.

---

175-204: Consider adding context on SSR compatibility and devtools behavior.

Given the SSR warnings earlier in the documentation (line 79 and elsewhere), it would be helpful to note whether this dynamic store pattern works reliably with SSR and how it appears in devtools (e.g., do all instances of BroadcastStore-a appear as a single store or separate entries?). This context would help developers decide when to use this pattern.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2deeee3 and bfdf7d1.

📒 Files selected for processing (1)

• packages/docs/core-concepts/index.md (1 hunks)

🔇 Additional comments (1)

packages/docs/core-concepts/index.md (1)

177-178: Clarify when state is shared vs. isolated across component instances.

The claim "Each call creates an independent store" could mislead readers. If useBroadcastStore('a') is called from multiple components, they all access the same store instance and share state. This is likely the intended behavior, but the docs should explicitly clarify whether isolation is per-call-site, per-component-instance, or per-ID.

[djunehor]

Believe this is a great addition. It's quite important but not generally documented. People might not know this is possible.

[posva]

This is actually not good because it re defines the same store over and over and it's not expected behavior 😅

I see this behavior of trying to reuse a store a lot of times but it shouldn't be this way, it should have a collection within the store and then within a composable use that store and pass the other arguments

[posva]

I added a ticket to the roadmap to not forget about this, thanks for the PR thought! 🙏

[hdJerry]

This is actually not good because it re defines the same store over and over and it's not expected behavior 😅

I see this behavior of trying to reuse a store a lot of times but it shouldn't be this way, it should have a collection within the store and then within a composable use that store and pass the other arguments

That's quite interesting, I was thinking I was being smart. Lol. What's the issue with this approach?