DEV Community: Uncle Pushui

Why Frontends Still Need Wrapping After Hooks

Uncle Pushui — Sat, 18 Jul 2026 04:49:19 +0000

Hooks replaced many inappropriate HOC use cases. They did not remove the need to apply independent rules around an existing rendering target.

When we ask whether HOCs are obsolete, it is easy to mix up two different questions:

How should components reuse internal state, requests, subscriptions, and interaction logic?
How should an application independently handle props, refs, layout, and presentation policies around the rendering boundary of an existing component or native element?

For the first question, a custom Hook is usually the right starting point today. If an HOC only moves useQuery, useEffect, or useState outward and passes the result back through props, it often adds little more than another component layer and prop forwarding.

The second question did not disappear with Hooks. The key is not whether a few lines of code can live inside a component. It is this:

Should this rule be owned by the target component itself, or should it remain an optional, replaceable, and composable rendering policy?

Hooks are for reusing internal logic

Custom Hooks are the natural modern React mechanism for reusing stateful and side-effectful logic. If several components need to subscribe to online status, for example, that subscription can live in useOnlineStatus(). Each calling component still decides how to use the result and what UI to render.

The ownership stays inside the caller's boundary: the component uses the data, handles the interaction, and owns the final output. A Hook does not introduce a new UI boundary, which is why it fits data access, state, subscriptions, and event handling so well.

This also explains why many classic HOCs now feel cumbersome: they were often used for internal logic reuse that a Hook can express more directly.

A Hook, however, is not a universal syntax for wrapping rendering elsewhere. If a requirement needs to alter props passed to a target, intercept a ref, or place the rendered result inside a shared layout, it is dealing with a different boundary.

Start with React: what does an autofocus HOC solve?

Consider an input that should receive focus after it mounts. If we want that behavior to be attachable to multiple input-compatible components, a traditional React HOC might look like this:

function withAutoFocus(WrappedInput) {
  return React.forwardRef(function AutoFocus(props, outerRef) {
    const inputRef = React.useRef(null);

    React.useEffect(() => {
      inputRef.current?.focus();
    }, []);

    return (
      <WrappedInput
        {...props}
        ref={node => {
          inputRef.current = node;

          if (typeof outerRef === 'function') {
            outerRef(node);
          } else if (outerRef) {
            outerRef.current = node;
          }
        }}
      />
    );
  });
}

Used like this:

const AutoFocusInput = withAutoFocus(TextInput);

<AutoFocusInput placeholder="Enter something" />

This works, and the requirement it expresses is perfectly valid: add a “focus after mount” rule to a render target without changing TextInput itself.

It also exposes the cost of the classic HOC expression:

it creates a new component type;
if callers need the input node, it must deliberately preserve the outer ref contract;
the wrapped component must support the relevant ref contract too;
production HOCs often also need to consider debugging names and static properties.

So the useful conclusion is not that HOCs can never be used. It is that an HOC is rarely the first choice when the goal is only to reuse internal stateful logic; when the rule really belongs at a rendering boundary, it is still describing a real problem.

The decision test: who owns this rule?

When a requirement should be reused, start with three questions:

Is it intrinsic behavior of the target component, or a policy needed only in certain contexts?
Should callers be able to attach, remove, or combine the rule independently?
Does it need to alter render input, a ref, output structure, or presentation around the target?

The answers point to different abstractions:

If the rule is intrinsic to the component, keep it inside the component, using a Hook where appropriate.
If it must expose a stable, standalone UI contract, make it a normal component.
If it only transforms data and has no rendering concern, use a pure helper.
If it intercepts or wraps an existing render target and must compose independently, it needs some form of wrapping capability.

React HOCs, other wrappers, and Cabloy/Zova Behaviors are different implementations of that last category. They are not the same runtime mechanism, but they all address cases where a rule should not be fused into its target.

Zova Behavior: attach a rule to the render target

In Cabloy/Zova, the same autofocus requirement can be expressed with a Behavior:

<input bs-behaviors-focus type="text" />

The <input> is still just an input. Autofocus is a capability attached to its rendering process. Its essential implementation looks like this:

@Behavior<IBehaviorOptionsFocus>()
export class BehaviorFocus extends BeanBehaviorBase<
  IBehaviorOptionsFocus,
  IBehaviorPropsInputFocus,
  IBehaviorPropsOutputFocus
> {
  inputRef?: HTMLElement;

  protected render(props, next) {
    const refOuter = props?.ref;

    props = {
      ...props,
      ref: ref => {
        if (this.$options.always || !this.inputRef) {
          ref.focus?.();
        }
        this.inputRef = ref;
        refOuter?.(ref);
      },
    };

    return next(props);
  }
}

It does a small number of things:

receives the current render props;
preserves the original ref;
injects a new ref that calls focus() once the element is available;
calls the original ref as well;
continues the original render with next(props).

This is direct render-time composition: a Behavior can adjust the input to the next render step, while the target element remains unaware of whether autofocus is needed.

Behavior is not a “Vue HOC.” Zova is built on Vue runtime and reactivity, but it provides an application architecture based on controllers, beans, and IoC. Behavior is Zova's native facility for render-time interception and composition. The important point here is not its lower-level runtime machinery, but that it expresses autofocus as a rule that can be attached to a target independently.

Not only props: wrapping rendered output

Autofocus demonstrates a before-render shape: change the input to the next render step, such as props or a ref.

A second kind of requirement makes the value of wrapping even clearer: form-field layout. A field control owns input, values, and validation, but different pages may need to present it differently: add a label, display validation errors, insert prefix or suffix content, or apply a block or inline layout.

A layout Behavior can first obtain the field's original rendering result, then add presentation structure around it. Its core shape is like this:

const vnode = next(renderContext);

return (
  <fieldset>
    <legend>{label}</legend>
    {vnode}
    {errorMessage}
  </fieldset>
);

If the layout rule is intended only for a native input, a separate layout Behavior can be attached directly to <input>. For example, define demo-ui:inputLayout to accept ordinary native props, call const vnode = next(props), and return a layout shell. Its usage can be as simple as:

<input bs-demo-ui-inputLayout type="text" placeholder="Enter something" />

That attaches demo-ui:inputLayout to the rendering process of a native input: the Behavior continues rendering the input, then places its resulting vnode in its own layout structure. It does not change the responsibility of <input>, and it does not require a dedicated input component for this case.

Cabloy Basic's existing form-field layout Behavior follows the same “render first, then wrap” pattern, but it runs inside a form-field host and depends on field state and layout configuration. It should therefore be used through ZFormField and a form provider, not attached directly to an arbitrary <input>. Native-element use cases need a separate Behavior such as demo-ui:inputLayout that handles ordinary input props.

A page can also choose a form-field layout Behavior. For example, the login page selects home-login:formFieldLayoutLogin through ZForm's formProvider, so every field in that form automatically receives the layout Behavior and renders with a consistent visual style:

<ZForm
  formProvider={{
    behaviors: {
      FormFieldLayout: 'home-login:formFieldLayoutLogin',
    },
  }}
>
  {/* fields */}
</ZForm>

The useful separation is: the field owns the field itself; the layout policy owns how that field is wrapped and presented in this page.

If the login layout were hard-coded into every field component, layout policies for different pages would contaminate one another. If every page copied fields and layout code, there would be no shared point of adjustment. A selectable rendering rule preserves the field's stable contract while preserving page-level presentation freedom.

Which reuse mechanism should you choose?

Need	First choice	Why
Reuse state, data, subscriptions, and interaction inside a component	Custom Hook	The logic still belongs to the calling component's own boundary.
Provide stable, standalone UI structure with explicit inputs and outputs	Component	The abstraction owns a clear UI contract.
Transform data or normalize options without rendering context	Pure helper	No framework-level render composition is needed.
Alter props/`ref`s or wrap an existing render target	HOC / Wrapper / Behavior	The rule belongs around the target and may need independent attachment and composition.

This table does not mean every visual requirement should become a Behavior. When an abstraction owns a stable interface and interaction contract of its own, a normal component is usually clearer. HOCs, wrappers, and Behaviors matter because they let a rule live around an existing target instead of becoming an inseparable part of that target.

Conclusion

Classic React HOCs can seem obsolete mainly because they were once used to solve many problems that Hooks now solve better.

Wrapping itself is not obsolete. As long as a requirement is fundamentally about:

intercepting a target's props or ref before render;
adding a shared presentation or interaction policy outside the target;
independently declaring and combining cross-cutting rules;

there is still a place for HOCs, wrappers, and Zova Behaviors.

What became outdated was not the idea of wrapping. It was the habit of turning every reuse problem into an HOC.\
Hooks are for internal logic reuse; wrapping capabilities attach and compose cross-cutting rules at a rendering boundary.

Cabloy Form Layout: Organize Complex Forms in DTOs with Tabs, Groups, and Sections

Uncle Pushui — Sat, 18 Jul 2026 02:04:16 +0000

Automatically rendered forms work well when there are only a few fields. As a form grows to include profile information, contact details, and business records, structure starts to matter: how should fields be grouped? Which fields should sit side by side? Which content belongs in a separate tab?

Cabloy Form Layout is designed for exactly this. It lets you describe the placement and hierarchy of multiple form fields in a DTO, then lets the frontend render that structure from the configuration.

Put simply: Form Layout decides where fields go. The existing schema and form configuration still decide field types, labels, validation, and other field behavior.

What Form Layout Can Do

With Form Layout, you can configure common form requirements in a DTO:

Change the order in which fields appear.
Put related fields into a titled business group.
Use multiple columns on wider screens and a single column on smaller screens.
Split independent content, such as Basic Information and Training Records, into separate tabs.
Apply the same structural approach across create, update, and view forms.

The main nodes are straightforward:

field: places one field.
section: arranges fields in one or more columns.
group: organizes related fields together.
tabs / tab: divides separate content areas into tabs.

Example: Structuring the Student Form

The following Student Create DTO layout is slightly simplified for illustration. It focuses on the Form Layout portion and omits the outer DTO definition, page actions, and other field configuration.

ZovaRender.block('basic-form:blockFormLayout', {
  formLayout: {
    children: [
      {
        type: 'tabs',
        children: [
          {
            type: 'tab',
            title: $locale('BasicInformation'),
            children: [
              {
                type: 'group',
                title: $locale('StudentProfile'),
                children: [
                  {
                    type: 'section',
                    columns: { default: 1, md: 2 },
                    children: [
                      { type: 'field', name: 'name' },
                      { type: 'field', name: 'mobile' },
                      {
                        type: 'field',
                        name: 'imageId',
                        span: { default: 1, md: 2 },
                      },
                    ],
                  },
                ],
              },
            ],
          },
          {
            type: 'tab',
            title: $locale('TrainingRecords'),
            children: [
              { type: 'field', name: 'level' },
              { type: 'field', name: 'trainingRecords' },
            ],
          },
        ],
      },
    ],
  },
});

Read the example from the outside in to see what it produces.

1. `tabs` and `tab`: Split the Form by Business Area

The outer tabs node creates a tabbed area. It contains two tab nodes:

BasicInformation
TrainingRecords

Tabs help readers focus on one area at a time when a form contains independent business content. If a form has only a few fields, a simple group is usually easier to scan than a tabbed interface.

2. `group`: Give Related Fields a Clear Context

The group in the Basic Information tab is titled StudentProfile. It puts the student's name, mobile number, and image under one shared business context.

Think of a group as a titled grouping for related fields. Contact details, shipping addresses, and approval information are all common examples.

3. `section`: Control Responsive Columns

The section controls the field grid. columns: { default: 1, md: 2 } means one column by default and two columns at the md breakpoint and above.

As a result, name and mobile can appear side by side on wider screens and naturally stack on smaller screens.

4. `field`: Reference Fields Already Defined in the DTO Schema

Each field uses name to reference a field that already exists in the DTO schema, such as name. Its widget, label, and validation rules continue to use the field's existing configuration.

imageId also uses span: { default: 1, md: 2 }. It takes one column in the default layout and both columns in the two-column layout. This is useful for an image, note, or description that should occupy a full row.

Choosing the Right Node

Start with the smallest structure that expresses what the form needs:

Requirement	Use
Only change field order	`field`
Show fields side by side on wider screens	`section`
Give related fields a shared title and boundary	`group`
Separate genuinely independent business content	`tabs` / `tab`

A common composition is: Tabs divide business areas, Groups express business context, Sections handle responsive columns, and Fields place individual fields.

You do not need every container for every form. Use field alone for a simple form, add a section when columns help, and add a group only when fields truly belong to the same business block.

One Easy-to-Miss Detail

Form Layout controls field placement, not field visibility.

If a field should not appear, configure its visibility in the field's schema metadata. Leaving it out of formLayout does not necessarily hide it; an eligible visible field can still appear at the end of the form.

Summary

Form Layout lets a DTO describe the structure of a complex form:

Use field to set field order.
Use section for responsive columns.
Use group for business grouping.
Use tabs / tab to separate independent content.

The key division of responsibility is simple: DTO metadata describes the form structure; the schema and form runtime continue to govern each field's behavior. When fields change, update the layout in the DTO instead of maintaining field placement repeatedly across multiple pages.

How to Bridge Login State Across SSR and CSR: Next.js, Nuxt, and Cabloy Compared

Uncle Pushui — Mon, 13 Jul 2026 02:00:38 +0000

Supporting login state across SSR and CSR is not merely a question of whether a cookie travels with the request. The real work is verifying identity on the server, reusing that result for the first client render, recovering a good browser experience later, and still authorizing every protected operation on the server.

Start with three minimal implementations

Before discussing abstractions, here are representative ways that Next.js, Nuxt, and Cabloy carry server-verified login state into the first client render.

All three examples deliberately expose only a UI-safe public DTO. A raw session token, refresh token, password hash, and server-internal fields do not belong in a hydration payload.

Next.js App Router: a Server Component passes a safe DTO explicitly

// app/types/session.ts
export type PublicSession = {
  user: { id: string; name: string };
  roles: string[];
} | null;

// app/lib/session.ts
import 'server-only';
import { cookies } from 'next/headers';
import type { PublicSession } from '@/app/types/session';

export async function getPublicSession(): Promise<PublicSession> {
  const token = (await cookies()).get('session')?.value;
  if (!token) return null;

  const session = await verifySessionOnServer(token);
  if (!session) return null;

  return {
    user: {
      id: session.user.id,
      name: session.user.name,
    },
    roles: session.roles,
  };
}

// app/dashboard/page.tsx — Server Component
import { DashboardClient } from './dashboard-client';
import { getPublicSession } from '@/app/lib/session';

export default async function DashboardPage() {
  const initialSession = await getPublicSession();

  return <DashboardClient initialSession={initialSession} />;
}

// app/dashboard/dashboard-client.tsx
'use client';

import type { PublicSession } from '@/app/types/session';

export function DashboardClient({
  initialSession,
}: {
  initialSession: PublicSession;
}) {
  if (!initialSession) return <a href="/login">Sign in</a>;

  return <p>Hello, {initialSession.user.name}</p>;
}

A protected operation still establishes identity and authorizes the exact resource on the server:

// app/lib/projects.ts
import 'server-only';
import { getPublicSession } from './session';

export async function getProjectForViewer(projectId: string) {
  const session = await getPublicSession();
  if (!session) throw new Error('Unauthenticated');

  await assertCanReadProject(session.user.id, projectId);
  return await db.project.findUniqueOrThrow({ where: { id: projectId } });
}

Nuxt: a server session endpoint plus a `useFetch` payload

// server/api/session.get.ts
import { getCookie } from 'h3';

export default defineEventHandler(async event => {
  const token = getCookie(event, 'session');
  if (!token) return { user: null, roles: [] };

  const session = await verifySessionOnServer(token);
  if (!session) return { user: null, roles: [] };

  return {
    user: {
      id: session.user.id,
      name: session.user.name,
    },
    roles: session.roles,
  };
});

// composables/useSession.ts
export function useSession() {
  return useFetch('/api/session', {
    key: 'session',
    default: () => ({ user: null, roles: [] }),
  });
}

<!-- app.vue or a layout -->
<script setup lang="ts">
const { data: session } = await useSession();
</script>

<template>
  <AccountMenu :session="session" />
</template>

Cabloy: server `mem`, client `local`, bridged by the Model Query Cache

This is the current shape of Cabloy Basic's ModelPassport:

// zova/src/suite/a-home/modules/home-passport/src/model/passport.ts
this.passport = process.env.CLIENT
  ? this.$useStateLocal({ queryKey: ['passport'] })
  : this.$useStateMem({ queryKey: ['passport'] });

The server confirms the passport using the authentication information for the current request:

async ensurePassport() {
  if (process.env.CLIENT) return this.passport;

  if (!this.sys.config.ssr.cookieDisabledOnServer && !this.isAuthenticated && this.accessToken) {
    this.passport = await this.$api.homeUserPassport.current();
    this._setLocaleTz();
  }

  return this.passport;
}

The surface APIs differ, but the shared principle is the same:

The browser receives a server-confirmed, UI-safe projection of login state. Authentication and authorization decisions remain on the server.

What each implementation is actually solving

Next.js: the Server Component is the start of the bridge

The natural boundary in the Next.js App Router is between Server Components and Client Components.

HttpOnly Cookie
  → server-only session verification
  → Server Component
  → serializable initialSession prop
  → Client Component hydration

cookies() is read along a server execution path. getPublicSession() reads the request cookie, verifies the session, and constructs a small, explicit PublicSession DTO. The Server Component then passes it as initialSession to the Client Component.

Two details matter:

The Client Component receives a DTO, not the cookie or raw session. HttpOnly exists specifically to keep the credential unavailable to browser JavaScript.
initialSession solves first-render consistency. It avoids a server-rendered signed-in UI becoming a signed-out client UI during hydration. It does not authorize a later Server Action, Route Handler, or data-access operation.

Next.js does not decide your global client session store for you. The application may put initialSession in Context, a state store, a Query cache, or pass it farther through the component tree. That explicitness is a feature: the application owns both the session DTO and its later client-state policy.

Nuxt: keyed async data bridges the SSR payload

In Nuxt, the primary bridge is commonly useFetch or useAsyncData:

HttpOnly Cookie
  → /api/session server endpoint
  → useFetch('/api/session', { key: 'session' })
  → Nuxt SSR payload
  → Client hydration reuses payload

The server /api/session endpoint reads and validates the request cookie, then returns only public display data. A page or layout calls the same useFetch path. On SSR, the result enters the Nuxt payload; during initial hydration, the client reuses the result under that async-data identity instead of treating the same session read as an independent request.

key: 'session' provides stable identity for this async data. It also makes later refreshes such as refreshNuxtData('session') possible. It is not a permission key and does not authorize any protected endpoint.

Projects that want a fuller Nuxt session abstraction can evaluate the official nuxt-auth-utils module and its useUserSession(), setUserSession(), and requireUserSession() APIs. This article uses /api/session plus useFetch because it exposes the fundamental SSR-payload-to-client-reuse chain directly.

Cabloy: Model-owned Query Cache identity is the bridge

Cabloy's ModelPassport uses different helpers for the initial SSR source and the browser persistence policy, then joins them through the same effective Query Key:

request cookie / token
  → ModelPassport.ensurePassport()
  → server $useStateMem(['passport'])
  → request-scoped Query Cache
  → dehydrate after render
  → client QueryClient hydrate
  → client $useStateLocal(['passport'])
  → Query Cache first, localStorage fallback

The server selects $useStateMem(...) because it has no browser localStorage, and the identity for this request must be confirmed through the request credential and ensurePassport(). A successful memory Query Cache entry that passes the dehydration policy can enter the SSR snapshot.

The client selects $useStateLocal(...) because it must both reuse the initial SSR snapshot and support CSR-only entry or browser-session recovery when no snapshot exists. $useStateLocal(...) checks the Query Cache first. When a hydration entry exists, the server-confirmed passport wins. Only when no cache value exists does it attempt synchronous localStorage restoration and then fall back to meta.defaultData.

Two details are frequently misunderstood:

The dehydrated entry is the Query entry created by server $useStateMem(...), not the client $useStateLocal(...) wrapper.
Hydration restores the Query Cache. Reading that value does not automatically save it to localStorage; a later assignment through the client local-state wrapper updates the cache and writes the local record.

Also, ['passport'] is not a global key. Zova prefixes the key with Model identity, and selector-enabled Models include selector identity as well. Reuse therefore requires the same Model, applicable selector, and logical queryKey.

One table for the three bridge designs

Dimension	Next.js App Router	Nuxt	Cabloy
Server identity confirmation	Server-only code / Server Component reads and verifies Cookie	`/api/session` endpoint reads and verifies Cookie	`ModelPassport.ensurePassport()` confirms the passport for the current request
Initial client-state carrier	Explicit `initialSession` prop through the RSC payload	Nuxt payload from `useFetch`	Dehydrated and hydrated Model Query Cache entry
Later client-state policy	Context, store, or Query policy chosen by the application	`useFetch` cache; higher-level auth/state policy chosen by the application	`$useStateLocal` restores `localStorage` only when hydrated cache is absent
Identity rule	The Server/Client Component props contract	Async-data key, such as `session`	Model identity + selector when applicable + logical `queryKey`
Protected server operations	Server Actions, Route Handlers, and DAL authorize independently	Server APIs, handlers, and services authorize independently	Vona passport guard and business permission logic authorize independently
Main architectural emphasis	Server/client component boundary and safe DTOs	SSR-aware fetching and payload reuse	Model ownership, Query Cache identity, and helper lifecycle

None of these designs "hydrates a cookie into the browser." A cookie is a request credential. Hydrated props, a Nuxt payload, and a Model Query Cache entry are derived state for rendering and interaction.

The real security boundary: client login state improves UX only

Many implementations go wrong here: a page can render the user name and hide buttons by role, so the client state is treated as an authorization result.

It is not.

1. An `HttpOnly` cookie is not client state

Browser JavaScript should not read an HttpOnly cookie. The browser attaches it to requests within the cookie's scope; the server then validates its signature, expiry, session record, revocation state, or user status.

Do not conflate these two channels:

Cookie / session credential
  → server-side authentication input

hydrated public session DTO / passport cache
  → client rendering input

2. A client route guard is a UX guard, not an authorization point

A client-side guard can redirect early, avoid a visible unauthorized page, or hide unavailable controls. A caller can still issue an HTTP request directly and can still alter display state in browser memory.

Every protected Server Action, Route Handler, Nuxt server API, Vona Controller/service, or equivalent operation must independently:

establish the current identity from request authentication data;
validate that the user, tenant, and session remain valid;
authorize the exact action against the exact resource;
validate its input.

3. A smaller DTO is both safer and more stable

The first client render commonly needs no more than:

{
  user: { id, name, avatar },
  roles: ['admin'],
}

It does not need a raw session, refresh token, upstream API token, password field, internal audit field, or an entire database user record. A safe DTO reduces both direct exposure and accidental leakage as server-side data models evolve.

4. Stale display state is normal

Logout, expiration, role revocation, tenant changes, and a logout on another device can all make a browser's previous login-state projection stale.

The objective of an SSR/CSR bridge is therefore:

Make the first paint and ordinary interactions coherent, not give the client a permanently trusted copy of identity.

Cookie configuration should match the application: HttpOnly, Secure, SameSite, path, expiry, and rotation strategy all matter. Cookie-authenticated state-changing requests also need a CSRF approach appropriate to the deployment, cross-site requirements, embedded contexts, and session architecture.

Why Cabloy's bridge deserves separate attention

The Next.js and Nuxt examples usually keep one visible application abstraction across the boundary:

Next: server DTO → client prop / provider
Nuxt: server endpoint → same useFetch key

Cabloy's distinguishing feature is that the same business field can deliberately use different state helpers on server and client:

SSR Server: $useStateMem(['passport'])
SSR Client: $useStateLocal(['passport'])
Bridge: Model-owned effective Query Cache identity

This separates two needs instead of conflating them:

mem means request-confirmed runtime state for the current SSR pass, without a browser storage backend;
local means client state that can persist and recover in the browser, without overriding a hydrated server conclusion;
the common effective key joins those paths during the first hydration.

The trade-off is equally explicit. Developers must understand Model ownership, Query Cache lifecycle, dehydrate/hydrate behavior, selectors, and helper families rather than treating this as an ordinary Vue ref or one global store. For applications where SSR, caching, persistence, and resource models coexist, that explicit ownership can be easier to sustain than an accumulation of local conventions.

Common mistakes and better formulations

Misleading shortcut	More accurate formulation
"Next.js hydrates the session cookie into React."	Next.js reads the Cookie in a Server Component or server-only path and passes a serializable safe DTO to a Client Component.
"Nuxt `useCookie` lets the client read an `HttpOnly` login cookie."	`useCookie` is SSR-aware, but browser JavaScript still cannot read an `HttpOnly` cookie; the client should consume a safe DTO returned by the server.
"A `useFetch` key is a permission key."	The key identifies async data and payload/cache reuse. The server still authorizes requests from their credentials and target resources.
"Cabloy's `$useStateLocal` is dehydrated directly by the server."	In this flow, the server `$useStateMem` entry is dehydrated; the client `$useStateLocal` wrapper reuses hydrated cache through the same effective key.
"An SSR snapshot automatically persists to localStorage."	SSR hydration restores initial cache. Cabloy saves browser-local state through later assignments to the local-state wrapper.
"An API is safe because the UI hides its button by role."	UI control is an experience layer; every protected server operation must authenticate, authorize, and validate input independently.

When each structure fits

Choose an explicit Next.js DTO bridge

This fits applications centered on the App Router and Server Components that want precise control over every server-to-client boundary. The exposure surface is highly visible; the trade-off is that the application chooses and maintains its own client session provider, cache, and refresh policy.

Choose a keyed Nuxt `useFetch` bridge

This fits Nuxt applications centered on server APIs and SSR data fetching. It offers SSR-payload reuse with little plumbing; the trade-off is that a team must keep async-data keys, endpoint response shapes, and refresh/invalidation policy disciplined as the application grows.

Use Cabloy's `ModelPassport` bridge

This fits Cabloy/Zova Model applications that want SSR handoff, client cache identity, and browser persistence fallback under one Model-owned state runtime. It provides an existing passport bridge pattern; the trade-off is following the architectural rules around Model/selector/Query Key identity and helper lifecycle.

Whichever framework you choose, the stable final principle is unchanged:

The server verifies identity, the client reuses display state, and protected server operations authorize again.

References and source material

Next.js

Nuxt

Cabloy

How to Manage Complex State in Large Vue Projects: "Scattered" vs "Systematic"

Uncle Pushui — Mon, 06 Jul 2026 07:40:04 +0000

Large frontend systems rarely hit their limit because they chose the wrong individual state tool. They hit it when ownership, sharing boundaries, cache semantics, persistence, and SSR rules no longer compose into one coherent system.

The problem is not tool shortage. It is boundary drift.

If I had to compress the entire argument into one sentence, it would be this:

Large Vue projects usually do not become difficult because they need one more library. They become difficult because state mechanisms keep multiplying while state boundaries keep losing clarity.

That is the real subject of this article.

Not whether Pinia is sufficient.
Not whether composables are overused.
Not whether Vue itself is somehow inadequate.

The real problem is more structural than that.

In a large codebase, the usual mechanisms all solve legitimate local problems:

local reactive state,
composables,
provide/inject,
stores,
query cache,
local persistence,
SSR hydration rules.

Any one of those choices can be correct.

And still, taken together, they can produce a state layer that feels progressively less stable.

Not because one piece is obviously wrong, but because the whole system gradually loses shape.

That is what I mean by the scattered version.

Not a broken system. Not an amateur system. Not even an irrational one.

A scattered system is one where:

each local decision can be justified,
each mechanism solves a real problem,
but the overall state architecture becomes harder and harder to explain, modify, and trust.

What Zova/Cabloy tries to offer is not a replacement for Vue, but a more systematic way to organize state on top of Vue:

Bean / Controller defines ownership,
IoC Scope defines how far state is shared,
Model defines a unified state layer,
Resource Owner defines the boundary for resource-level semantics such as queries, schema, permissions, and invalidation.

If the project is small, short-lived, or handled by a very small team, the scattered version may be perfectly adequate.

But once the system becomes long-lived, multi-person, SSR-aware, cache-heavy, and persistence-heavy, the difference between scattered and systematic stops being a matter of taste.

It becomes a question of architecture.

And that leads to the real question underneath the tooling discussion:

Should complex state continue to be held together mainly by team discipline, or should more of it be held together by structure?

The decisive questions sit upstream of tooling

Most state-management discussions begin at the tool layer:

Should we use Pinia?
Should we add Query?
How should we persist local state?
How should we handle SSR hydration?

Those are sensible questions.

But in large systems, they are not the first questions.

The first questions are these:

Ownership — which object actually owns this state?
Sharing boundary — is it local, parent/child shared, app-level, or system-level?
State family — is it server state, in-memory state, local persistence, cookie-backed state, or async persistent state?
Cache semantics — who owns the key, invalidation, and restore rules?
Lifecycle — what survives disposal, refresh, route transitions, and SSR request boundaries?
Resource semantics — is this just a value, or part of a larger resource boundary that also owns schema, permissions, queries, forms, and actions?

When those questions are answered by different local mechanisms, the result is usually familiar:

some state lives in pages,
some lives in composables,
some lives in stores,
some lives in query cache,
some lives in persistence wrappers.

The application still works.

But the architecture becomes progressively harder to narrate.

And once a system becomes hard to narrate, it usually becomes hard to evolve safely.

That is the real failure mode of state management in large projects.

Not that a feature cannot be built.

But that the team gradually loses a clean answer to the most important question:

Why does this state live here, why is this mechanism responsible for it, and where exactly does its boundary end?

Large systems usually do not need more state tools.

They need a stronger organizational model for the tools they already have.

Why large Vue projects drift into the scattered version so easily

Because the road into it is the most natural road available.

A team starts with local state.
Then extracts a composable.
Then uses provide/inject.
Then adds a store.
Then adds Query.
Then adds local persistence.
Then patches SSR behavior.

Every move is locally rational.

That is exactly why the outcome is so common.

The issue is not that teams are making obviously bad decisions.

The issue is that the default growth path is a local-solution path, not a boundary-first path.

And over time, that difference compounds.

The same symptoms begin to appear again and again:

the same kind of state lands in different places on different screens,
refresh rules are hidden inside mutation success handlers,
persistence is treated as an afterthought rather than part of state semantics,
"global state" quietly mixes request-level and long-lived system concerns,
one resource's schema, permissions, forms, queries, and invalidation rules end up split across several layers.

This is the critical distinction:

The scattered version is not wrong because the tools are wrong. It is wrong because each tool solves one slice while the system never grows one stable ownership model.

That creates a very particular form of technical debt.

Not sudden failure.

Not dramatic breakage.

A slower, more corrosive debt: the project becomes increasingly dependent on memory, habit, and tribal knowledge to remain coherent.

At first, that feels like flexibility.

Later, it feels like fog.

What Zova/Cabloy changes is not the reactive core, but the authoring model

The most important thing to understand about Zova/Cabloy is this:

Vue 3 remains the reactive foundation. What changes is the programming model the business layer encounters first.

In mainstream Vue development, the most visible concepts are usually:

setup(),
ref() / reactive(),
computed(),
composables,
provide/inject,
stores.

In Zova, the center of gravity shifts.

The foreground concepts become:

Controller / Bean instances as visible state owners,
__init__ as a lifecycle-aware wiring point,
IoC scopes as the sharing model,
Model as the unified state layer,
Resource Owner as the owner of resource-level frontend semantics.

That changes the first design question.

Instead of asking:

should this go into a store?

You are pushed to ask:

which bean owns this?
which scope should share it?
which model family should represent it?

That is not a cosmetic shift.

It changes where architectural decisions happen.

In the scattered version, state tends to appear first and only later search for a home.

In the systematic version, the home is chosen first, and implementation follows.

That sounds subtle.

In a large system, it is not subtle at all.

Because the hardest thing in a growing codebase is not shipping one more feature.

It is continuing to place boundaries correctly as the system gets more complex.

Layer 1: make ownership explicit

In many Vue projects, the most natural host for state is a local declaration inside setup():

const count = ref(0);
const countLabel = computed(() => `=== ${count.value} ===`);

There is nothing wrong with that pattern.

But at scale, it often produces a predictable drift: state appears as a local variable first, then gradually leaks outward into composables, stores, parent components, and other abstractions.

Zova begins from a different assumption. Visible state typically lives directly on a Controller or Bean instance:

count: number = 0;

protected async __init__() {
  this.countLabel = this.$computed(() => {
    return `=== ${this.count} ===`;
  });
}

increment() {
  this.count++;
}

The important point is not that you wrote less .value.

The important point is this:

the state host becomes a framework-managed instance,
derived state becomes lifecycle-aware wiring on that instance,
behavior and state collapse back under one explicit owner.

That changes how a large codebase is read.

In ordinary Vue code, the reader often asks:

which composable owns this?

In Zova, the reader is more likely to ask:

which Bean or Controller owns this?

That is a healthier question in a large system.

Because large systems rarely suffer from a lack of flexibility.

They suffer from a lack of stable ownership.

And once ownership drifts, scope, persistence, cache identity, SSR behavior, and invalidation tend to drift with it.

Layer 2: make sharing a scope problem instead of a mechanism-switching problem

Large Vue projects also become scattered because sharing is expressed through multiple unrelated mechanisms.

The word "shared" can point to very different strategies:

local component sharing through local state or composables,
parent-child sharing through props/emits or provide/inject,
app-level sharing through a store,
long-lived sharing through module singletons, plugin state, or some implicit global object.

So the system quietly learns a rule like this:

When the sharing boundary changes, the mechanism changes too.

Zova reframes that into one IoC model with multiple scopes:

Sharing range	Common Vue 3 pattern	Zova question framing
component-internal	local state, component-local composables	should this be a `ctx`-scoped Bean?
between-components	props/emits, parent-owned composables, `provide/inject`	should this use hierarchical injection such as `host` / `skipSelf`?
app-global	stores, app-level provided state	should this be an `app`-scoped shared Bean?
system-level	module singletons, long-lived imported state	should this be a `sys`-scoped state that outlives requests?

The value is not just cleaner terminology.

It is a different way of framing the problem:

Do not start with the sharing mechanism. Start with the sharing boundary.

A compact mental model looks like this:

class ControllerPage {
  @Use()
  $$localCounterState: CounterState;

  @Use({ injectionScope: 'host' })
  $$hostCounterState: CounterState;

  @Use({ injectionScope: 'app' })
  $$appCounterState: CounterState;

  @Use({ injectionScope: 'sys' })
  $$sysCounterState: CounterState;
}

The strength of this model is not only uniform syntax.

It is also that:

the sharing boundary becomes explicit,
state does not need to jump between unrelated mechanisms as sharing expands,
app-level and system-level state stop being casually mixed together.

This matters even more in SSR.

Because many teams casually label both of the following things as "global state":

request-level or app-level state — state that should follow an app instance or one SSR request,
system-level state — state that should outlive those requests.

If that distinction is not built into the model, SSR bugs become easy to create and hard to reason about.

Zova moves the difference directly into the architecture through app versus sys.

That is what a systematic model does well:

It turns boundaries that used to live in team memory into explicit structural rules.

Layer 3: Model is not just a request layer, and not just another store

Even teams that use both a store and a query library often unify only part of the state problem.

The usual split is familiar:

stores handle client-shared state,
query handles server-state cache,
localStorage utilities handle persistence,
cookie utilities handle request-related state,
async persistence is wrapped somewhere else.

That is still a scattered model.

Every state family has a tool.

But the state families do not share one coherent owner.

Zova's Model pushes the abstraction one step further.

It does not only represent remote data. It brings multiple state families under one model-state layer:

data — server / query-style state,
mem — in-memory state,
local — localStorage-backed state,
cookie — cookie-backed state,
db — async persistent state.

That changes the conversation in an important way.

Server state, local persistence, and in-memory state no longer need to be treated as unrelated worlds.

They still have different semantics, but they can live under one unified model ownership.

And this is not merely a thin wrapper over other tools.

Zova's Model is built on TanStack Query, but what the business layer sees is a more structured interface:

query keys carry model identity,
mutation keys carry model identity,
invalidation policy can belong to the model,
local / cookie / db state still participates in model-owned keying and restore semantics,
SSR and hydration behavior can follow model rules.

So the accurate description is not "Model is another store."

It is this:

Model is a unified state boundary for query, mutation, persistence, invalidation, restore behavior, and SSR semantics.

That is also why localStorage should not be understood as merely "saving something somewhere."

A more precise description is:

local-storage state is not a separate store; it is model-owned query state with a local-storage persister.

That may sound like a wording change, but it affects the whole architecture:

which model owns the state,
how its key space is isolated,
how restore works,
who owns invalidation,
whether it participates in SSR dehydration and hydration behavior.

In the scattered version, those answers are spread across utilities and conventions.

In the systematic version, they are pulled back into one model boundary.

That is the kind of abstraction large systems actually need.

Layer 4: pull resource semantics back under a Resource Owner

Even teams with both a store and a query layer often continue to fragment at the resource boundary.

Take a typical list / form / detail resource.

The frontend still needs to know all of this:

how the API path is built,
how the list is fetched,
how one row is fetched,
how create / update / delete work,
where schema comes from,
how permissions are checked,
which caches must be invalidated after success,
how the form layer is wired.

At that point, the problem is no longer "a piece of state."

It is a bundle of resource semantics.

This is where ModelResource becomes especially important:

It allows a model to become not just a query wrapper, but the frontend owner of a resource boundary.

That means the model can own:

resource bootstrap,
schema access,
permission access,
form integration,
query state,
mutation state,
cache invalidation policy.

A large amount of logic that would otherwise be scattered across pages, forms, buttons, request wrappers, schema helpers, and permission helpers gets pulled back into one stable boundary.

The shortest way to say it is this:

The page consumes resource semantics. The model owns query semantics.

That matters because it lifts the discussion from "where should this value live?" to "who owns this entire resource-shaped complexity?"

And once that resource boundary is stable, pages, forms, permissions, schema, and cache behavior are much more likely to remain stable together.

That is one of the most valuable properties a large codebase can have:

Not just reusable logic, but reusable boundaries.

One table to summarize the difference

Dimension	Scattered version	Systematic version
State ownership	whoever touches it first tends to host it	ownership is assigned first to Bean / Controller / Model
Sharing model	composables, `provide/inject`, stores grow in parallel	sharing is discussed through IoC scopes
Server data	owned by a separate request or query layer	part of Model's unified state boundary
Local persistence	localStorage / cookie wrappers remain separate utilities	`local` / `cookie` / `db` live inside model-state families
Cache keys	often become team-defined strings	namespaced by model identity and selectors
Invalidation	handled by pages, buttons, and mutation callbacks	owned as model policy
SSR semantics	usually patched through conventions	structured through `app` / `sys` and hydration rules
Reading strategy	find hooks and variables, then infer boundaries	inspect owner, scope, and model first
Complexity control	mostly maintained by team discipline	more of it is maintained by structure

The judgment behind the table is simple:

The scattered version can work, but it manages complexity mainly through discipline. The systematic version moves more of that burden into structure.

Or, more bluntly:

the scattered version is easier to start,
the systematic version is easier to scale.

And large projects are rarely decided by how elegant they felt in week one.

They are decided by whether the architecture is still legible six months later.

Three practical scenarios

1. Page filter state

In the scattered version, page-level filter state often evolves like this:

it starts as a few local refs,
then moves into a composable,
then gets saved to localStorage,
then later moves into a store because another page needs it too.

That path can work.

But after enough steps, the crucial questions become harder to answer:

which page actually owns it?
is it page-local, resource-level, or app-level?
is persistence just a UX convenience, or part of the state semantics?

In the systematic version, the first question is not "should we extract a composable?"

It is:

is this page / controller-local state?
should it instead be mem or local state on a Model?
does it need model identity in its key space?

Answer those questions early, and the state tends to keep a much more stable home.

2. List query and refresh after create

In the scattered version, refreshing a list after creating a record often means:

manually refetching the list,
invalidating queries from the page,
or letting some store action do it as a side effect.

It works.

But the refresh rule ends up distributed across multiple call sites.

In the systematic version, this belongs much more naturally to Model ownership:

the list query belongs to the model,
the create mutation belongs to the model,
the invalidation policy after create belongs to the model too.

The page consumes a resource action instead of coordinating cache semantics itself.

3. Resource forms, permissions, and schema

The scattered version usually loses control not at simple fetching, but at the semantics that accumulate around a resource:

which fields are editable,
which buttons are visible,
where the schema comes from,
which regions refresh after which action.

If those rules are split across pages, forms, buttons, helper utilities, store logic, and query logic, the codebase becomes only locally understandable.

The Resource Owner mindset is different:

pull that semantic bundle back to one stable owner,
let the page consume it,
let the model own it.

That is what effective complex-state management actually looks like.

Across all three scenarios, the same distinction appears again:

The scattered version solves the immediate problem first. The systematic version places the state inside the right boundary first.

The systematic version is not free

This part matters.

A more systematic architecture is not a free lunch.

Its cost includes at least this:

you accept stronger architectural constraints,
you need to learn roles like owner, scope, and model,
you cannot keep treating every piece of state as a local detail that will be sorted out later,
for small projects, short projects, or one-off pages, the structure may feel heavier than necessary.

So the conclusion is definitely not:

every Vue project should be written this way.

The more accurate conclusion is:

When complexity is still low, the scattered version feels flexible. When complexity keeps rising, the systematic version becomes far more stable.

What you save early is abstraction cost.

What you usually pay later is boundary cost.

That is the real trade-off.

The systematic version does not guarantee that day one feels fastest.

It gives you a much better chance that day 180 still feels manageable.

Final judgment: the ceiling is architectural, not just tool-level

If state management is reduced to "which library should we choose," the conversation remains too shallow.

In large frontend systems, the more decisive questions are usually these:

does state have a stable owner?
are sharing boundaries explicit?
is cache identity controlled?
is persistence part of the model's semantics, or merely a patch?
are SSR rules structural, or just conventions?
is resource-level complexity pulled back under one stable owner?

So the conclusion I would draw is this:

The ceiling of state management in a large project is usually not determined by one library. It is determined by whether the architecture forms a coherent state system.

The scattered version can be fast.

The systematic version can be steady.

The former depends more on discipline.

The latter depends more on structure.

That is the real value of Zova/Cabloy in large Vue projects: not one isolated capability, but a more consistent system for the things that drift apart most easily:

ownership,
sharing,
cache semantics,
persistence,
SSR,
resource boundaries.

That is why "Scattered vs Systematic" is more than a catchy title.

It points to the real engineering question underneath the tooling debate:

should complex state continue to be held together mainly by people,
or should more of it be held together by structure?

If I had to compress the whole article into one closing line, it would be this:

Large Vue projects usually do not need more state tools. They need a state architecture capable of organizing the tools they already have.

Why Large Frontend Apps Keep Getting Slower Even After the Usual Optimizations

Uncle Pushui — Tue, 30 Jun 2026 10:02:00 +0000

Large frontend performance is often more of an architecture problem than a bundle problem.

Most large frontend teams are not ignoring performance basics.

They already split bundles, lazy-load routes, compress assets, optimize images, cache requests, and add SSR where it clearly helps.

And yet the app still gets heavier.

A dashboard gets faster, and another one becomes the new bottleneck. A bundle goes down, then creeps back up a few sprints later. Caching improves one flow, while invalidation gets messy somewhere else.

If that sounds familiar, the issue may not be that your team needs one more round of optimization. It may be that the frontend is structurally designed to keep accumulating weight as it grows.

That is the argument of this article.

Key takeaways

weak boundaries tend to produce frontend monolith growth
repeated CRUD and resource page construction creates hidden system weight
query caching works best as infrastructure, not as a team-by-team habit
SSR becomes more useful when it includes admin flows, not just public pages

The real problem is not just slowness. It is slowness that keeps coming back.

A lot of teams approach performance in a familiar loop:

shrink the bundle
optimize the slow screen
cache a few expensive requests
move selected routes to SSR
repeat when the next bottleneck appears

That approach works for a while.

What it does not explain is why large business applications so often slide back into the same state. In many cases, the reason is structural. The architecture keeps creating new weight faster than the team can remove it.

You can usually see that happening through four patterns:

the frontend keeps drifting toward a monolith
similar CRUD and resource pages are rebuilt over and over
query and cache behavior varies from team to team
SSR exists, but only as a special-case feature

When those patterns are present, performance work becomes reactive by default.

1. Weak boundaries quietly turn the frontend into one growing shell

A codebase can look modular and still behave like a monolith.

It may have feature folders, shared utilities, route splitting, and a decent naming convention. But that often amounts to directory modularity, not real architectural separation.

The harder question is whether the system has durable boundaries:

business boundaries
bundle boundaries
runtime boundaries
delivery-target boundaries

Without them, every new feature adds a little more shared dependency surface, a little more startup cost, and a little more cross-cutting complexity. No single change looks fatal. The problem is the accumulation.

That is why large-app performance is often misdiagnosed as “one more bundle problem.” In reality, it is frequently a boundary problem. Once the frontend loses the ability to resist monolith growth, every optimization becomes harder to keep.

2. Rebuilding the same resource surfaces again and again also makes the app heavier

Another source of weight is repetition at the page layer.

Large business systems tend to contain many variations of the same basic surfaces:

list pages
create and edit forms
filters
detail views
row actions
resource-oriented admin flows

When teams hand-build these again and again, the cost is not just duplicated effort. It is also duplicated structure:

more page code
more repeated view logic
more initialization work per screen
more inconsistency across similar resources
more rework when backend fields change

This is where contract-driven UI becomes interesting.

The point is not that everything should be generated. That is rarely the right target. The more practical goal is to let backend contracts shape the routine parts of the frontend, while keeping custom work for the genuinely product-specific pieces.

Done well, that has a few compounding benefits: thinner page layers, less drift between backend and frontend, and fewer repeated decisions around the same CRUD patterns.

At scale, that is not just a DX win. It changes the weight profile of the application.

3. Query caching works best as infrastructure, not as a team habit

A surprising number of “slow frontend” complaints are really data-path problems.

You see them in patterns like these:

too many requests on first entry
unnecessary refetches when returning to a screen
multiple components requesting the same data independently
inconsistent invalidation rules
awkward SSR prefetch and hydration behavior

Small apps can get away with this for a while. Large apps usually cannot.

That is why query caching should be treated as infrastructure. The specific library matters less than the role it plays in the system.

What matters is whether server-data behavior is:

consistent
reusable
centrally modeled
compatible with SSR and hydration
understandable across teams

If caching arrives late, each team tends to wrap it in its own way. Cache keys drift. Invalidation becomes uneven. SSR support is added later and never feels fully integrated.

When query behavior is part of the runtime model, the frontend is much more likely to get shared semantics, predictable reuse, and cleaner transitions between server-rendered and client-resumed states.

In large systems, that kind of coherence matters as much as bundle size.

4. SSR becomes more valuable when it includes admin flows, not just public pages

SSR is still often discussed as a public-web technique:

SEO pages
marketing pages
content pages
landing pages

But some of the heaviest first-load experiences in real applications are internal:

admin dashboards
workbenches
reporting screens
entry pages that need identity, permissions, menus, layout state, and initial data before they become useful

If all of that is handled purely on the client, users often sit through a long startup chain before they see the first meaningful screen.

That is exactly where SSR can help.

But SSR is most effective when it is not bolted on as a special case. It works best when it lines up with the rest of the architecture:

modular frontend boundaries
shared contract surfaces
query and cache infrastructure
coherent hydration paths

That matters not only for public web apps, but also for serious back-office systems where first-use responsiveness shapes the overall feel of the product.

Why Cabloy is a useful case study

Cabloy is interesting here not because it “solves performance automatically,” but because it brings several of these ideas together in one place.

In Cabloy Basic:

Frontend structure is explicitly modular. Zova organizes capabilities through modules and suites instead of treating the UI as one flat application surface.
Backend contracts can shape routine frontend surfaces. DTO, entity, and OpenAPI metadata can feed SDK generation and schema-aware UI helpers for forms, tables, filters, detail views, and actions.
TanStack Query sits in the foundation. Zova’s model-state layer builds on it through framework-native abstractions.
SSR exists for both Admin and Web flavors. That treats first-load quality as a whole-system concern rather than something reserved for public pages.

The takeaway is not that every team should adopt Cabloy. The more portable lesson is that large frontend performance improves when these concerns are treated as design choices early, not cleanup tasks later.

A better question to ask

If your team has already done the obvious optimizations and the app still feels heavy, ask this instead:

Is our architecture structurally designed to keep getting heavier over time?

That question usually reveals more than another isolated bundle audit.

A strong answer tends to include four things:

real modular boundaries
thinner routine UI through shared contracts
query caching as infrastructure
SSR integrated into the system model, including admin flows where it matters

If those pieces are missing, performance wins tend to be temporary. If they are present, the frontend has a much better chance of staying fast as it grows.

That is the real challenge in frontend performance at scale:

not making one page faster today, but building a system that does not keep getting slower by default.

Vite: How to resolve bundle fragmentation?

Uncle Pushui — Mon, 14 Oct 2024 11:12:00 +0000

Preface

When we use Vite for bundle code files, we often encounter this problem: With the development of the business, there are more and more pages, more and more third-party dependencies, and the chunks are getting bigger and bigger. If the pages are imported dynamically, then all the files shared by several pages will be independently bundled to the same chunk, which will create a large number of tiny js chunk files, such as: 1K, 2K, 3K, which significantly increases the resource request of the browser.

Although you can customize the chunks-merging strategy through the rollupOptions.output.manualChunks, the dependencies between the files are intricate. If the chunks-merging configuration is unreasonable, it will cause the initial chunks to be too large, or the circular reference will occur. Therefore, the mental burden is heavy. Is there an automated chunks-merging mechanism to completely solve the problem of bundle fragmentation?

Two potential issues of chunks-merging

As mentioned earlier, there are two potential issues to use the rollupOptions.output.manualChunks custom chunks-merging strategy.

1. Cause the initial chunks to large

As shown in the figure, file A originally only depends on file C, but according to the chunks-merging configuration in the figure, Chunk1 and Chunk2 must be downloaded before using file A. In a complex project, due to the complexity of the dependencies between the files, this dependency will spread quickly with the merger of a large number of small files, resulting in the large size of the initial bundles.

2. Cause circular reference error

As shown in the figure, due to the mutual dependence between the files, Chunk1 and Chunk2 will cause circular dependence error. Then in complex projects, the scenes of mutual dependence between code files are more common.

Solution: modular system

Because the chunks-merging configuration will lead to the above two potential issues, it is often difficult to follow, and it is difficult to have a simple and easy-to-use configuration rules that can be followed. Because the chunks-merging configuration is closely related to the current state of the project. Once the code of the project has changed, the chunks-merging configuration also needs to be changed accordingly.

To solve this problem, I introduced a modular system in the project. That is, the code of the project is split according to business characteristics to form a combination of several modules. Each module can include pages, components, configurations, languages, tools and other resources. Then a module is a natural bundle boundary, and automatically bundled into an independent asynchronous chunk when building, bidding farewell to the hassle of Vite configuration and effectively avoiding the fragmentation of bundles. Especially in large business systems, this advantage is particularly evident. Of course, the use of a modular system is also conducive to code decoupling and facilitating division of labor collaboration.

Since a module is a bundle boundary, we can control the content and quantity of the chunks by controlling the content and quantity of the modules. And we divide the modules based on business characteristics to make the chunks-merging configuration have obvious business significance. Compared with the customization of the rollupOptions.output.manualChunks, it is obviously low mental burden.

Directory Structure

As the project continues to evolve iteratively, the business modules created will also expand. In addition, for some business scenarios, multiple modules are often required to be implemented together. To solve the above problems, We can introduces the concept of suite. In short, a suite is a combination of a group of business modules. In this way, a project is composed of several suites and several modules. Below is the directory structure of a project:

project
├── src
│  ├── module
│  ├── module-vendor
│  ├── suite
│  │  ├── a-demo
│  │  └── a-home
│  │    ├── modules
│  │    │  ├── home-base
│  │    │  ├── home-icon
│  │    │  ├── home-index
│  │    │  └── home-layout
│  └── suite-vendor

Name	Description
src/module	Standalone module (not part of a suite)
src/module-vendor	Standalone module (from third-party)
src/suite	Suite
src/suite-vendor	Suite (from third-party)

Name	Description
a-demo	demo suite: Put the test code into a suite, so that it is convenient to disable at any time
a-home	business suite: including 4 business modules

Chunks-merging effect

Let's take a look at the actual bundle effect:

Taking the module home-base as an example, the left shows the code of the module, and the right shows the chunk size is 12k, and 3K with gzip. To achieve this chunks-merging effect, no configuration is required.

For another example, we can also concentrate the layout components into the module home-layout for management. The module is bundled into an independent chunk, which size is 29K and 6K with gzip.

Source code inside

1. Dynamic import modules

Since the module directory structure of the project is regular, we can extract all the module list before the project startup, and then generate a js file to centrally implement the dynamic import of modules:

const modules = {};
...
modules['home-base'] = { resource: () => import('home-base')};
modules['home-layout'] = { resource: () => import('home-layout')};
...
export const modulesMeta = { modules };

Since all modules are dynamically imported through the import method, it will automatically split into independent chunks when performing Vite building.

2. Chunks-merging Configuration

We also need to customize the chunks-merging configuration through rollupOptions.output.manualChunks to ensure that the code inside the module is uniformly bundled together to avoid fragmented files.

const __ModuleLibs = [
  /src\/module\/([^\/]*?)\//,
  /src\/module-vendor\/([^\/]*?)\//,
  /src\/suite\/.*\/modules\/([^\/]*?)\//,
  /src\/suite-vendor\/.*\/modules\/([^\/]*?)\//,
];

const build = {
  rollupOptions: {
    output: {
      manualChunks: (id) => {
        return customManualChunk(id);
      },
    },
  },
};

function customManualChunk(id: string) {
  for (const moduleLib of __ModuleLibs) {
    const matched = id.match(moduleLib);
    if (matched) return matched[1];
  }
  return null;
}

Each file path is matched with a regular expression. If the matching is successful, use the corresponding module name as chunk name.

Solutions to two potential issues

If the modules are interdependent, there may be two potential issues mentioned above, as shown in the figure:

In order to prevent the occurrence of the two potential issues, we can implement a dynamic loading and resource positioning mechanism. In short, when we access the resources of Module 2 in Module 1, we must first dynamically load module 2, then find the resources of module 2 and return them to the caller.

For example, there is a Vue component Card in module 2, and a page component FirstPage in module 1. We need to use the Card component in the page component FirstPage. Then, we need to do it like this:

// dynamically load module
export async function loadModule(moduleName: string) {
  const moduleRepo = modulesMeta.modules[moduleName];
  return await moduleRepo.resource();
}

// create dynamic component
export function createDynamicComponent(moduleName: string, name: string) {
  return defineAsyncComponent(() => {
    return new Promise((resolve) => {
      // dynamically load module
      loadModule(moduleName).then((moduleResource) => {
        // return the component of module
        resolve(moduleResource.components[name]);
      });
    });
  });
}

const ZCard = createDynamicComponent('Module2', 'Card');

export class RenderFirstPage {
  render() {
    return (
      <div>
        <ZCard />
      </div>
    );
  }
}

Advanced import mechanism

Although using createDynamicComponent can achieve the desired purpose, the code is not concise enough and cannot fully utilize the automatic import mechanism provided by Typescript. We still hope to use the component in the usual way:

import { ZCard } from 'Module2';

export class RenderFirstPage {
  render() {
    return (
      <div>
        <ZCard />
      </div>
    );
  }
}

Such code is in the form of static import, which will cause Module 1 and Module 2 to be strongly dependent on each other. So, is there a way to have the best of both worlds? Yes. We can develop a Babel plug-in to parse the AST syntax tree and automatically change the ZCard import to a dynamic import form. In this way, our code is not only concise and intuitive, but also can implement dynamic import, avoiding the occurrence of two potential issues when bundling. In order to avoid distracting the topic, how to develop the Babel plug-in will not be expanded here. If you are interested, you can directly refer to the source code: babel-plugin-zova-component

Conclusion

This article analyzes the causes of Vite bundle fragmentation and proposes a modular system to simplify the chunks-merging configuration. At the same time, it adopts a dynamic loading mechanism to perfectly avoid the occurrence of two potential issues during bundling.

Of course, there are still many details to consider in order to realize a complete modular system. If you want to experience the out-of-the-box effect, you can visit my open source framework: https://github.com/cabloy/zova. You can contact me on twitter: https://twitter.com/zhennann2024

How to achieve unified management of four types of global state data in Vue3?

Uncle Pushui — Fri, 11 Oct 2024 02:22:00 +0000

Four types of global state data

In actual development, you will encounter four types of global state data: asynchronous data (usually from the server) and synchronous data, while synchronous data is divided into three types: localstorage, cookie, and memory. In the traditional Vue3, different mechanisms are used to handle these state data, while only a unified Model mechanism is needed in Zova

Global State Data	Traditional Vue3	Zova
asynchronous data	Pinia	Model
localstorage	Pinia + Localstorage	Model
cookie	Pinia + Cookie	Model
memory	Pinia	Model

By using the Model mechanism to uniformly manage these global state data, some common system capabilities can be provided, including Memory Optimization, Persistence and SSR Support, etc., thereby standardizing data usage, simplifying code structure, and improving code maintainability

Feature 1. Support for async data and sync data

The base of Zova Model is TanStack Query. TanStack Query provides powerful data acquisition, caching and update capabilities. If you have not used similar data management mechanisms like TanStack Query, it is strongly recommended that you learn about it, and you will definitely be impressed by the thought

The core of TanStack Query is to manage asynchronous data (usually from the server). Zova provides some extension capabilities based on TanStack Query, so as to support the management of synchronous data. In other words, all the features and capabilities described below apply to both asynchronous data and synchronous data

Feature 2. Automatic caching

Locally cache the acquired asynchronous data to avoid repeated acquisition. For synchronous data, read and write operations will be automatically performed on localstorage or cookie

Feature 3. Automatic update

Provide data expiration strategy and automatically update at the right time

Feature 4. Reduce duplicate requests

When accessing data in multiple places in the program at the same time, the server API will only be called once. If it is synchronous data, only one operation will be called for localstorage or cookie

Feature 5. Memory optimization

Although the data managed by Zova Model is in a global state, it does not always occupy memory, but provides a mechanism for memory release and recycling. Specifically, it is to create cache data according to business needs when creating a Vue component instance, release the reference to the cache data when the Vue component instance is unmounted, and if no reference and expiration time reached, the garbage collection mechanism (GC) will be triggered to complete the release of memory, thereby saving memory usage. This has significant benefits for large projects and scenarios where users need to interact with the interface for a long time

Feature 6. Persistence

Local cache can be persisted and can be automatically restored when the page is refreshed to avoid server requests. If it is asynchronous data, it will be automatically persisted to IndexDB to meet the storage needs of large amounts of data. If it is synchronous data, it will be automatically persisted to localstorage or cookie

Memory optimization and persistence work together, and the effect is more obvious for large projects. For example, the data obtained from the server will generate a local cache and automatically persist. When no longer used and expires, the local cache will be automatically destroyed to release memory. When the data is accessed again, the local cache data will be automatically restored from persistence instead of requesting the data from the server again

Feature 7. SSR support

Different types of state data will also have different implementation mechanisms in SSR mode. Zova Model smoothes out the differences in these state data and uses a unified mechanism to hydrate them, making the implementation of SSR more natural and intuitive, significantly reducing the mental burden

Feature 8. Automatic namespace isolation

Zova manages data through Model Bean. The Bean itself has a unique identifier and can be used as a namespace for data, thereby automatically ensuring the uniqueness of the state data naming inside the Bean and avoiding data conflicts

See: Bean Identifier

How to create a model bean

Zova provides a VSCode extension that allows you to easily create a model bean through the context menu

Context Menu - [Module Path]: Zova Create/Bean: Model

Enter the name of model bean according to the prompt, such as todo. The VSCode extension will automatically create the code skeleton of model bean

For example, create a Model Bean todo in the demo-todo module

demo-todo/src/bean/model.todo.ts

import { Model } from 'zova';
import { BeanModelBase } from 'zova-module-a-model';

@Model()
export class ModelTodo extends BeanModelBase {}

Use @Model decorator
Inherited from base class BeanModelBase

Async Data

The core of TanStack Query is to manage server-side data. For simplicity, only the definition and use of the select method are shown here:

For complete code examples, please see: demo-todo

How to define

@Model()
export class ModelTodo {
  select() {
    return this.$useQueryExisting({
      queryKey: ['select'],
      queryFn: async () => {
        return this.scope.service.todo.select();
      },
    });
  }
}

Invoke $useQueryExisting to create a Query object
- Why not use the $useQuery method? Because asynchronous data is generally loaded asynchronously when needed. Therefore, we need to ensure that the same Query object is always returned when the select method is invoked multiple times, so the $useQueryExisting method must be used
Pass in queryKey to ensure the uniqueness of the local cache
Pass in queryFn and call this function at the appropriate time to obtain server data
- service.todo.select: see Api service

How to use

demo-todo/src/page/todo/controller.ts

import { ModelTodo } from '../../bean/model.todo.js';

export class ControllerPageTodo {
  @Use()
  $$modelTodo: ModelTodo;
}

Inject Model Bean instance: $$modelTodo

demo-todo/src/page/todo/render.tsx

export class RenderTodo {
  render() {
    const todos = this.$$modelTodo.select();
    return (
      <div>
        <div>isLoading: {todos.isLoading}</div>
        <div>
          {todos.data?.map(item => {
            return <div>{item.title}</div>;
          })}
        </div>
      </div>
    );
  }
}

Invoke select method to obtain the Query object
- The render method will be executed multiple times, and repeated calls to the select method return the same Query object
Directly use the state and data of the Query object
- See: TanStack Query: Queries

How to support SSR

In SSR mode, we need to use asynchronous data like this: load the state data on the server, and then render it into an HTML string through the render method. The state data and HTML string will be sent to the client at the same time, and the client will still use the same state data when hydrating so as to maintain state consistency

To implement the above logic, only one step is required in Zova Model:

demo-todo/src/page/todo/controller.ts

import { ModelTodo } from '../../bean/model.todo.js';

export class ControllerPageTodo {
  @Use()
  $$modelTodo: ModelTodo;

  protected async __init__() {
    const queryTodos = this.$$modelTodo.select();
    await queryTodos.suspense();
    if (queryTodos.error) throw queryTodos.error;
  }
}

Just invoke suspense in the __init__ method to wait for asynchronous data loading to complete

Sync Data: localstorage

Since the server does not support window.localStorage, the localstorage state data does not participate in the SSR hydration process

The following demonstrates storing user information in localstorage, and the state will be retained when the page is refreshed

How to define

export class ModelUser extends BeanModelBase {
  user?: ServiceUserEntity;

  protected async __init__() {
    this.user = this.$useQueryLocal({
      queryKey: ['user'],
    });
  }
}

Unlike async data definition, sync data is defined directly in the initialization method __init__
Invoke $useQueryLocal to create a Query object
Pass in queryKey to ensure the uniqueness of the local cache

How to use

Read and set data directly like regular variables

const user = this.user;
this.user = newUser;

Sync Data: cookie

Cookies in Request Header are automatically used on the server side, and document.cookie is automatically used on the client side, thus automatically ensuring the consistency of cookie state data during SSR hydration

The following demonstrates storing the user Token in a cookie, and the state will be retained when the page is refreshed. Thus, in SSR mode, both the client and the server can use the same jwt token to access the backend API services

How to define

export class ModelUser extends BeanModelBase {
  token?: string;

  protected async __init__() {
    this.token = this.$useQueryCookie({
      queryKey: ['token'],
    });
  }
}

Unlike async data definition, sync data is defined directly in the initialization method __init__
Invoke $useQueryCookie to create a Query object
Pass in queryKey to ensure the uniqueness of the local cache

How to use

Read and set data directly like regular variables

const token = this.token;
this.token = newToken;

Sync Data: memory

In SSR mode, the global state data defined by the server will be synchronized to the client and automatically complete the hydration

The following demonstrates the memory-based global state data

How to define

zova-ui-quasar/src/suite-vendor/a-quasar/modules/quasar-adapter/src/bean/model.theme.ts

export class ModelTheme extends BeanModelBase {
  cBrand: string;

  protected async __init__() {
    this.cBrand = this.$useQueryMem({
      queryKey: ['cBrand'],
    });
  }
}

Unlike async data definition, sync data is defined directly in the initialization method __init__
Invoke $useQueryMem to create a Query object
Pass in queryKey to ensure the uniqueness of the local cache

How to use

Read and set data directly like regular variables

const cBrand = this.cBrand;
this.cBrand = newValue;

Conclusion

Zova is a vue3 framework with ioc container. It combines the advantages of Vue/React/Angular in code style, while avoiding their shortcomings to make our development experience more elegant and reduce the mental burden. Zova has built-in a lot of interesting features, and the Model mechanism is just one of them.

Zova has been open sourced, welcome to follow and participate: https://github.com/cabloy/zova. You can contact me on twitter: https://twitter.com/zhennann2024

How to provide types for route query parameters in Vue3

Uncle Pushui — Tue, 06 Aug 2024 10:07:40 +0000

Preface

Recently, a Vue3 framework that supports IOC containers was released: Zova. Unlike previous OOP or Class solutions, Zova still uses Setup syntax at the ui interaction side and only introduces IOC containers at the business side. IOC containers are like a key that opens the door to business engineering for us, allowing us to explore more engineering designs and capabilities. A netizen made a very good suggestion: Can you provide some business scenarios to explain what Class can do but Composable can't do, so that it will be more convincing.

First of all, it should be noted that there are actually no business requirements that can be done by this and not by that. Different programming paradigms bring different code styles and different programming experiences, pointing to the evaluation of development efficiency and code maintainability from different paths. Therefore, it ultimately depends on the user's own habits and actual business requirements.

So, here, we will take this topic How to provide types for route query parameters in Vue3 as an example to see what the code styles of Composable and IOC containers are different.

Business requirements

Here is a page component User, which can pass three parameters through Query:

Param	Type	Default
id	number	0
name	string	''
married	boolean	false

Composable: native

1. Open page

const router = useRouter();
router.push({
  path: '/test/demo/user',
  query: {
    id: 1,
    name: 'kevin',
    married: false.toString(),
  },
});

From the perspective of Typescript types, this code has the following two problems:

path: no type constraints and autocompletion. This will have the following three hidden dangers:
1. Can't remember: If the path is long or the words are complex, you can't remember the path and need to find it from the source file
2. Written wrong: If you accidentally write it wrong, there is no prompt, and the error will only be exposed when it is actually run
3. Changed: If the path is changed during subsequent code maintenance, there will be no prompt in the code here, and the error will only be exposed when it is actually run
query: only limited type constraints, inconsistent with business types
1. For example, Boolean type is not supported and must be forced to String type

2. Obtain parameters

const route = useRoute();
const id = parseInt(route.query.id ?? 0);
const name = route.query.name ?? '';
const married = route.query.married === 'true' ? true : false;

Since no type tool is provided, each parameter needs to be processed separately

Composable：useRouteQuery

1. Open page

(Same as above)

2. Obtain parameters

import { useRouteQuery } from '@vueuse/router';

const id = useRouteQuery('id', 0, { transform: Number });
const name = useRouteQuery('name', '');
const married = useRouteQuery('married', 'false', {
  transform: value => {
    return value === 'true' ? true : false;
  },
});

IOC container

1. Define types

import { zz } from 'zova';

export const QuerySchema = zz.object({
+  id: zz.number().default(0),
+  name: zz.string().default(''),
+  married: zz.boolean().default(false),
});

zz is an enhanced version based on zod, which is specially processed for route parameters and supports array and json. For details, see: Zova: zod
You can specify the default value when defining the types

2. Open page

const url = this.$router.resolvePath('/test/demo/user', {
  id: 0,
  name: 'kevin',
  married: false,
});
this.$router.push(url);

The parameters of resolvePath have type constraints and autocompletion, and are consistent with the business types

3. Obtain parameters

const id = this.$query.id;
const name = this.$query.name;
const married = this.$query.married;

Get parameter values directly through this.$query, with precise types and no need to handle default values

Conclusion

From the above example comparison, we can see that the IOC container can separate the definition from the usage, and the scaffolding can be created by tools on the definition side to further simplify the writing of the definition. Since the normative codes such as TS types and default values are completed on the definition side, the code on the usage side is more concise and intuitive. I don't know what your code style is, and if there is a better way to implement it, you are welcome to communicate in the comment area.

References

Come on, provide an ioc container for Vue3 that is comparable to Angular

Uncle Pushui — Thu, 01 Aug 2024 12:11:17 +0000

Why provide an ioc container for Vue3

Vue3 is fully capable of developing large-scale business systems due to its excellent responsive system and convenient functional features. However, we must not only be able to do it, but also do it better. The key to large-scale business systems is decoupling, thereby slowing down the growth of messy code. The ioc container is currently the best decoupling tool. Angular introduced the ioc container from the beginning, so it has always been in a leading position in business engineering, and has been waving to other front-end frameworks: "I'm waiting for you in front, and I hope to see you again in three years." So, I will try to take two steps forward, provide the ioc container in Vue3, and introduce other engineering capabilities based on it to get a new framework: Zova. Is it easy to use? I look forward to your trial and feedback

IOC Containers

There are two types of ioc containers in Zova:

global ioc container(referred to as app container): During system initialization, a unique global bean container will be automatically created. Bean instances created in this container are all singleton mode
component instance ioc container(referred to as ctx container): When creating Vue component instances, the system will create a bean container for each of them. Bean instances created in this container can share data and logic within the scope of the component instance

Bean Class

Zova adopts a modular system, and Bean Classes are provided by different modules. When using the Bean Class inside the same module, you can directly locate it based on Class type. When using cross-module, you can locate it based on Bean identifier instead of Class type/file path, which is conducive to achieving loose coupling between modules

Therefore, Zova provides two types of Bean Classes:

Anonymous bean: The class decorated with @Local is an anonymous bean. This type of bean is only used within the module, there is no naming conflict, and it is easy to define and use
Named bean: Except for @Local, the classes decorated by the other decorator functions are named beans. Zova provides a unified naming convention for such beans, which can avoid naming conflicts and facilitate cross-module usage

Injection mechanism

Zova provides the following injection mechanisms:

1. Bean Class

Use Bean Class to lookup and inject bean instance in the ioc container, and automatically create one if not exist. This mechanism is generally used for same module injection

import { ModelTodo } from '../../bean/model.todo.js';

class ControllerTodo {
  @Use()
  $$modelTodo: ModelTodo;
}

2. Bean identifier

Use Bean identifier to lookup and inject bean instance in the ioc container, and automatically create one if not exist. This mechanism is generally used for cross-module injection and hierarchical injection

import type { ModelTabs } from 'zova-module-a-tabs';

class ControllerLayout {
  @Use('a-tabs.model.tabs')
  $$modelTabs: ModelTabs;
}

Lookup and inject bean instance through a-tabs.model.tabs
Therefore, only the type of ModelTabs needs to be imported to maintain the loose coupling relationship between modules

3. Registration name

Lookup and inject bean instance in the ioc container through the registration name, and return a null value if not exist. This mechanism is generally used for same module injection and hierarchical injection

import type { ModelTodo } from '../../bean/model.todo.js';

class ControllerTodo {
  @Use({ name: '$$modelTodo' })
  $$modelTodo: ModelTodo;
}

Lookup and inject the bean instance by the registration name $$modelTodo. Generally speaking, you should ensure that the bean instance has been injected in the ioc container in advance, otherwise a null value will be returned

4. Variable name

Lookup and inject the bean instance in the ioc container by the variable name, and return a null value if not exist. This mechanism is generally used for same module injection and hierarchical injection

import type { ModelTodo } from '../../bean/model.todo.js';

class ControllerTodo {
  @Use()
  $$modelTodo: ModelTodo;
}

Lookup and inject the bean instance by the variable name $$modelTodo. Generally speaking, you should ensure that the Bean instance has been injected in the ioc container in advance, otherwise a null value will be returned

Injection scope

The default injection scope of anonymous bean is ctx, and the default injection scope of named bean can be specified when defining it. Different scenes have different default injection scopes. In addition, when injecting, you can also override the default injection scope through the injectionScope option in @Use

Zova provides the following injection scopes: app/ctx/new/host/skipSelf

1. app

If the injection scope is app, then inject the bean instance in the global ioc container to achieve the singleton effect

// in module: test-module1
@Store()
class StoreCounter {}

// in module: test-module2
import type { StoreCounter } from 'zova-module-test-module1';

class Test {
  @Use('test-module1.store.counter')
  $$storeCounter: StoreCounter;
}

The injection scope of Store is app by default, so the bean instance will be lookuped and injected in the global ioc container through the bean identifier test-module1.store.counter

2. ctx

If the injection scope is ctx, then inject the bean instance into the ioc container of the current component instance

// in module: a-tabs
@Model()
class ModelTabs {}

// in module: test-module2
import type { ModelTabs } from 'zova-module-a-tabs';

class ControllerLayout {
  @Use('a-tabs.model.tabs')
  $$modelTabs: ModelTabs;
}

The injection scope of Model is ctx by default, so the bean instance will be lookuped and injected in the ioc container of the current component instance through the bean identifier a-tabs.model.tabs

3. new

If the injection scope is new, then directly create a new bean instance

// in module: a-tabs
@Model()
class ModelTabs {}

// in module: test-module2
import type { ModelTabs } from 'zova-module-a-tabs';

class ControllerLayout {
  @Use({ beanFullName: 'a-tabs.model.tabs', injectionScope: 'new' })
  $$modelTabs: ModelTabs;
}

Since the injectionScope option is specified as new, a new bean instance will be directly created through the bean identifier a-tabs.model.tabs

Hierarchical injection

Injection scope supports not only app/ctx/new, but also host/skipSelf which is called hierarchical injection

4. host

If the injection scope is host, the bean instance will be lookuped in the ioc container of the current component instance and all parent containers in turn. If it does not exist, a null value is returned

// in parent component
import type { ModelTabs } from 'zova-module-a-tabs';

class Parent {
  @Use('a-tabs.model.tabs')
  $$modelTabs: ModelTabs;
}

// in child component
import type { ModelTabs } from 'zova-module-a-tabs';

class Child {
  @Use({ injectionScope: 'host' })
  $$modelTabs: ModelTabs;
}

Since the parent component has already injected the ModelTabs bean instance, the child component can directly lookup and inject it
Hierarchical injection also supports all injection mechanisms: Bean Class/Bean identifier/Registration name/Variable name

5. skipSelf

If the injection scope is skipSelf, then lookup the bean instance in all parent containers in turn. If it does not exist, a null value is returned

Github: https://github.com/cabloy/zova
Demo: https://zova.js.org/zova-demo/
Docs: https://zova.js.org/guide/essentials/ioc/introduction.html

DEV Community: Uncle Pushui

Why Frontends Still Need Wrapping After Hooks

Hooks are for reusing internal logic

Start with React: what does an autofocus HOC solve?

The decision test: who owns this rule?

Zova Behavior: attach a rule to the render target

Not only props: wrapping rendered output

Which reuse mechanism should you choose?

Conclusion

Further Reading

Cabloy Form Layout: Organize Complex Forms in DTOs with Tabs, Groups, and Sections

What Form Layout Can Do

Example: Structuring the Student Form

1. tabs and tab: Split the Form by Business Area

2. group: Give Related Fields a Clear Context

3. section: Control Responsive Columns

4. field: Reference Fields Already Defined in the DTO Schema

Choosing the Right Node

One Easy-to-Miss Detail

Summary

Further Reading

How to Bridge Login State Across SSR and CSR: Next.js, Nuxt, and Cabloy Compared

Start with three minimal implementations

Next.js App Router: a Server Component passes a safe DTO explicitly

Nuxt: a server session endpoint plus a useFetch payload

Cabloy: server mem, client local, bridged by the Model Query Cache

What each implementation is actually solving

Next.js: the Server Component is the start of the bridge

Nuxt: keyed async data bridges the SSR payload

Cabloy: Model-owned Query Cache identity is the bridge

One table for the three bridge designs

The real security boundary: client login state improves UX only

1. An HttpOnly cookie is not client state

2. A client route guard is a UX guard, not an authorization point

3. A smaller DTO is both safer and more stable

4. Stale display state is normal

Why Cabloy's bridge deserves separate attention

Common mistakes and better formulations

When each structure fits

Choose an explicit Next.js DTO bridge

Choose a keyed Nuxt useFetch bridge

Use Cabloy's ModelPassport bridge

References and source material

Next.js

Nuxt

Cabloy

How to Manage Complex State in Large Vue Projects: "Scattered" vs "Systematic"

The problem is not tool shortage. It is boundary drift.

The decisive questions sit upstream of tooling

Why large Vue projects drift into the scattered version so easily

What Zova/Cabloy changes is not the reactive core, but the authoring model

Layer 1: make ownership explicit

Layer 2: make sharing a scope problem instead of a mechanism-switching problem

Layer 3: Model is not just a request layer, and not just another store

Layer 4: pull resource semantics back under a Resource Owner

One table to summarize the difference

Three practical scenarios

1. Page filter state

2. List query and refresh after create

3. Resource forms, permissions, and schema

The systematic version is not free

Final judgment: the ceiling is architectural, not just tool-level

Further reading

Why Large Frontend Apps Keep Getting Slower Even After the Usual Optimizations

Key takeaways

The real problem is not just slowness. It is slowness that keeps coming back.

1. Weak boundaries quietly turn the frontend into one growing shell

2. Rebuilding the same resource surfaces again and again also makes the app heavier

3. Query caching works best as infrastructure, not as a team habit

4. SSR becomes more valuable when it includes admin flows, not just public pages

Why Cabloy is a useful case study

A better question to ask

Vite: How to resolve bundle fragmentation?

Preface

Two potential issues of chunks-merging

1. Cause the initial chunks to large

2. Cause circular reference error

Solution: modular system

Directory Structure

Chunks-merging effect

1. `tabs` and `tab`: Split the Form by Business Area

2. `group`: Give Related Fields a Clear Context

3. `section`: Control Responsive Columns

4. `field`: Reference Fields Already Defined in the DTO Schema

Nuxt: a server session endpoint plus a `useFetch` payload

Cabloy: server `mem`, client `local`, bridged by the Model Query Cache

1. An `HttpOnly` cookie is not client state

Choose a keyed Nuxt `useFetch` bridge

Use Cabloy's `ModelPassport` bridge