usePage() Memory leak in SSR

[KevinXL]

Version:

• @inertiajs/vue3 version: 1.0.9

Describe the problem:

I am using Inertia Vue 3 with SSR.
This works fine with v1.0.0 but after updating to the latest version I saw the memory of the GCP run container increasing to 100%. So it looks like a memory leak.
After some testing, the usePage() is the problem.
I changed all the usePage() to $page and the memory leak is gone.

Is it possible that this update ensures the memory leak?
https://github.com/inertiajs/inertia/pull/1469/files#diff-25b79295169393d2d80fe8246bba1ae0ec1b3cdffb6592d81b9f5ad63d8a7f97R130

Steps to reproduce:

This gives me a memory leak:

<template>
{{ user.name }}
</template>

<script>
  import {usePage} from '@inertiajs/vue3';

  computed: {
    user() {
      return usePage().props.auth.user;
    },
  },
</script>

And no memory leak when I just use:

<template>
{{ $page.props.auth.user.name }}
</template>

[thecrypticace]

Hey! This is likely happening because new reactive and computed objects / proxies are being created every time the user computed property is accessed. There's a chance that this also causes the computed prop to not cache anything because it looks like "dependencies" have changed on every access.

Instead, you should call usePage() inside a setup function (or <script setup> block) and then use it inside a computed property:

<template>
{{ user.name }}
</template>

<script setup>
  import { usePage } from '@inertiajs/vue3';
  import { computed } from 'vue';
  
  let page = usePage()
  let user = computed(() => page.props.auth.user)
</script>

If you still see a memory leak after making this change could you please open an issue with a reproduction on GitHub?

Hope that helps! ✨

[jeanlucnguyen]

I think I'm having the same issue, SSR with Inertia v1.0.10 and Vue 3, I get

Inertia\Ssr\SsrException

<--- Last few GCs --->

[23912:0x610ea60] 30754314 ms: Scavenge (reduce) 2038.4 (2066.7) -> 2038.3 (2068.0) MB, 21.6 / 0.0 ms  (average mu = 0.961, current mu = 0.550) allocation failure 
[23912:0x610ea60] 30754849 ms: Mark-sweep (reduce) 2039.5 (2068.0) -> 2039.2 (2069.0) MB, 532.0 / 0.0 ms  (average mu = 0.906, current mu = 0.197) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb090e0 node::Abort() [node]
 2: 0xa1b70e  [node]
 3: 0xce1a20 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xce1dc7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xe99435  [node]
 6: 0xea90fd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0xeabdfe v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0xe6d072 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]

I'm going to try the option you suggest, but what is the difference between using usePage() and accessing directly the $page property?

[reinink]

I'm going to try the option you suggest, but what is the difference between using usePage() and accessing directly the $page property?

Using the global $page property is technically simpler, just because on how it's implemented in the root <App /> component, but we've been generally moving away from using global properties and instead using hooks like usePage(), as that feels more inline with how people are doing things in JavaScript these days.

Plus, I don't think you can use $page in <script setup>, if I recall correctly.

[jeanlucnguyen]

@reinink Thanks for the clarification.

Just to follow up on the issue, I have replaced usePage() everywhere by $page as mentioned by @KevinXL and I stopped having the memory leak crash.

Haven't tried to move the usePage() out of the computed property as suggested but the issue I see is that some libraries use the usePage() in the computed property (some components stub in Laravel Jetstream for example). At least, it would be good to show a warning in the docs to not use usePage() inside a computed property so everyone can update accordingly.

[glenncoppens]

Just an update of our findings, if someone is in doubt that this could be a thé cause. It seemed we had been experiencing the same symptoms using SSR. Below is a before and after situation in 1 chart to show the impact on RAM usage. We replaced every usePage() inside a computed prop with a data prop { page: usePage() } (options API) and const page = usePage() (composition API).

inertiajs/inertia-laravel: v0.6.9