[Exploration] Switch expression

[aleclarson]

It can be useful to have a utility that acts like switch but can be used in an expression. This thread is exploring the possible APIs for such a task. Others are encouraged to pitch their own ideas.

My idea: match()

Pass an input value first, followed by an object whose keys are matched against the input value. If a matching key is found, that key's value is returned. If no match is found, and the object has a default property, its value will be returned. If still no match is found, return undefined.

type Match<
  TOutputs extends object,
  TInputKey extends PropertyKey,
> = TInputKey extends any
  ? keyof TOutputs extends infer TOutputKey extends keyof TOutputs
    ? TOutputKey extends TInputKey
      ? TOutputs[TOutputKey]
      : TOutputs extends { default: infer TDefault }
        ? TDefault
        : undefined
    : never
  : never

function match<const TOutputs extends object, TInputKey extends PropertyKey>(
  input: TInputKey,
  outputs: TOutputs,
): Match<TOutputs, TInputKey> {
  return (
    input in outputs
      ? outputs[input as unknown as keyof TOutputs]
      : 'default' in outputs
        ? outputs.default
        : undefined
  ) as any
}

Example usage

declare const environment: string

const config = match(environment, {
  production: { apiUrl: 'https://example.com', debug: false },
  staging: { apiUrl: 'https://staging.example.com', debug: true },
  default: { apiUrl: 'https://dev.example.com', debug: true },
})

// If we assume `environment` was "staging":
config // => { apiUrl: 'https://staging.example.com', debug: true }

If you tried to do similar without match, you might try:

const environment: string = 'staging'
const config = {
  production: { apiUrl: 'https://example.com', debug: false },
  staging: { apiUrl: 'https://staging.example.com', debug: true },
}[environment] ?? { apiUrl: 'https://dev.example.com', debug: true }

…which might be “good enough”. Having the “input” come after the named outputs and before the default output is a bit jarring, though.

Here's the equivalent ternary expression (formatted with Biome):

const config =
  environment === 'production'
    ? { apiUrl: 'https://example.com', debug: false }
    : environment === 'staging'
      ? { apiUrl: 'https://staging.example.com', debug: true }
      : { apiUrl: 'https://dev.example.com', debug: true } 

Imagine the objects having more properties, thus needing to be split into multiple lines. It quickly becomes an unpleasant DX.

[Minhir]

In current proposal, default is a reserved word (think about situation when I have environment = "default" but it's not a default 🥲 ). To avoid such magic, we can accept 3d argument:

const config = match(environment, {
  production: { apiUrl: 'https://example.com', debug: false },
  staging: { apiUrl: 'https://staging.example.com', debug: true },
}, { apiUrl: 'https://dev.example.com', debug: true })

Another concern I have is that people could start to use it inside React components, e.g:

const MyComponent = (props) => {
  const styles = match(props.status, {
    success: { color: "green" },
    error: { color: "red" },
  }, {})

  return <Icon styles={styles} />
}

In such case, styles object will be new for each render even if its content supposed to be static. We can think about one time matcher initialization:

const styleMatcher = createMatcher({
    success: { color: "green" },
    error: { color: "red" },
  }, {});

const style = styleMatcher(status);

P.S.
There is a great lib https://github.com/gvergnaud/ts-pattern. But I think it's too much sugar for radashi. We can provide a very thin wrapper around a static record approach as in @aleclarson example.

[aleclarson]

Reserved default concerns

It's rare enough for the matched value to be "default" that I don't know if it matters much. In those rare cases where it does matter, you can work around it with a ternary check:

match(value === "default" ? "production" : value, {…})

Also, in cases where you're using "default" as a valid value, you likely want the default value anyway, so it wouldn't be a problem.

Currying API

Instead of providing a match-specific currying overload, we could introduce a partialRight function:

import { match, partialRight } from 'radashi'

const getStyleForStatus = partialRight(match, {
  success: { color: "green" },
  error: { color: "red" },
})

// elsewhere…
const style = getStyleForStatus(status)

edit: Ah, this might prove to be problematic since “generic type currying” is not a thing in TypeScript currently, and match is generic. But we could still add partialRight in addition to a type-safe matcher function that's implemented with partialRight(match, …).