Props property value not changing

[kee-oth]

Hi!

I'm having trouble with the tracking/updating concepts.

I have a component that isn't updating based on props, even though props does change.

The component:

const defaultProps = {
  className: '',
  disabled: false,
  errorMessage: '',
  onChange: () => { console.log("It's always this onChange function")},
  label: '',
  name: '',
  placeholder: '',
  value: '',
};

const FieldText = (props) => {
  props = mergeProps(defaultProps, props);
  const errorId = nanoid();
  
  createEffect(() => {
    console.log('props', props.onChange); // This actually ends up being the correct, intended function
  })

  return (
    <>
      <label
        className='label'
        htmlFor={props.name}
      >
        {props.label}
      </label>
      <input
        aria-disabled={props.disabled}
        aria-describedby={errorId}
        className={cx(style.root, props.className)}
        disabled={props.disabled}
        name={props.name}
        onInput={props.onChange} // Why doesn't this change?
        placeholder={props.placeholder}
        type='text'
        value={props.value}
      />
      <p
        className='error' 
        id={errorId}
      >
        <screen-reader-content>Error:</screen-reader-content>
        <span className='error__content'>
          {props.errorMessage}
        </span>
      </p>
    </>
  );
};

export default FieldText;

onInput always ends up being the onChange from the defaultProps object. Even though the console.log shows the updated function (the actual onChange function that I'm trying to pass down).

What am I doing wrong here?

Thanks!

Edit:
It may be worth noting that I'm using Vite + Solid via vite-plugin-solid plugin. When I first load the page, the issue described above is there but if I make it "hot reload" I do actually get the correct behavior (I get the right onChange.

[ryansolid]

This might be of interest. I thought I mentioned it in the docs but I might have done it in a very glossed over way:

#359

I had some more discussions elsewhere. ryansolid/dom-expressions#33 (comment). From midway down to almost the end.

The gist of it is that compiled consideration would de-optimize the common case and be inconsistent. Still looking if there is a reasonable solution here.

[kee-oth]

Ah, you know... I actually do remember coming across that 🤦‍♂️

I spent a decent amount of time banging my head against this and considering I'm not the first and certainly won't be the last person to try it this way, maybe the compiler should spit out a "Hey, this might not work as expected" warning with an explanation and helpful hints.

Thanks for taking the time to answer!

[ryansolid]

Yeah for sure. It's a tricky one since it's being passed through parents that makes this tricky. I can't tell if it is dynamic except at runtime. And even then I can't be sure. A chain of of {props.onClick} could look like they might be dynamic. Without being able to know how they are applied (like in a click handler in the end) would make this really hard. It would require a type of analysis no current framework does. I don't like that it trips people up. Maybe I can make a shortlist of these things. Destructuring is the big one. I am not sure there are many but there are probably a couple other smaller ones.

[kee-oth]

Yeah, I think a "Gotchas/Quirks" section in the docs that explains some of these common scenarios would be helpful. It'd be good to collect them for readers and also have a specific place to direct people to when they ask questions. It could even be mentioned in the default Issues message so people can explore it and see if they can find the answer to their question there.

A collection like this would also be helpful for maintainers to quickly see how "quirky" the library is overall in order to assess DX and such.