Way to handle optional fields in typescript?

[muradm]

(duck typing)

type Data = {
  firstname: string
  lastname?: string
  settings?: {
    theme: 'dark' | 'light'
  }
}

function NamePart({ lens }: { lens: Lens<string> }) {
  return lens.interop((control, name) => (
    <Controller {...{ control, name }}  render={({ field }) => <TextField {...field} />}   />
  )
}

function OptionalNamePart({ lens }: { lens: Lens<string | undefined> }) {
  return lens.interop((control, name) => (
    <Controller
      {...{ control, name }}
      render={({ field: { value, onChange, ...field } }) => (
        <TextField {...field} value={value ?? ''} onChange=((e) => {
         const v = e.target.value
         onChange(isEmpty(v) ? undefined : v)
        }) />
      )}
    />
  )
}

function Fullname({ lens }: { lens: Lens<{ firstname: string, lastname?: string }> }) {
  return (
    <>
      {/* works */}
      <NamePart lens={lens.focus('firstname')} />
      {/* works */}
      <OptionalNamePart lens={lens.focus('lastname')} />
      {/* 1. type does not match */}
      <OptionalNamePart lens={lens.focus('firstname')} />
    </>
  )
}

function Settings({ lens }: { lens: Lens<NonNullabel<Data['settings']>> }) {
  return  <></> // ... omitted
}

function Form() {
   const { control } = useForm<Data>()
   const lens = useLens({ control })
   return (
     <>
       <Fullname lens={lens.reflect(l) => ({
         firstname: l.focus('firstname'),
         lastname: l.focus('lastname'),
       })} />
       {/*  2. This results in: `Lens<undefined> | Lens<NonNullable<Data['settings']>> ` which is unassignable/unassertable  */}
       <Settings lens={lens.focus('settings')} />
     </>
   )
}

[aspirisen]

Yes, working with nullable fields doesn't work well right now, I will take a look on this problem

[github-actions]

🎉 This issue has been resolved in version 0.7.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[valerii15298]

Hello @aspirisen and @muradm

I stumbled on this issue from another problem where types of nullable fields are omitted which causes a problem when working with nullable fields.

And wanna say that behavior with this code from @muradm example:

{/* 1. type does not match */}
 <OptionalNamePart lens={lens.focus('firstname')} />

when type Type 'Lens<string>' is not assignable to type 'Lens<string | undefined>'. is fully correct and that is how it should be. And by allowing such assignment in next version of hookform/lenses we introduced a tricky bug with runtime errors while typescript will tell us that everything is okay.

Consider this code:

import type { Lens } from "@hookform/lenses";
import { useLens } from "@hookform/lenses";
import { useController, useForm } from "react-hook-form";

interface Data {
  firstname: string;
}

function OptionalNamePart({ lens }: { lens: Lens<string | undefined> }) {
  const controller = useController(lens.interop());
  return (
    <button onClick={() => controller.field.onChange(undefined)}>
      Set Undefined
    </button>
  );
}

function Form() {
  const { control } = useForm<Data>({ defaultValues: { firstname: "John" } });
  const lens = useLens({ control });
  const { field } = useController({ control, name: "firstname" });
  return (
    <>
      <OptionalNamePart lens={lens.focus("firstname")} />
      Length of the first name is: {field.value.length}
    </>
  );
}

Which would show typescript error in compilation step in version 0.6.0 but with latest version it will crush on production while not showing any typescript compilation errors.

PR #15 introduced this kind of bug and made usage of lenses runtime unsafe.
FYI: @bluebill1049

Would you guys be open to considering fixing this kind issue?

[aspirisen]

The ideal variant of lenses behavior is to follow normal object flow. In typescript the following code is correct:

function test(props: { data: { a?: string | undefined } }) { }

function wrapper(props: { data: { a: string } }) {
    test({ data: { a: props.data.a } })
}

And lenses should follow the same behavior, but it is kind of hard to achieve, so that's why null and undefined are excluded, to just allow such kind of lenses pass to other components

[aspirisen]

Actually, after some thinking the core issue looks like that:

If it is a value then you can pass more narrow type to wider type:

interface A {
    value: 'a' | 'b' | 'c'
}

function test(props: A) { }

function wrapper(data: "a" | 'b') {
    test({ value: data }) // All good
}

But if you have i.e. and onChange function then this rule doesn't work

interface A {
    onChange: (value: 'a' | 'b' | 'c') => void
}

function test(props: A) { }

function wrapper(onChange: (data: 'a' | 'b') => void) {
    test({ onChange }) // Error: Type '"c"' is not assignable to type '"a" | "b"'.
}

And this seems logical, because inside test function you can pass c and this is not expected in the passed callback.

In some way Lenses combine both value and onChange, and it looks like they should work like in the last variant.

So the question is - how Lenses should behave, like a property or like a function?

[aspirisen]

@muradm I've created an issue describing the original problem #38
I've added a defined method to lenses for such case, could you please take a look https://www.npmjs.com/package/@hookform/lenses/v/0.0.0-canary-35-20250805-090b3f5?activeTab=readme