V2 Roadmap

[ArrayKnight]

@selbekk I'd like to discuss your proposal to co-maintain https://github.com/selbekk/calidation and potentially also https://github.com/selbekk/calidators. I'm interested. Sorry I didn't reach out on Twitter, but I don't use social media. If we get on the same page, I'm happy to share my direct contact information so we can keep in touch.

Some things that I've been thinking about:

• Updating React version to allow use of hooks (new hotness, if it makes sense to)
• Allowing for a ref to be added to Form (solves the issue of being able to externally submit the Form, currently need to implement a <button type="submit"> or use document.forms && dispatchEvent)
• Update calidators to work on more specific/generic types (depending on the validator, enforce string/number/boolean/etc type casting or be type agnostic)
• Breaking out integration tests (minor cleanup so it's easier to consume/edit)
• Introducing lodash & babel-plugin-lodash for certain utility functionality
• Add ability to get ALL errors when validating (not just the first)
• Adding recipes (breaking documentation up so the README isn't so dense, separating API & examples & real world scenarios)

[ArrayKnight]

Also, I have my own calidation.d.ts Typescript definition file in my project, but it would be good to get it officially merged into https://github.com/DefinitelyTyped/DefinitelyTyped. Mine would probably need some tweaking to be ready for production.

Alternatively, Calidation and Calidators could be written in Typescript and published with definitions.

[ArrayKnight]

It would be good to add contribution guidelines. One of the things that I missed was to use yarn commit to enforce using https://www.conventionalcommits.org/en/v1.0.0-beta.2/#summary

[selbekk]

I'm glad you're interested in pitching in!

I'll go through your ideas point by point:

Updating React version to allow use of hooks (new hotness, if it makes sense to)

Sure, I've been thinking about this as well. There are several great ways we can leverage hooks, and requiring a recent version of React doesn't seem like a blocker to me.

Allowing for a ref to be added to Form (solves the issue of being able to externally submit the Form, currently need to implement a or use document.forms && dispatchEvent)

Good idea, although I've never come across a situation where I wouldn't want to do that with a <button type="submit" />. Do you mind giving an example of such a situation? Passing a ref down should be manageable either way, but I'm just curious of your use case.

Update calidators to work on more specific/generic types (depending on the validator, enforce string/number/boolean/etc type casting or be type agnostic)

I don't mind keep adding to calidators, but we should make it tree-shakeable, and make sure we don't add too much. You always have the option of passing a custom validator.

Breaking out integration tests (minor cleanup so it's easier to consume/edit)

Yep, the tests need some cleanup for sure.

Introducing lodash & babel-plugin-lodash for certain utility functionality

To be honest, I don't see why we'd need to. Less dependencies are better. Especially stuff we could easily write ourselves.

Add ability to get ALL errors when validating (not just the first)

I disagree with this point, but I'm up for discussing adding a flag to achieve it somehow.

Adding recipes (breaking documentation up so the README isn't so dense, separating API & examples & real world scenarios)

Yep, totally agree. We should probably spin up a Docusaurus site or something like it at some point.

Also, I have my own calidation.d.ts Typescript definition file in my project, but it would be good to get it officially merged into https://github.com/DefinitelyTyped/DefinitelyTyped.

I'm totally open for that.

Alternatively, Calidation and Calidators could be written in Typescript and published with definitions.

Haven't touched TypeScript, but I'm all about learning. Perhaps we could add something to DefinitelyTyped first, and then consider a typed rewrite?

It would be good to add contribution guidelines.

Totally agree! That's totally required. TBH, this project kind of blew up in my face popularity-wise - wasn't expecting all of you beautiful contributors to help out.

---

I'll create a v2 milestone and create some issues where we can discuss these further.

[ArrayKnight]

Introducing lodash & babel-plugin-lodash for certain utility functionality

To be honest, I don't see why we'd need to. Less dependencies are better. Especially stuff we could easily write ourselves.

Yea, good call. That makes sense. I guess I just like it in all of my projects.

Add ability to get ALL errors when validating (not just the first)

I disagree with this point, but I'm up for discussing adding a flag to achieve it somehow.

Yea, I keep forgetting why I need this. And I keep figuring out ways around it. So, let's skip it!

Allowing for a ref to be added to Form (solves the issue of being able to externally submit the Form, currently need to implement a or use document.forms && dispatchEvent)

Good idea, although I've never come across a situation where I wouldn't want to do that with a . Do you mind giving an example of such a situation? Passing a ref down should be manageable either way, but I'm just curious of your use case.

I'm currently implementing my forms inside a Panel (Office UI Fabric) where the footer (which has my submit button) is forced into a function call outside the Form context. This means that the Parent of the Panel, SpecificForm, & Footer needs to be able to submit the Form. The Form is not directly accessible by the Parent. I could in theory put a slot in the SpecificForm which implements Form, which would allow Parent to implement a ref'd invisible submit button to trigger a click on, but that all feels wrong. Ultimately, I had Parent generate a uuid() and pass that to SpecificForm to implement on Form so that the Parent can call document.forms.namedItem(id).dispatchEvent(new Event('submit'))

class Parent {
   name = uuid()

   render() {
      return (
          <Panel {...} onRenderFooterContent={this.onRenderFooter}>
              <SpecificForm name={this.name} {...} />
          </Panel>
      )
   }

   onRenderFooter = (...) => (
       <Footer {...}>
           <button onClick={this.submit}>Submit</button>
       </Footer>
    )
}

class SpecificForm {
   render() {
       return <Form name={this.props.name} />
   }
}

[ArrayKnight]

Turns out that the UMD output wasn't quite enough due to invariant not being published in a browser compatible format. This means that we'd need to also build a secondary bundled version that could be used directly in a script, or swap out the invariant dependency.

It may also be good to use a moduleId to wrap everything under Calidation: https://babeljs.io/docs/en/babel-plugin-transform-es2015-modules-umd#more-flexible-semantics-with-exactglobals-true

Something like:

{
    "presets": ["react", "env"],
    "plugins": [
        "transform-class-properties",
        ["transform-es2015-modules-umd", {
            "globals": {
                "calidation": "Calidation"
            },
            "exactGlobals": true
        }],
        "transform-object-rest-spread"
    ],
    "moduleId": "calidation"
}

[selbekk]

Hm okay that’s fine. I’ve never tried that before, so I can’t be of much help

[ArrayKnight]

PR for the first iteration of Typescript types: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/37009

[lisatassone]

Just a heads up that I have created a PR for adding Generics support to the types here: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45348. I'd created my own types for the library a long time ago but it was great to see @ArrayKnight officially add some. I needed generic support, so it's now an option for people.