How a v-for Assignment White-Screened a Vue App — and the Two Safe Fixes
The same Vue code that passes local testing white-screens in production with zero console output, because assignment expressions inside v-for compile to the render function's global scope. SSR environments expose it even earlier, since Node defaults to strict mode, so this is a tooling behavior every team needs to plan for.
A Vue list page white-screened in pre-production after a temporary variable was added inside a v-for block. Local runs with 200 rows passed without a warning. The compiled render function shows the assignment hoisted to the top level, so the variable becomes global in non-strict mode and gets overwritten on each iteration until the call stack overflows. Vue's template compiler preserves raw expression structure, so the mistake passes.
Two safe patterns work: precompute the derived value in a computed property, or call the method directly inside the v-if. Measurements show both are fast: 42ms and 38ms for 1000 renders, with memory around 16MB. Beyond that, side-effect mutations, destructuring, and async calls inside v-for all carry the same risk. To catch these silent failures, flip on ESLint's no-undef, force strict mode in the Vue build, and treat templates as pure display layers.
The crash is a scoping artifact: Vue's template compiler lets a careless assignment escape its expected local context, which JavaScript silently allows in sloppy mode.
The local/production split suggests data size or the extra render passes in pre-production flip the call stack threshold; the same bug could appear sooner on any larger list.
This is a reminder that template DSLs are not plain JavaScript; the mental model of 'it's just a for loop' is wrong.
Computed properties are suitable for centralized derived data.