2.0.0

Hi, fellow contributors. I feel the time has come to start considering a new major version release so that we can introduce some breaking changes and deal with issues that burden formsy from the old times when things were handled with mixins. Let’s post ideas for 2.0.0 here as an “umbrella issue” so that we can start working on them and hopefully release a beta at some point. Also feel free to tell me that I’m dumb and we don’t need a new major version 😉

For the starters, we have #48 and #50, both reviewed and awaiting merge, both with introducing breaking but much needed changes.

To start with ideas, one that I had is streamlining withFormsy. Currently, for each custom form element, we need to make a new component that renders the base one, an error message and copies the value to Formsy HOC’s state. This is pretty simple but there’s a lot of code, a lot of boilerplate to just copy-paste around. I’d like to improve this by making withFormsy work more like Redux’s connect. Something like:

import { withFormsy } from 'formsy-react';
import React from 'react';
import MyInput from './some/path/MyInput';

const mapValue = event => {
  return event.currentTarget.value;
};

const renderWrapper = (Component, props) => (
  <div>
    <Component {...props} />
    <span>{this.props.errorMessage}</span>
  </div>
);

export default withFormsy(MyInput, mapValue, renderWrapper);

We could also make mapValue and renderWrapper from this example the defaults, so it would simply look like

import { withFormsy } from 'formsy-react';
import React from 'react';
import MyInput from './some/path/MyInput';

export default withFormsy(MyInput);

and uses could still supply their own mapValue and renderWrapper for cases that differ from defaults. Should probably also allow onChange prop name override for base components that deviate from the standard.

This has multiple benefits over the current HOC:

1. Much less verbose, especially for simple cases.
2. Easier to just drop into whatever file is using Formsy rather than writing a separate file to wrap each custom component.
3. Looks cool af. I mean, that’s a render prop as a HOC argument… a render argument?

Another idea would be performance issues. Aside from optimizing existing code if feasible, I’d also like to look into the possibility of marking elements as “isolated”, meaning they don’t affect rendering and validation of the form and other elements. With elements like these, we could opt to not rerender the form when they change. It would probably have to be calculated at runtime and not left to user to specify as a prop.

Any of this make sense to you guys or am I just rambling?

[MilosRasic]

I wouldn’t do it on master. If we find a bug that could be fixed in 1.x it would become impossible if master is bumped to 2.0. How about a 2.0 branch which we can merge into master once it’s good enough for release?

[Kaishiyoku]

Your suggestions make sense to me and I would appreciate it to seeing a 2.0.0 release in the future.