Simpler way to set errors after form submission

Not sure if it’s just me, but the process of showing errors on a form is a bit cumbersome:

1. import { setErrors } from '@formkit/vue'
2. Set a unique ID on your form
3. Invoke setErrors() with your unique ID

What if the form submission handler was passed a second parameter containing a node object?

function submit(value, node) {
  node.setErrors(["Username not available."])
} 

Implementation details free to be changed but something like this.

[justin-schroeder]

@tosling solid points — one thing to note that will help with the unique ID thing is FormKit already produces unique IDs for you — you technically dont need to specify it yourself — but only explicitly specified ones end up in the global getNode() registry.

For submitting forms, which is now in the beta.3 branch as of a few minutes ago, you can submit these forms 3 ways:

// any id works, even the auto-generated ones
submitForm('formId')
$formkit.submit('formId')
node.submit()

An alternative way to get a node is using the @node event which is emitted from all <FormKit> components with the node as a payload. And in beta.3 you can also get the node via template ref:

<template>
  <FormKit ref="foobar" />
</template>

<script>
export default {
  mounted () {
    this.$refs.foobar.node.input('hello world')
  }
}
</script>

Playground example

[justin-schroeder]

I think @huzaifahj’s suggestion in great, and plan to implement it or something similar! I’m curious about your opposition to using id to reference core nodes @tosling. Our rational for ID vs template refs:

• It’s already useful in native JS and allows native js compatible code
• It insures unique identification
• It does not require importing ref to use it
• It can be used globally instead of template refs that can only be used in the bound context where the template was defined
• provides a consistent API between schema and template based implementations
• no need to artificially surface internals of the FormKit component which leads to quick misuse of the internals

That said, the DX still has a ways to go in my opinion. On the note of DX — my eventual goal with the form type is to automatically handle errors for most “standard” requests, and you can provide an error adaptor (imagine a laravel or django error adapter) that automatically structures error responses into the accepted setErrors format. We would leverage native fetch requests for you. An example API would be:

<FormKit
  type="form"
  endpoint="/api/users"
  method="post"
>
  <FormKit
    type="email"
    name="email"
  />
  <FormKit
    type="password"
    name="password"
   validation="required"
  />
  <FormKit
    type="password"
    name="password_confirm"
    validation="required|confirm"
  />
</FormKit>

Basically if the user provided an endpoint prop, we can assume responsibility for the submit handler and automatically catch any backend errors and set the on the form directly. This is an example of the kind of DX “enhancement” I’d like to see become reality, but what is currently published and available is still an early beta of the “fundamental” structures/api.