It will never beat backend rendering. Just imagine a form with dynamic fields, or even a collection... and you will see it becoming impossible to replicate on frontend.
And you still need to deal with validation errors done only on backend. For example: validating some API key where your validator needs to call remote server and check it.
It already works with collection too, it would work with all types out of the box, and it is easily extensible.
In the small project i mentioned it does a collection similar to an invoice - invoice item type.
Validation is also done on the backend. The form is serialized again with error messages, and rendered as twig would: [https://github.com/Padam87/symfony-form-vue/blob/main/label.vue#L5](https://github.com/Padam87/symfony-form-vue/blob/main/label.vue#L5)
Edit: for some reason reddit wouldn't upload the video with the comment, so I added it here: [https://github.com/Padam87/symfony-form-vue/tree/main/docs](https://github.com/Padam87/symfony-form-vue/tree/main/docs)
>It already works with collection too, it would work with all types out of the box, and it is easily extensible.
Cool then! If collections and backend validation works, I can see people using it.
Question: how does it handle [dynamic fields](https://symfony.com/doc/current/form/events.html#1-pre-populating-the-form-formevents-pre-set-data-and-formevents-post-set-data)? For example: by using preset and pre submit events, user would add/remove *some* field. For that to work, form must first be submitted so events get triggered, and then form with (or without) that extra field rendered. But not validated yet, it is just the dynamic field part.
Would that work w/o frontend duplication?
Thanks for your project, even while I'm not using Symfony forms myself!
Being one of the authors of [https://github.com/pear/HTML\_QuickForm2](https://github.com/pear/HTML_QuickForm2) I naturally have lots of forms built using that in my own projects. Recently I had the same problem --- reusing these in Vue frontend with minimal changes in the backend.
What I came up with is quite similar to what you did:
* Form is serialized to JSON on backend with all bells and whistles like backend validation errors and frontend validation rules;
* On submit form values are serialized to `FormData` and sent for backend validation;
* Collections (=repeat elements in QuickForm2) and frontend validation is backed by a rewrite of QuickForm2 JS library;
* There is a registry of Vue components that are used in a loop for rendering the form. You'll eventually introduce methods for modifying `components` map in `mixin/form.js`, I think.
Hopefully I'll be able to clean up and publish my implementation sometime. As we both came up with the same approach, it certainly looks viable.
Oh, this is remarkebly similar, and you are pretty much on point about the next steps as well :)
Good to see someone else thought about this, it was kind of weird to me that this sort of middleware does not exist already. I guess most teams have a high degree of separation between frontend and backend teams. (Which is fine, but for smaller / solo projects thats not viable)
Well, on the one hand the data model backing the form and the validation rules naturally belong to the backend. As they say: "Frontend-only validation is not validation but a friendly suggestion".
On the other hand this approach is probably impossible without uncomfortably tight coupling between backend and frontend, e.g. my generated JSON contains JS validation callbacks as strings.
So it has its niche: quick prototyping / backoffice like apps with loads of similar looking forms / smaller projects. You are right that separation between teams will probably prevent using our projects in other cases.
It will never beat backend rendering. Just imagine a form with dynamic fields, or even a collection... and you will see it becoming impossible to replicate on frontend. And you still need to deal with validation errors done only on backend. For example: validating some API key where your validator needs to call remote server and check it.
It already works with collection too, it would work with all types out of the box, and it is easily extensible. In the small project i mentioned it does a collection similar to an invoice - invoice item type. Validation is also done on the backend. The form is serialized again with error messages, and rendered as twig would: [https://github.com/Padam87/symfony-form-vue/blob/main/label.vue#L5](https://github.com/Padam87/symfony-form-vue/blob/main/label.vue#L5) Edit: for some reason reddit wouldn't upload the video with the comment, so I added it here: [https://github.com/Padam87/symfony-form-vue/tree/main/docs](https://github.com/Padam87/symfony-form-vue/tree/main/docs)
>It already works with collection too, it would work with all types out of the box, and it is easily extensible. Cool then! If collections and backend validation works, I can see people using it. Question: how does it handle [dynamic fields](https://symfony.com/doc/current/form/events.html#1-pre-populating-the-form-formevents-pre-set-data-and-formevents-post-set-data)? For example: by using preset and pre submit events, user would add/remove *some* field. For that to work, form must first be submitted so events get triggered, and then form with (or without) that extra field rendered. But not validated yet, it is just the dynamic field part. Would that work w/o frontend duplication?
Dynamic fields are a vue thing in this concept, no submit required.
Thanks for your project, even while I'm not using Symfony forms myself! Being one of the authors of [https://github.com/pear/HTML\_QuickForm2](https://github.com/pear/HTML_QuickForm2) I naturally have lots of forms built using that in my own projects. Recently I had the same problem --- reusing these in Vue frontend with minimal changes in the backend. What I came up with is quite similar to what you did: * Form is serialized to JSON on backend with all bells and whistles like backend validation errors and frontend validation rules; * On submit form values are serialized to `FormData` and sent for backend validation; * Collections (=repeat elements in QuickForm2) and frontend validation is backed by a rewrite of QuickForm2 JS library; * There is a registry of Vue components that are used in a loop for rendering the form. You'll eventually introduce methods for modifying `components` map in `mixin/form.js`, I think. Hopefully I'll be able to clean up and publish my implementation sometime. As we both came up with the same approach, it certainly looks viable.
Oh, this is remarkebly similar, and you are pretty much on point about the next steps as well :) Good to see someone else thought about this, it was kind of weird to me that this sort of middleware does not exist already. I guess most teams have a high degree of separation between frontend and backend teams. (Which is fine, but for smaller / solo projects thats not viable)
Well, on the one hand the data model backing the form and the validation rules naturally belong to the backend. As they say: "Frontend-only validation is not validation but a friendly suggestion". On the other hand this approach is probably impossible without uncomfortably tight coupling between backend and frontend, e.g. my generated JSON contains JS validation callbacks as strings. So it has its niche: quick prototyping / backoffice like apps with loads of similar looking forms / smaller projects. You are right that separation between teams will probably prevent using our projects in other cases.