davezuko / react-reformed Goto Github PK

Thought I would share it in case anyone else might find it useful.
It did take me stubbing my toes for a good while to get things mostly ironed out.

It may still have some problems, but it is working well enough in one of my projects.
The gist with reformed.tsx https://gist.github.com/rluiten/53ff1d74b8bf5b5453990b6e2a99349e,

Thanks for your articles and example, good stuff.

I would sort of expect this to work, but it doesn't. Any idea what I might be doing wrong?

const middleware = (props) => {
  const { setModel, setProperty, ...xProps } = props
  const interceptedSetModel = (model)=> {
    console.log(model)
    return setModel(model)
  }
  const interceptedSetProperty = (name,value) => {
    console.log(value)
    return setProperty(name,value)
  }
  return { setModel: interceptedSetModel, setProperty: interceptedSetProperty, ...xProps }
}

const SimpleForm = props => {
  const { bindInput } = props
  return (
    <form>
      <Input {...bindInput('example')} />
    </form>
  )
}

const ReformedForm = reformed(middleware)(SimpleForm)

ReactDOM.render(<ReformedForm />, document.getElementById('app'))

There are no (expected) logs when the model inside the reformed form changes. I'm really stumped...

Created a PR to add support for bindInput( "nested.data" ) etc to work with nested models.
#5

OK, I was a bit too fast in stating that 2.0.0 fixed my issue. My goal was to intercept setModel, not setProperty and it's still impossible to override. Now that I understand what is happening, it's easy to see why: if you don't override setProperty, it will still be "locked in" with the original setModel function.

This for example will not work.

const middleware = function(props) {
  const { setModel, ...xProps } = props
  const interceptedSetModel = (model)=> {
    console.log("Intercepting model")
    console.log(model)
    return setModel(model)
  }
  return { setModel: interceptedSetModel, ...xProps }
}

const SimpleForm = props => {
  const { bindInput } = props
  return (
    <Form>
      <Input {...bindInput('example')} />
    </Form>
  )
}

const ReformedForm = reformed(middleware)(SimpleForm)

Now, you may begin to wonder why we would want to use that?

Let's say we're creating a dynamic form that has "repeatable" parts. The output we are aiming for is an array like this:

output = [
  {
     name: "foo",
     value: "hello"
  },
  {
     name: "bar",
     value: "world"
  },
]

If I can intercept setModel, I can easily store the state of the entire "form" into an array inside of a higher order state object. We could perhaps do this with setProperty as well, but I'm betting this will break bindInput, etc because the internal state of the "lower order" reformed component will not be updated anymore...

I am getting this:

Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.

React version: 15.5.4

Was implementing this myself when I decided to do a quick check if it wasn't already done, great work.

But it's kinda ugly to show all those error messages to a user when they haven't even typed a single character yet.
So either for schema validation put a isDirty flag on the field data right next to isValid or don't even validate if model[field] === initialModel[field]

Hi,
Great work on this library! I noticed a minor issue that I wanted to get your input on (no pun intended):

If you don't use an initial model for a form, React with display this error message once the onChange event is triggered for the first time:

Warning: OtherForm is changing an uncontrolled input of type text to be controlled. Input elements should not switch from uncontrolled to controlled (or vice versa). Decide between using a controlled or uncontrolled input element for the lifetime of the component. More info: https://fb.me/react-controlled-components

Apparently this is caused by React treating any inputs with a value of null or undefined as uncontrolled. Typing in the input updates the model, which sets a new value on the input, converting it to controlled.

This warning is easily avoided by just using an initial model or by doing something like value={model.firstName || ''}. But perhaps bindInput could be updated to do this by default, something like this:

bindInput = (name) => {
      return {
        name,
        value: this.state.model[name] || '',
        onChange: this.bindToChangeEvent,
      }
    }

Happy to open a PR if you think this is good idea.

Hello,
First of all I want to thank you for such a cool library.
I am still trying to wrap my head around it so I was wondering if you could give me advice how would you go about passing isSubmiting state into form from HOC with asumption you will always have onSubmit prop. I would like to keep my LoginForm stateless

Code example of what I am trying to achieve

export default compose(
  connect(
    state => ({
      initialModel: {...}
    }), {
      onSubmit: login
    }
  ),
  reformed(),
  isSubmiting()
)(LoginForm)

const LoginForm = ({
  model,
  bindInput,
  onSubmit,
  isSubmiting
}) => (
  <form onSubmit={onSubmit} >
    <input
      name='username'
      {...bindInput('username'))}
    />
    <Button
      value={isSubmiting
        ? 'Click me'
        : 'I am submiting now'}
    />
  </form>
)

Hi there,

The library is amazing and has taught me great deal of information. I am very new to react and I have come across a challenging validation problem. My validation is dependent on the state of the model. For example if a specific select option is selected a text field will appear and that's when the text field becomes required.

I'm still trying to get my head around HOCs so it's not very clear if they are indeed useful in my case (I have a strong feeling they are). Particularly I wanna be able to dynamically place different input elements on the form depending on the current state of the model (show/hide elements). This requires me to be able to remove and add properties to my model (which the reformed HOC does).

What happens in cases where validation must be applied on submit as oppose to synchronous validation. How can HOC solve such problems? I've been looking into the source code for a few hours and I mostly understand what's happening and the solution is great for simple forms. When complexities like dynamic field rendering and validation, I'm not sure how you can abstract these logics with the use of HOC. Any insight would be greatly appreciated.

I apologize for posting a question in the issues but I was evaluating using reformed vs redux-form today. I saw that redux-form is at v6 now and the migration guide Inversion of Control section specifically states that one of the issues with v5 and below was that every single keypress that changed a form value caused a complete re-render of the form which could lead to performance issues on larger forms.

I started to implement reformed and right away realized thats what was happening here as well. Having read the redux-form portion makes me cautious about moving forward with reformed but I want to make a somewhat informed decision on this and not just read what one module says as gospel.

Could you talk a bit about the effect reformed would have on more complex forms and if I'd be pigeon-holing myself into performance issues down the line? I don't foresee having huge forms in my app but you never know what comes in the future.

As explained pretty well in this article, autofill creates a few problems with server-side rendering, because the change event happens before React finishes initialising. So we end up back on the world of having to use refs and reading the DOM when mounting the form. I'm wondering if you have any preferred patterns for this.

Hi there, any plan to publish a UMD release?