Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formsy 1.0.0 release info preview #83

Closed
christianalfoni opened this issue Apr 12, 2015 · 10 comments
Closed

Formsy 1.0.0 release info preview #83

christianalfoni opened this issue Apr 12, 2015 · 10 comments

Comments

@christianalfoni
Copy link
Owner

Hi there,

We are moving towards a 1.0.0 release. The API has become very flexible and powerful and though I am sure there will still be lots of more input the library and its API has been a proven valuable tool. Thanks a lot for all contributions!

First of all Formsy v1.0.0 will be released when React 0.14.0 is released. The reason for that is a feature change internally in React which allows Formsy to pass hooks down to the form element children with a concept called parent-children-context. This issue confirms the feature for React 0.14.0. The Formsy implementation is ready, we just have to wait.

There will also be a few changes:

  • CI builds to automatically run tests (which now runs in Node)
  • Removed Ajax handling, as it can easily be implemented with Formsy hooks. Formsy is a form library, not an ajax library
  • validations prop can now pass an object with validations instead of a string. This allows for more complex validation, like passing regexps etc.
<MyElement name="foo" validations={{
  isEmail: true,
  regexp: /\.js$/,
  isLongerThan: 'myOtherInputName'
}}/>
  • required will also be able to pass validation rules. By default it checks for empty string, but if your element is a checkbox you might want to check if the value is false to indicate that it is required.
<MyElement name="foo" required="isFalse"/>
  • A new prop called validationErrors. This is the same as validationError, but it allows you to pass an object indicating what rule should give what error.
var validations = {
  isEmail: true,
  maxLength: 50
};
var errors = {
  isEmail: 'You have to type a valid email address',
  maxLength: 'Your email can not be longer than 50 characters'
};
<MyElement name="foo" validations={validations} validationErrors={errors}/>
@pkmiec
Copy link

pkmiec commented Apr 12, 2015

I've been experimenting with different form libraries for react and I think formsy is very good. Thanks for putting it together.

However, I think it is still lacking on the validation front. Validations are common and often the same validation is used over and over again. Take isEmail for example. I may want to use isEmail on various fields throughout the app, but I don't really want to keep saying errors = { isEmail: 'You have to type a valid email address' }. Also, the message is not a static string, but rather needs to be generated dynamically based on the parameters of the validation (e.g. maxLength: X => 'Your email can not be longer than X characters').

I think Rails does this pretty well, where you'd say,

validates_email :foo

which will check whether foo is a valid email and if not add a default validation error for email (e.g. "is not a valid email address"). I can change that default message globally if I want. Or I can also change the message on a particular instance,

validates_email :foo, :message => "really needs to be an email address"

The main point here is a field has a list of validators. All that validator needs to do is take a value (or perhaps all the values from the form) and produce an error string or null if there is no error (i.e. it is valid).

Translating this to type of approach to formsy, maybe you'd end up with something like,

<MyElement name="foo" validations={[
  validators.email(),
  validators.length({ min: 10, max: 255 })
]}/>

This would first check whether foo is an email and use a default validation error for email (e.g. "is not a valid email address"). And then it would check whether foo is within the length limits and use a default validation error for length (e.g. "needs to be between 10 and 255 characters").

I could change the default messages with maybe,

  validators.email.error = "my own static default message"
  validators.length.error = function(options) { "my own custom message - min:" + options.min }

Or I could provide a custom message and / or custom validators,

var myValidator = {
  validate: function(value) {
    if (!!value) { return "oops" }
  }
}
<MyElement name="foo" validations={[
  validators.email(message: "my own message"),
  validators.length({ min: 10, max: 255, message:  function(options) { "my own dynamic message" } }),
  myValidator
]}/>

Thanks for listening. Let me know what you think.

Edit: minor naming change.

@pkmiec
Copy link

pkmiec commented Apr 12, 2015

One more thought ... I was looking at I18N and http://formatjs.io/react/. It would be good to support localization for error messages.

Any idea on how to support something like http://formatjs.io/react/?

@gilbarbara
Copy link

Awesome, I dig the flexible validations with regex.

But I think React 0.14 will take some time to hit the stove and I keep getting the mutation warnings in my forms. Maybe you could make a pre-1.0 using the parent-child context?
react-router is already using it with a ContextWrapper solution for the owner/parent warnings.

cheers

@janmyler
Copy link

Hi, maybe I just didn't get it, is it that Formsy v1.0.0 will not require the use of mixins anymore?

@christianalfoni
Copy link
Owner Author

Hi @janmyler ,

Sorry for late response. Formsy will still require mixins, but the relationship between the form and the form elements will technically use context. It is more performant than the current solution and the Formsy.Form element and its child form elements can actually live in different "owners". Which basically means they can live inside different "render" methods and still have a relationship.

@drawveloper
Copy link

@pkmiec 👍 very important to keep i18n in mind, and React Intl is the de-facto solution right now.

@christianalfoni
Copy link
Owner Author

@pkmiec and @firstdoit , yeah, I totally agree. I have no experience with React Intl (You referring to Yahoo?) or formatjs, but I am very open to suggestions and examples of how to handle this!

@Nicolab
Copy link

Nicolab commented Jun 3, 2015

i18n is a great idea. However, to better integrate into existing projects, no module should be imposed.

The ideal would be to go through an adapter, like this:

Formsy.translate(function(errorMessage) {
  return anyTranslator(errorMessage);
});

Or via a config container:

Formsy.config.translate(function(errorMessage) {
  return anyTranslator(errorMessage);
});

@christianalfoni
Copy link
Owner Author

React 0.14 is now in Beta and I am working on the next release. When 0.14 is released and the new version has been tested, we go for 1.0 release :-)

When it comes to translation I do not see why formsy needs a wrapper for this. As you probably have other translations in your project already, so:

<MyInput validations="isEmail" validationErrors={{isEmail: translate('invalidEmail') }}/>

It would work just like translating any other text in your components?

Closing this issue as things are moving along.

@Nicolab
Copy link

Nicolab commented Jul 13, 2015

It would work just like translating any other text in your components?

Indeed, it makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants