Location>code7788 >text

How to annotate types for routing Query parameters in Vue3

Popularity：432 ℃/2024-08-05 22:50:32

preamble

A Vue3 framework with support for IOC containers was recently released:Zova. Unlike previous OOP or Class solutions, Zova still uses Setup syntax at the interface interaction level and introduces IOC containers only at the business level.IOC containers are like a key that opens the door to business engineering, allowing us to explore more engineering aspects of design and capabilities.There is a very good suggestion: can you provide some business scenarios that show what Class can do but Composable can't, so that it's more convincing.

First of all, let's make it clear that there are really no business requirements where this can be done and that can't be done. Different programming paradigms lead to different code styles, different programming experiences, and different paths to evaluation of development efficiency and code maintainability. Therefore, it is ultimately based on the user's own preferences and actual business needs.

So, here we are on this topicHow to Label Types for Route Query ParametersAs an example, let's see how the code styles of Composable and IOC containers really differ.

Statement of Requirements

Here is a page component, User, which can be passed three parameters via Query:

parameter name typology default value
id number 0
name string ''
married boolean false

Composable: Native

1. Access page

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

From a Typescript type perspective, this code has the following two problems:

  1. path: no type constraints or smart hints. This can have the following three pitfalls:
    1. can't remember: If the path is long or the word is complex, you can't remember the path and need to look it up in the source file.
    2. It's a mistake.: If you accidentally make a mistake, there is no hint, and the error is only exposed when you actually run the program.
    3. It's been changed.: If the path is changed during subsequent maintenance of the code, the code here is also not alerted, and the error is only exposed when it is actually run.
  2. query: only limited type constraints, not consistent with business types
    1. For example, the Boolean type is not supported and must be forcibly converted to a String type

2. Access to parameters

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

Since no type tools are provided, each parameter needs to be handled individually

Composable：useRouteQuery

1. Access page

(ibid.)

2. Access to 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. Defining types

import { zz } from 'zova';

export const QuerySchema = ({
+  id: ().default(0),
+  name: ().default(''),
+  married: ().default(false),
});
  • zz is done on the basis of zod enhanced version, especially for the routing parameters to do the processing, support array arrays and json objects, see:Zova: zod
  • Default values can be specified while defining types

2. Access page

const url = this.$('/test/demo/user', {
  id: 0,
  name: 'kevin',
  married: false,
});
this.$(url);
  • Parameters to resolvePath are type-constrained and smart-alerted, and aligned with business types

3. Access to parameters

const id = this.$;
const name = this.$;
const married = this.$;
  • Directly throughthis.$queryGet parameter values with explicit types and no need to deal with default values

summarize

As you can see from the example comparison above, using IOC containers, it is possible to implement thedefinetogether withutilizationof separation, anddefineSide can be further simplified by tools to create scaffoldingdefineThe writing of the Since normative code such as TS types and default values are in thedefineside is completed, then theutilizationThe side code is much more clean and intuitive. I don't know what your code style preference is and if there is a better way to express it, feel free to share it in the comments section.

bibliography

  • VueUse: useRouteQuery
  • Zova: Routing Query
<Previous Next>