Parse param in matcher

[olehmisar]

Describe the problem

I want to have a number in my route param. So, I created a matcher

Filename: src/params/number.ts

export function match(value): boolean {
  return Number.isFinite(Number(value));
}

and a page

Filename: src/[a=number]/+page.ts

export function load({ params }) {
  return {
    a: params.a, // type: string
  };
}

params.a is still inferred as a string but not a number. So, I have to convert it to a number once more, which is repetitive and error-prone(e.g., if I forget to add =number during a refactoring)

  return {
    a: Number(params.a),
  };

Describe the proposed solution

I propose to change match(value): boolean to match<T>(value): T, so it is possible to return any type from match and it will be correctly inferred in load functions.

Filename: src/params/number.ts

export function match(value): number {
  const parsed = Number(value);
  if (!Number.isFinite(parsed)) {
    // throw an error to indicate that value is invalid
    throw new Error("not a number");
  }
  return parsed; // type: number
}

Filename: src/[a=number]/+page.ts

export function load({ params }) {
  return {
    a: params.a, // type: number
  };
}

This would also make it possible to integrate with zod:

Filename: src/params/number.ts

export const match = z.number().parse

Since, this is a non-backwards compatible change, it can be a proposal for sveltekit 2 or the name of the matcher may be changed to something like parse or matchParse etc.

Alternatives considered

-

Importance

would make my life easier

Additional Information

keywords: match, parse, route param, zod

[jhwz]

This makes sense to me! Always better to prefer parsing over validating

[pkb-pmj]

I remember something similar being proposed when I searched for it some time ago... yeah, here: #8137
And now I remember I even started implementing it and it worked 🤔 maybe I should go back to it

Also, parsing is even better, because it works not only with strings and string enums, but with any type.

[adiguba]

I like this proposition, but I think that the non-backwards compatible change is a problem.

I had considered in #11654 a specific return-type that would maintain compatibility, but now I think it would be even better to use 2 distinct functions.

Ex, currently ParamMatcher is defined like this :

export type ParamMatcher = (param: string) => boolean;

We could have another function's type for parsing :

export type ParamParser<T> = (param: string) => T;

And the params file must contain at least one of these functions.

Some examples :

=> If we only define match it's just working like now and the type of the param's value will be string.

import type { ParamMatcher } from '@sveltejs/kit';

export const match: ParamMatcher = (param) => {
	return /^\d+$/.test(param);
};

=> If we define both functions, the type of the param's value will be determined according to the function parse(), used for converting the value :

import type { ParamMatcher, ParamParser } from '@sveltejs/kit';

export const match: ParamMatcher = (param) => {
	return /^\d+$/.test(param);
};

export const parse: ParamParser<number> = (param) => {
	return +param;
};

=> If we only use the parse function, it will determine the type and the match (param will not match if the function throw an error) :

import { z } from 'zod';
import type { ParamParser } from '@sveltejs/kit';

export const parse: ParamParser<number> = z.coerce.number().int().parse;

Rules :

• If match() is not defined, it will be equivalent to ()=>true.
• If parse() is not defined, it will be equivalent to (param)=>param
• If parse() throw an error, the value will not match.