DEV Community: Uncle Pushui

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