Validators not always running when expected.

[mthadley]

I'm noticing behavior like this:

class Inner extends JSXComponent { /* ... */ }

Inner.PROPS = {
  bar: Config.string()
};

class Outter extends JSXCompoonent {
  render() {
    return <div><Inner bar={undefined} /></div>;
  }
}

Outter.PROPS = {
  foo: Config.number()
};
/* ... */

const outter = new Outter(); // No warning

outter.props.foo = '2'; // Warning from Inner, 'bar' is undefined, etc.

To me, it seems like I should have seen the warning when the component initially rendered also. I'm guessing on re-ender, some kind of state-key now exists for bar, and the validator is finally run for the incoming value (which is still undefined).

[mairatma]

I haven't investigated this yet, so not 100% sure, but this is probably because props are lazily set, meaning that both setter/validator only run for the first time when they're first accessed. We probably access the child's data when we render for the second time, making the validator finally run.

I see why this wouldn't be desirable in these validator cases though... I'll have to think about this for a while (after confirming this is what's actually happening).

[mairatma]

I was actually wrong, we do have lazy logic, but that's just for initializing props until their first get/set call. Validators are not lazy, so they should run at the correct time.

The problem here is just with the undefined value actually, the check we're making to see if a value was given is wrong. Will fix, thanks for reporting!