Auto cast numeric parameters as integers about wouter

[Paratron]

Usually, IDs are strings, not integers. What you basically demand is, that because you chose to use numeric IDs, the router should handle the conversion for you.

URL parameters are automatically extracted parts of an URL - which is a string. The router should not change that and make any assumptions about your code. The next project breaks because of that change, because they assumed to receive strings instead of numbers.

I would suggest to leave the mechanic as-is and do any conversion on your side; if its even needed.

[molefrog]

I agree with @Paratron, if we decide to convert these parameters automatically, this might create a non-obvious behaviour, when for example the parameter was intended to be a string, but in some rare cases it will be converted to integer.

There was a similar thread in React Router and seems like they have decided to avoid this possible complexity remix-run/react-router#6097. Ideally this can be solved with types, by IMO the design of the library becomes too overloaded.

Even in Rails which was designed to be intuitive and convention-based they don't provide an automatic conversion. What they do instead is following:

def show
  user_id = params[:id] # this is a string

  # but this works fine, since ActiveRecord#find accepts both strings and integers
  user = User.find(user_id)
end

@haggen But if you still want to have this in your project really bad I would suggest overriding a default matcher function like this:

import { Route } from "wouter";
import makeMatcher from "wouter/matcher";

const autoCastIntegers = (objectOrNull) => {
   ...
}

const matcherWithTransformedParams = (transformFn) => {
  const originalMatcher = makeMatcher();

  return (pattern, path) => {
    const [match, params] = originalMatcher(pattern, path);
    return [match, transformFn(params)]
  }
}

<Router matcher={matcherWithTransformedParams(autoCastIntegers)}>
  ...
</Router>

(haven't tested the code)

Thanks for suggesting this feature, but we are likely not going to implement this. Closing the issue.