bradwestfall / informative Goto Github PK

This happens if the value is not a string. The logic here https://github.com/bradwestfall/informative/blob/master/src/Form.js#L138 needs to account for value having the trim method on its proto.

Maybe this is more of a hassle than its worth, but what if instead of requiring a promise on submit we provided a closure to them that makes them handle success or failure?

      if (this.props.onSubmit) {
        const successful = succeed => succeed ? this.submitSucceed() : this.submitFailed();
        this.props.onSubmit(values, this.state, successful)
      }

The downside is it makes it less straight forward if you already using promises all over, but leaves flexibility there if you are using callbacks, or doing something like just dispatching an action as part of your onSubmit function. If we do go that route I think it would make sense to optimistically mark submitted: true if its submitted and passed validation, but before we invoke their callback.

I need a way to turn empty string into '0' or at least 0 for checkboxes.

Currently I am mapping those values on submit, however it requires to keep track of which fields are checkboxes (working with big forms). To avoid keeping track of field types, I thought to look for checked property as a way to differentiate checkboxes from other fields, but the only thing available is formState.fields[name].props.checked which are initial props and do not update.

Ideally, this would be dealt with on a field instance and not submit. Also looked into creating a separate CheckboxField component, but it seems that '' is hardcoded in the Informative internals, so dealing with it there is too late.
How about an uncheckedValue prop?

What would be the best way to do this?

Thanks

Hey @bradwestfall thanks for all the work you've done on this!

Is there a built in way to handle server-side errors when the onSubmit promise is rejected?

It would be nice to be able to reject the promise with the same type of object returned by validate and then access those errors somewhere in fieldState/formState when I render my Field.

This is how redux-form handles it: http://redux-form.com/6.0.0-rc.1/examples/submitValidation/

I don't see anything like this on the README, but it's possible I was looking for the wrong term.

Consider this

<Form
  onSubmit={this.handleSubmit}
  render={(formProps, formState) => {
    return (
      <form {...formProps}>
        <Field
          name='color'
          component='input'
          type='radio'
          value='yellow'
          checked
        />
        <Field
          name='color'
          component='input'
          type='radio'
          value='blue'
        />

        <Button type='submit'>
          Save
        </Button>
      </form>
    )}
  } />

When clicking on either of the radio inputs, error is Uncaught TypeError: fieldValueFormatter is not a function

The error happens on L136 (Form.js) because this.state.fields[name] does not have format and trim properties (L120 and L121).
I've noticed this in the past, but always attributed it to the error on my end where I would have multiple elements with the same name. Radios however have to have the same name.

Please let me know if I am doing something wrong.

It doesn't look like its being used in the Fields yet, but I'm guessing there is a plan to =) What is the goal of the children having access to the broader form state?

The form wrapping feels a bit weird, requires a lot of context of the inner workings of Form and its state. The result is that it'll tie your app in pretty hard, or at a minimum require you to maintain a middle-tier abstraction for it. I don't have a working implementation yet (but I'm hacking something together) but I was thinking of an API like this:

// Expect my component to have a single input, and name it
const CustomInput = ({label, name, type}) =>
  <fieldset>
    <label htmlFor={name}>{label}</label>
    <input name={name} type={type} />
  </fieldset>;

const Username = field('username')(CustomInput);

class App extends Component {
  submit(...args){
    return new Promise(ok => ok(console.log(args)) );
  }
  render() {
    return (
      <div className="App">
        <Form onSubmit={this.submit}>
          <Username label="email" name="username" type="text" />
          <FieldWrap label="Password" name="password" type="password" />
          <button type="submit">Submit</button>
        </Form>
      </div>
    );
  }
}

Then the field HOC is the only thing that knows about the context or the inner workings. It could still pass along the specialized callbacks as props, in case they want to tie those into the component but its super easy to never know about it if you don't care.

The actual implementation would have to include walking the tree to find the input(s) which is the downside, but then you assure that the attaching happens correctly and can handle common scenarios the user might not think about like the onChange they provide should probably also be executed in addition to the attached one.