Provide initial data for pinia on the server side

[YKDZ]

Hello everyone,

I’m using vike-vue + vike-vue-pinia in my project. Initially, following the documentation, I tried fetching the page’s initial data from a trpc server-side call inside the data.server.ts hook and injecting it into Pinia like this:

const myData = {...};
useMyStore(ctx.pinia).data = myData;

However, I noticed this doesn’t work properly. After some experimentation, I discovered that onCreateApp is called after data.server, which means I can’t provide data to the store in data.server because ctx.pinia doesn’t exist yet.

Where should I perform this work instead? I tried onBeforeRender, onBeforeRenderHtml, etc., but none of them meet my needs.

Currently, I’m using data.server + Vue’s onBeforeMounted to inject data into Pinia on the client side, but this causes a hydration node mismatch issue. Any suggestions?

[brillout]

Quick reply: vikejs/vike-react#87 (comment).

I'll read your question more thoroughly later.

CC @4350pChris

[YKDZ]

Do you mean using useData<Data>() on the client side to fetch data and inject it into the store like this?

// MyComponent.vue
onMounted(() => {
  const { projects } = useData<Data>();
  useMyStore().projects = projects;
})

My usual approach is to use const { data } = storeToRefs(useMyStore()) in Vue components to get reactive data for rendering pages, but this causes hydration mismatches in SSR scenarios.

However, doing things like this can indeed solve the problems I mentioned above:

// MyComponent.vue
// Do this both in server an client side
const { projects } = useData<Data>();
useMyStore().projects = projects; 

But I’d prefer to centralize everything in data.server instead of splitting the "inject data into store" logic across two separate files.

(I'm very sorry if I misunderstood your meaning.)

[brillout]

I meant using pageContext.data inside +onBoreRenderClient(). Does that make sense?

[YKDZ]

Are you referring to something like the following code? In my use case, this still causes hydration mismatch and doesn’t meet the requirement of "handling everything in data.server".

// data.server.ts
export const data = async (ctx: PageContext) => {
  const projects = { ...data }
  return {
    projects,
  };
};

// +onBeforeRenderClient.ts
export const onBeforeRenderClient = (ctx: PageContext) => {
  useProjectStore(ctx.globalContext.pinia).addProjects(
    ...(ctx.data as { projects: Project[] }).projects,
  );
};

// +Page.vue
<script setup lang="ts">
const { projects } = storeToRefs(useProjectStore());
</script>

<template>
  <div v-for="project in projects :key="project.id">xxx</div>
</template>

[brillout]

doesn’t meet the requirement of "handling everything in data.server"

Makes sense. Let me think about a clean solution an circle back on this.

[brillout]

We released a new hook +onData which covers this use case.

Contribution welcome to update vike-vue-pinia's docs: vikejs/vike-vue#206.

[YKDZ]

After some testing, I finally found an implementation that I'm fairly satisfied with. It roughly looks like this:

// +onBeforeRenderClient.ts
export const onBeforeRenderClient = (ctx: PageContext) => {
  const { _piniaInitState } = ctx;
  if (_piniaInitState) {
    ctx.globalContext.pinia!.state.value = {
      ...ctx.globalContext.pinia!.state,
      ..._piniaInitState,
    };
  }
};

// +onBeforeRoute.ts
export const onBeforeRoute = (ctx: PageContext) => {
  // _piniaInitState store the reference of pinia.state
  ctx._piniaInitState = ctx.pinia?.state.value;
};

// +onCreateApp.ts
export const onCreateApp = (ctx: PageContext) => {
  const { app } = ctx;
  if (!app) return;

  if (!import.meta.env.SSR) {
    ctx.globalContext.pinia = createPinia();
  }

  // client: GlobalContext
  // server: PageContext
  app.use(ctx.globalContext.pinia ?? ctx.pinia!);
};

// +onCreatePageContext.server.ts
export const onCreatePageContext = (ctx: PageContext) => {
  ctx.pinia = createPinia();
};

Through the above implementation, I can achieve:

• Modify the store within data.server.ts and have its values properly passed to the client
• Values set on the server side can be seamlessly merged into the client (I'm not entirely sure about this part, at least I haven't found issues yet)
• Handle everything inside data.server.ts without introducing a second file

[YKDZ]

Yes, it works very well most of the time, and I can completely abandon the original _piniaInitState design and switch to using ctx.data to pass the initial state of the store to the client.
However, I would like to know if the onData hook is intentionally designed not to be called on the client side when visiting a page for the first time. Because this results in filling the store only working properly when navigating from one page to another.
For example, I have a data.server.ts that return todos data and a onData hook under /todos route. This onData hook will not be called in client side when I first visit /todos, it will only be called when I navigate from a page (such as /) to /todos.

[YKDZ]

The relevant code in my current implementation is as follows:

// /pages/todos/+data.server.ts
export const data = async (ctx: PageContext) => {
  const todos = await ... // Some db code
  return { todos };
};

// /pages/todos/+onData.ts
export const onData = (ctx: PageContext & { data?: Data }) => {
  if (!ctx.data) return;

  const { todos } = ctx.data;
  useTodoStore(ctx.globalContext?.pinia ?? ctx.pinia!).add(
    ...todos,
  );

  if (!import.meta.env.SSR) delete ctx.data;
};

// /pages/+onCreateApp.ts
export const onCreateApp = (ctx: PageContext) => {
  const { app } = ctx;

  if (!app) return;

  if (!import.meta.env.SSR) {
    ctx.globalContext.pinia = createPinia();
  }

  // client: GlobalContext
  // server: PageContext
  app.use(ctx.globalContext.pinia ?? ctx.pinia!);
};

// /pages/+onCreatePageContext.server.ts
export const onCreatePageContext = (ctx: PageContext) => {
  ctx.pinia = createPinia();
};

[YKDZ]

By the way, I also wrote a helper to further simplify all of these things:

// helper.ts
export const injectPiniaData = <T>(
  handler: (pinia: Pinia, data: T) => void,
) => {
  return (ctx: PageContext & { data?: T }) => {
    if (!ctx.data) return;
    const pinia = ctx.globalContext?.pinia ?? ctx.pinia!;
    handler(pinia, ctx.data);
    if (!ctx.isPrerendering) delete ctx.data;
  };
};

// data.server.ts
export const data = async (ctx: PageContext) => {
  const glossary = // some db code;

  return {
    glossary,
  };
};

export type Data = Awaited<ReturnType<typeof data>>;

// onData.ts
export const onData = injectPiniaData<Data>((pinia, { glossary }) => {
  useGlossaryStore(pinia).addGlossaries(glossary);
});

But the hook call issue mentioned in the previous reply still troubles me.

[brillout]

vikejs/vike-react@3e8a2e5

I believe this answers your question.

In case you're up for it, contribution welcome to add a to-do list example at examples/vue-pinia/ by porting the to-do list example from here.

[YKDZ]

I finally understand. Thank you for your patient guidance. I’ll try to work on the examples/vue-pinia/.

[brillout]

@YKDZ (or anyone else) I'm curious: why do you want to populate your store with pageContext.data to begin with? WDYT of the note When do I need to use my store on the server-side? at https://vike.dev/store#ssr?

[YKDZ]

At present, my personal use case does not exceed the content in the document: basically, it is achieved by obtaining some list data in advance on the server to avoid flickering and spinning during client rendering, and to allow users to see more content on the first screen.