Submit form on keyup/keydown

[gabrielstuff]

Hi!
I'm trying to figure out how to send the form using keydown or keyup. Does not look to be implemented.

Thanks,

G

[lionel-bijaoui]

Can you provide more details ?

[gabrielstuff]

hello @lionel-bijaoui,
The idea is to be able to send the form on enter when keycode 13 is pressed: keyDown
On this simple codepen you can type and press "enter". By default the browser will submit the form relative to the fieldset you are in.

https://codepen.io/gabrielstuff/pen/eRZxBz

Thanks !

[lionel-bijaoui]

I'm still not sure I get where the problem is.
When the user fill the form, the model is updated in real-time, so you can listen to any even you want and send the data however you want.
For example:

document.addEventListener('keypress', function (e) {
    var key = e.which || e.keyCode;
    if (key === 13) { // 13 is enter
      // send model data to server
    }
});

If what you want is a button, you can use submit.
https://icebob.gitbooks.io/vueformgenerator/fields/submit.html

[gabrielstuff]

Ok, maybe I'm not clear enough. What you propose is somekind of tape on top on something that should "natively" be supported. A form + a submit button in the browser convention means when you type enter, the form is submited.
So that is why I wondering how to do it natively without relying on document.addEventListener or something else.
Thanks !

[lionel-bijaoui]

Well, sorry if this is a "hack" for you...
document.addEventListener is a simple solution to emulate the native way a <form> work.
If you have a better solution in mind, you are free to do a PR and enhance this plugin for the good of the community.

[gabrielstuff]

Yes ! What do you think about adding it natively to the plugin and thus support by default the listening of the keycode 13 on keyup ? I could surely PR, if you are ok with this feature.

[lionel-bijaoui]

If you do that, it will have to be something deactivated by default and set with an option. Most usage of this plugin don't need a redirection or to react to enter and adding it by default would break all current implementations.
I can't guaranty that your PR will be accepted, since validation of feature depends on @icebob , the creator of this plugin.

I'm very curious on what you mean by "natively" and how you are going to implement this without addEventListener, but I will take a look at your PR with a lot of interest.

Good luck and thank you for your participation !
PS: don't forget to mention this issue in the PR ! thx

[gabrielstuff]

I'm going to use addEventListener, I'm just going to make it at the module level and not for the user. If I use template engine like vue, is to be faster and cleaner than native HTML markup... Adding addEventlistener on top of form generation is kind of rewriting again and again the browser logic.

…

On 12 Jun 2017, 15:23 +0200, lionel-bijaoui ***@***.***>, wrote: If you do that, it will have to be something deactivated by default and set with an option. Most usage of this plugin don't need a redirection or to react to enter and adding it by default would break all current implementations. I can't guaranty that your PR will be accepted, since validation of feature depends on @icebob , the creator of this plugin. I'm very curious on what you mean by "natively" and how you are going to implement this without addEventListener, but I will take a look at your PR with a lot of interest. Good luck and thank you for your participation ! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lionel-bijaoui]

So you are going to put document.addEventListener in the mount hook of the module ? I don't see why you think it's cleaner but go on, it's a useful functionality anyway.
I can see a need for more classic behavior when using VFG, especially with beginners. The more accessible we make VFG, the better 👍
Also, it will be more inline with browser implementation and good practice (kinda like #74 ).
Keep me posted, and gook luck !

[lionel-bijaoui]

@gabrielstuff you may want to take a look at this #26

[lionel-bijaoui]

@gabrielstuff Any progress on this ?

[zoul0813]

I too was surprised to find out that vue-form-generator didn't use an actual <form /> element, and provide access to a 'submit' event.

A quick modification to formGenerator.vue, changing the top-level <div /> into <form /> and adding a v-on:submit.prevent="formSubmit" attribute ... then having formSubmit method call this.$emit('submit', this.model) allows the parent component to add a @submit="onSubmit" event handler. Emitting the event would allow the change to be backward compatible, and should not interfere with or break existing uses of the component.

This seems like a standard feature for a form component.

form.vue-form-generator(v-if='schema != null' v-on:submit.prevent="formSubmit")

formSubmit(evt) {
	this.$emit('submit', this.model);
},

I have a branch with these changes in my fork, https://github.com/icebob/vue-form-generator/compare/master...zoul0813:feature/223-form-submit?expand=1

[DelfsEngineering]

@zoul0813 VFG is far more than a form 'submission' tool. Really it is a dynamic UI renderer. Simple form submission can be handled by posting the model to your endpoint.

I disagree that this should be changed to be reverse compatible with form submit. It feels like a step backward. Coupled with Vue's reactivity and a live framework like feathers you have dynamic live data. ... Super powerful.

Only a few lines of code are needed to handle a traditional post and even if you did do it that way, you still need code to handle errors etc.

[zoul0813]

I’m new to Vue, but the docs seem to imply one-way data binding with events passing data up the stack is the correct way to manage the models. Without the form providing some sort of event to listen too, how does the rest of the app know when the user is done? Requiring the user to click a button isn’t very friendly, as simple forms can be submitted with a key press traditionally. My change still has the developer implementing the form “post” code themselves, as it cancels the standard form submit event and just fires a submit event of its own to indicate the user has completed the form and is ready for the next step.

Only a single event handler is needed with the suggested change I made, at which point the developer implementing the form in their project doesn’t need to work around it. The form gen exposes a validated event, just seems logical to also expose a “submit” event of some sort to indicate completion through any manner of methods.

[DelfsEngineering]

@zoul0813 Was there any updates to this?
Can we perhaps now add a <form> in VFG if needed?
I too now see use cases where we want the submit button clicked with field enter

[zoul0813]

@DelfsEngineering I just wrap my <vue-form-generator ref="vfg" ... /> tag with a <form @submit.prevent="onSubmit"> and then go from there. I can use this.$refs.vfg to determine if the VFG form is "validated" or not, etc.

After further use and consideration, I don't think VFG should implement the form itself as this would cause conflicts with forms that are composed of multiple VFG instances, or a combination of VFG and non-vfg elements. It's easy enough to just wrap the VFG tag with a form element and handle the submit from there if you want to use traditional

tags.

<form @submit.prevent="onSubmit">
  <vue-form-generator ref="vfg" :schema="schema" :model="model" :options="formOptions"></vue-form-generator>
  <input type="submit" value="Submit" />
</form>

onSubmit($event) {
  // using "validateAsync option, so validate() returns a promise
  this.$refs.vfg.validate().then((valid) => {
    if(valid) { /* process */ }
    else { /* handle */ }
  }).catch((err) => {
    /* handle */
  });
}

As for handling traditional forms, without relying on VFG validation (or rather, ignoring it), you can just remove the "@submit" handler and the <form /> is treated as a classic HTML form. VFG will still do field-by-field validation and update CSS classes and display validation errors, but the user would be able to submit the form and ignore them.

Closing this Issue for now as it appears @lionel-bijaoui only re-opened it because @gabrielstuff was going to submit a PR (which either did not happen, or was not merged).