Working with forms

[ruilopesm]

I'm starting to use LiveVue. Chose it because of how much I like Vue and for the possible integrations with complete component libraries (configured shadcn-vue and is working very well). As in many other applications, I want to work with forms.

Vue (and other JS frameworks) tend to make use of zod for input validation. However, that approach would imply that I need to model my entities on two sides: Ecto and Vue (specifically speaking about zod) as well as validate them on both sides (client and server). I would much prefer an approach similar to what LiveView and Ecto already do, by seamlessly integrating changesets for proper server-side input validation. I like the API presented in #5 (comment).

It seems that some effort is being made in such direction by implementing useLiveForm on a branch. Correct me if I'm wrong and useLiveForm would work in a different way 😅

Nonetheless, I ask what is the progress on working with forms, what needs to be done and if it would be the way I have described...

[ruilopesm]

@Valian would love to hear from you here 🙏🏼

[Valian]

Hi @ruilopes! 👋

So currently forms are a WIP. I can rebase that branch on top of main so you'd be able to test freely. That's almost exactly the implementation I'm using in production https://postline.ai and it's working quite well.

Just, there are a few shortcomings I want to address before merging it to main:

• code itself is a bit messy. I'm going through hoops to ensure I won't break Vue reactivity at any point, but it's not trivial and I'm not sure I covered all the cases. I have an idea how to tackle it, but didn't yet have time to do it

• there is no support for file inputs as part of that API. I'd like to somehow marry existing useLiveUpload and useLiveForm to coexists. This can be postponed a bit but ultimately should be there.

• currently updating values via socket doesn't work, only initial value and errors

• and the most important, I'm looking for a feedback if current API of useLiveForm is easy to understand and work with. I have a feeling it could be simplified.

FYI I was inspired mostly by VeeValidate composition api. The biggest challenge is to support nested forms, have tracking of touched, valid etc for each field / form and design a beautiful API.

Would be amazing if you could help a bit with these!

[ruilopesm]

Thanks for the quick feedback @Valian.

I can rebase that branch on top of main so you'd be able to test freely

That would be nice! Let me know when it's done :D

Would be amazing if you could help a bit with these!

I can try to use the current API and give feedback on it, if that's helpful. Moreover, I will take a look on the code and see what I can do, regarding what you pointed out here that is in fault.

[Valian]

Feel free to check it out! Code is a bit complex due to recursive TS, but if you'll ignore types it should be fairly straightforward. I just pushed rebase on main, together with compiled assets in priv/static.

[ruilopesm]

Hello again, @Valian 👋🏼

I have been tinkering with forms for the past two days. The API provided by useLiveForm is working well and wasn't difficult to use, at least from what I've tested.

A few notes:

Documentation is lacking, specially when working with Ecto and their schemas. For example, it is required that LiveVue.Encoder is implemented for each schema, which is, for privacy reasons, a feature. Nonetheless, we could write a "Working with forms" guide detailing these little things and others that are important to note.

Still whilst working with Ecto I had to implement LiveVue.Encoder for Ecto.Schema.Metadata struct, which is used by Ecto itself.

defimpl LiveVue.Encoder, for: Ecto.Schema.Metadata do
  def encode(metadata, opts) do
    metadata
    |> Map.take([:state, :source])
    |> LiveVue.Encoder.encode(opts)
  end
end

It is not a big deal, as you can see from the code, but I don't know if it's me who is doing something wrong. If this is intended to be implemented, when working with Ecto forms, again, I think it should be detailed on a guide - in the limit, this defimpl could be part of live_vue I guess.

Finally, I have found a simple bug, but don't know how we should approach it. Basically, translate_error/1 (in encoder.ex module) is raising when a backend is not specified and value is a list. Example: email: {"has already been taken", [validation: :unsafe_unique, fields: [:email]]} (notice that fields value is a list).

defimpl LiveVue.Encoder, for: Phoenix.HTML.Form do
 ...
 cond do
   backend == nil ->
     Enum.reduce(opts, msg, fn {key, value}, acc ->
-      String.replace(acc, "%{#{key}}", to_string(value))
+      String.replace(acc, "%{#{key}}", format_translation_value(value))
    end)
end
+
+  defp format_translation_value(value) when is_list(value) do
+    value
+    |> Enum.map(&to_string/1)
+    |> Enum.join(", ")
+  end
+
+  defp format_translation_value(value) do
+    to_string(value)
+  end
 end

This fixes the error, but I don't know if you are ok with it. As such, another approach would be to simply check if key is present before replacing it: as keys can never be a list (I think), the translation afterwards would always work without other changes. Something along the lines of this:

Enum.reduce(opts, msg, fn {key, value}, acc ->
  if String.contains?(acc, "%{#{key}}") do
    String.replace(acc, "%{#{key}}", to_string(value))
  else
    acc
  end
end)

P.S: When working with a backend defined everything works well. Gettext already treats these cases for us.

A few questions, now:

In my project I'm using Ash so I don't have yet an implementation of nested error serialization for Ecto-backed forms.

(quoted from a comment inside encode_form_errors/1)

When working with schemas that have associations or even with embedded schemas? I can take a look into this and make it work. Tho, I haven't looked at useLiveForm's code so don't know if it supports nested forms. Any tips or something I should know about? :D

currently updating values via socket doesn't work, only initial value and errors

Could you explain what you mean by this?

EDIT:

Found another bug. It seems that Encoder.encode/1 call is missing when passing data-props-diff attribute to the rendered component. Line 139 of lib/live_vue.ex.

EDIT 2:

What are your thoughts on using useLiveForm with forms that do not have a changeset? Such functionality is not currently working and it may be out of scope, in fact. By using pushEvent one can make it work (that's what I have done) - I just think that an unified API would have a better DX.

These are the changes that I think are needed to support simple forms (valid part might be a bit odd :p). From what I've tested, it worked fine.

For errors encoding we can simply ignore them tho and pass an empty map (?).

---

I'm very excited about using this project and eager to contribute more :D

[Valian]

Hi @ruilopes, big thanks for your input! I'm vacationing with family rn but coming back soon, will look closer and address all your questions here soon :)

[ruilopesm]

Left two edits on the above comment, just in case you don't notice them.

[Valian]

Thank you @ruilopesm ! Two days ago I pushed some additional tests and adjusted the useLiveForm code to handle nested fields. Now I need to clean it up a little bit, and think on a client-side API, but it should be closer now :)

Found another bug. It seems that Encoder.encode/1 call is missing when passing data-props-diff attribute to the rendered component. Line 139 of lib/live_vue.ex.

Should be fixed

What are your thoughts on using useLiveForm with forms that do not have a changeset? Such functionality is not currently working and it may be out of scope, in fact. By using pushEvent one can make it work (that's what I have done) - I just think that an unified API would have a better DX.

Forms backend by a simple map, right? It should be working now as well, though I might need to test it a little bit more.

[Valian]

@ruilopesm I've made a huge progress on that one - redesigned the API, added tons of tests, ensured it supports embeds and associations. Please try it again: #70

Example project contains a solid example of a complex form. I'm looking forward to your opinion!

[Valian]

@ruilopesm I've added some non-trivial adjustments to forms behaviour:

1. All events sent to the server are debounced, if debounce option is configured
2. If there are multiple events in flight, we apply values only from the last one

I was testing adding new items to the list with simulated high latency to the server. Previously, items were added immediately, but then after a moment they reverted back to previous value and then finally reached out desired value - because of how value from (slow) events was applied. Now it should work pretty good, without any races!

[ruilopesm]

@Valian Shortly I will test all the work you've done and get feedback back. Thanks for the effort :D

[ruilopesm]

@Valian some feedback regarding the current state of working with forms.

Still whilst working with Ecto I had to implement LiveVue.Encoder for Ecto.Schema.Metadata struct, which is used by Ecto itself.

This isn't need anymore, which is great.

translate_error/1 (in encoder.ex module) is raising when a backend is not specified and value is a list. Example: email: {"has already been taken", [validation: :unsafe_unique, fields: [:email]]} (notice that fields value is a list)

This error still occurs. How do you think we should approach it? I have left some suggestions above, but I might have been a bit confusing 😓

[Valian]

I think I have an idea how to deal with it, will try later today

[Valian]

Fixed in 34af377