Form.Checkbox onChange provides weird value

[maxfahl]

Description

I have a very peculiar issue with the Form.Checkbox component. The onChange handler gets a value of another component passed as its newValue parameter. The value given here is what I've entered into a Form.TextArea (with id "preCommand") component. The value that gets passed is not even a boolean, but a string. The checkbox has a unique id (and key for that matter). I've even removed both the defaultValue and value props from the component. I have no idea of how this value gets there, at all, and have been scratching my head for three days trying to debug this. I've come to the conclusion that this must be a bug in the API with some state being confused somehow.

Raycast version: 1.34.1
@Raycast/api version: 1.34.1

Steps To Reproduce

1. git clone -b rsync-commands-before-after [email protected]:maxfahl/raycast-extensions.git
2. cd raycast-extensions/extensions/rsync-commands
3. npm install
4. npm run dev
5. Run Rsync Commands in Raycast
6. Create new entry
7. Enter details into the following fields
   • Name
   • Source > Path
   • Destination > Path
   • Pre Command (at the bottom)
8. Save the entry
9. Edit saved entry
10. Check the console for onChange value: PRE_COMMAND_VALUE

The weird action is going on inside of src/components/entry-option-form-fields.tsx, in the onChange handler of the Form.Checkbox component.

The current behavior

Value from a different field gets passed to the onChange handler of a Form.Checkbox

The expected behavior

I don't believe the onChange handler should fire at all in this case. And even if there was a defaultValue assigned to the component, the onChange handler shouln't be called with this value either, since it's the defaultValue. If I give a defaultValue of false, every EntryOptionFormFields components onChange will be called with a value of false.

[mattisssa]

I don't believe the onChange handler should fire at all in this case. And even if there was a defaultValue assigned to the component, the onChange handler shouldn't be called with this value either, since it's the defaultValue. If I give a defaultValue of false, every EntryOptionFormFields component onChange will be called with a value of false.

Since the initial value for the checkbox is anyway false, so, I don't see a reason to provide a false defaultValue for the case.

To make callbacks work more predictable we made it all work consistently. Some items can be updated initially on the native side. For example, the dropdown preselects the first available item. Or if an item has storeValue then the callback should be triggered with this value. And assuming all these cases would probably be hard to remember in what case the callback will be triggered. That's why we made an initial callback if any value/defaultValue/storeValue has been provided.

---

What about issue you mentioned, @sxn could you please take a look at that?

[maxfahl]

Hey @mattisssa. What you say is true. My issue is that I don't use value, defaultValue or storeValue, and the value I get for onChange comes from a completely different field in my form. They have unique keys and id's. Very strange.

[mattisssa]

Ah, alright, that we will have a look at 👍

[sxn]

hey @maxfahl - thanks for the report! You're right: in some cases, the wrong input's value can be sent to another one's onChange handler.
To work around this until we ship a fix, you could update the extension to not dynamically insert/remove form inputs; that is, replace

{visibleOptions.map(option => (
  <EntryOptionFormFields
    key={option.name}
    option={entry.options[option.name] ?? createEntryOption(option)}
    description={option.description}
    onChange={onOptionChange}
  />
))}

with

{rsyncOptions.map(option => (
  <EntryOptionFormFields
    key={option.name}
    option={entry.options[option.name] ?? createEntryOption(option)}
    description={option.description}
    onChange={onOptionChange}
  />
))}

A bit less convenient, but should unblock you in the mean time. 😓

[maxfahl]

Thank you @sxn! You mean removing the option filtering? Yes I will try that for now, looking forward to the fix!

[sxn]

You mean removing the option filtering?

Yup, for now at least. The issue's been fixed internally, so you should be able to add the filtering back after next release. 😉

Thanks again for the thorough report!

[maxfahl]

Sounds good, you're welcome. Thanks for good support, as usual 🤩