[discussion] getters and setters

[david-morris]

Getters and setters aren't just convenient. They're necessary for operations like "check all."

I'm not going to be able to really use Lenses and their ability to encapsulate complexity of my forms without that ability.

Is there a path to being able to support this? Without this, I can't actually adopt lenses because I'd need to additionally add all the complexity of non-lens logic wherever I have a requirement like "check all."

[aspirisen]

Explanation is here https://github.com/react-hook-form/lenses?tab=readme-ov-file#no-setters-and-getters
In short - adding setters and getters will lead of unexpected and tricky bugs because of non-reactive nature of react-hook-form

Also, you can take a look on react-hook-form/react-hook-form#12284 (comment)

The original lenses approach had mutation and reading methods react-hook-form/react-hook-form#9289 and I used that implementation in my previous app and we had a bunch of issue when some value was not reactivly updated or just stuck

That will bring even more problems when react-compiler will be widely adopted

[david-morris]

The reactivity is the problem for some uses.

Such as, making a "check all" button. If you disallow getters and setters, a "check all" button needs reactive access to all of the buttons that it checks and unchecks. That means it reads all of the values whenever any of them changes. That means that checking/unchecking an individual button gets slower the more checkboxes exist in the all-checkable group. In my application, that became unacceptable.

I do understand that getValues and setValue and other similar things belong only in callbacks. But they are needed for using lenses in forms that have become complicated due to changing and nontrivial design requirements.

And you might be thinking that I forgot about handling the change that a "check all" button should have when all checkboxes are checked. But I actually used CSS instead, because this form really does need optimization.

And if I can't optimize forms that need it which are using lenses, I can't adopt lenses for my forms.

I see non-reactive access and mutation as a needed escape hatch when building forms that might need to scale. And if the form definitely doesn't need to scale, why am I adding abstractions?

By the way, I don't think it needs to be shoehorned in to the control. My ideal solution would be to add getValues and setValue methods to the Lens itself, but if there was e.g. a hook where you either use the ambient form context or an explicitly passed useForm return to get getValues and setValue, on the condition that this is the same useForm return that was used to create the Lens.

[wyozi]

Agree that in practice using lenses with maximum flexibility requires mutation (and sometimes getter) methods. I don't mind requiring custom lens extension to have support for those, but what bothers me is that there is no standard way of implementing a setter. Instead, it requires everyone to individually stab at RHF internals to create a half-assed implementation that breaks in many situations.

I wish that the lenses library would at least come with standardized methods for getters and setters that could be utilized by custom lens implementations and would handle all internal complications with field arrays and what not.

[ap0nia]

When I needed to introspect or edit values from the original form, I used useWatch or useController, the latter of which has the field.onChange callback function that can edit the field in the original form. It accepts either an Event or the actual value, which was convenient for usage in components that may or may not have HTML inputs.

If I'm OK with creating a separate component to scope the reactivity, then I might do something like the following.

function FormButton({ lens }: { lens: Lens<{ a: boolean, c: boolean }> }) {
  // If only the current value is needed, I would only use useWatch
  const watch = useWatch(lens.interop())

  const checked = watch.a && watch.b && watch.c

  // If setting the value is required too, then controller.field.value could be used instead of useWatch
  const controller = useController(lens.interop())

  const toggle = () => {
    controller.field.onChange({ a: !checked, b: !checked})
  }

  return (<button onClick={toggle}>Check all</button>)
}

function MyForm() {
  const { control } = useForm({
    values: {
      a: true,
      b: false,
      c: true,
    }
  });

  const lens = useLens({ control })

  return (
    <form>
      {/* Reflecting may not be necessary, just an example of changing lens from parent to child.*/}
      <FormButton lens={lens.reflect((_lens, dict) => ({ a: dict.a, b: dict.b }))} />
    </form>
  )
}

If I was only introspecting the value and I wanted to create scoped reactivity without another component, I could nest the contents within a Controller.

function MyForm() {
  const { control } = useForm();

  const lens = useLens({ control })

  return (
    <form>
      <Controller
        {...lens.focus('a').interop()}
        render={({ field }) => {
          return <div>CURRENT VALUE: {field.value}</div>
        }}
      />
    </form>
  )
}

Feel free to let me know if any of these examples were relevant or helpful at all :^)