Integration with vuex-forms (or something similar)

[jnarowski]

One thing I've found a very limited amount of discussion and OS tools for is vuex-forms. There is an existing project but that project seems dead (hasn't been updated in over a year). I'm thinking about forking it and making it live again.

Either way, I end up handling most of my form manipulation in the component b/c it's easier than a ton of the CRUD vuex and vue boilerplate required to send it all back to the vuex store.

Would be great to see a best practices implementation of handling forms. Even if it's a bit more verbose, standardizing it across my applications and forms would bring a lot of stability and clarity to my forms.

[chrisvfritz]

I do include one simple implementation in login.vue. Is that the kind of thing you're looking for?

[jnarowski]

I was talking about a more robust way to handle form data through vuex. There are some solutions out there but not sure any of them are active. I might start my own OS project for it.

Even without a plugin, when forms get complex (aka using many nested components) validation gets tricky, storing the data in the parent component state also gets tough.

This is one thing that most boilerplates miss is showing real, complex forms (often partially populated via ajax etc).

I just refactored a form into vuex that ended up being about 5-10 components and is quite complex so I just recently felt this pain.

It seems that there isn't many examples of this kind of thing using vuex online. I'd love to help contribute to it in some way if you're interested in adding something like this (even as a non working example) to the boilerplate.

I do see a strong potential for developing a lightweight, robust form handling library built on vuex that handles validation and form data gathering (into a temporary forms[this.form.name] endpoint on vuex.

What do you think?

[chrisvfritz]

There are definitely some patterns that can help with complex forms, but I've usually found the exact needs and nature of the complexity can vary a lot between projects, so there's not really a 1-size-fits-all solution that I can recommend unfortunately.

In the case of forms built out of many nested components, I often see people break up a form component into many smaller, nested components just because the original form component was getting big. There isn't really anything wrong with a big component though. As long as it's not becoming a pain to maintain, it can stay big. I've seen people create a lot of work for themselves by splitting up a single concern into many deeply coupled components that have to constantly communicate. It's sort of like a recipe with 20 ingredients - it might seem like a lot, but introducing 20 chefs to "simplify" it will just make it 20 times more complex. 😄

I'm not sure if that's at all relevant to your case though. It's difficult to give advice without the code and like I said, there isn't really a pattern that's appropriate for everyone. For that reason, I don't think it meets the requirements to be added to the boilerplate unfortunately.

[jnarowski]

That is an interesting point. So do you generally keep forms in a single component even if they might be hundreds to thousands of lines long, with sub collection modification etc?

I can see an argument to be made to perhaps only create components for input level stuff within a form, keeping it one to two levels deep instead of more.

[chrisvfritz]

I'll keep a component long if I feel its complexity is still pretty low and so not very difficult to maintain - and there are also other ways to shorten form components other than splitting them out into subcomponents. For example, render functions can be pretty useful in creating dynamic form generators, sometimes even automatically by analyzing the data that it's binding to.