Hello! There is a fundamental question related to LiveView forms that I’ve been struggling with. In all the simple form tutorials, the form fields map one-to-one to the fields of the underlying data structure. But in my experience, that’s rarely the case. Here’s a practical example I’m working on …

One way to go is having changesets specifically for forms that then convert to the appropriate db schema, though that’s a bigger topic and something I never do personally. A simpler way is to use a virtual field specifically for forms. In your case it could look roughly like this: defmodule MyApp…

[image] blazejcm: In the database, I store this as two fields: Integer that represents the number of pages or minutes, and an atom that specifies which unit is used (:pages or :minutes). You are venturing down a dangerous path here. You should store this as three columns: :type (:audiobook an…

FWIW, when it comes to your specific scenario I fully agree with @garrison , I was using your scenario to answer the more general question as I know you are learning!

Hi guys, This is all very interesting! I have to say, though, that I am starting to get the feeling that LiveView is the kind of framework where my UI choices are going to be dictated by the (somewhat undocumented) capabilities of the framework instead of the framework enabling a variety of UI des…

In general, when form fields don’t map exactly to the database entity, you can use an embedded schema that maps exactly to your UI for validation. You don’t persist the embedded schema but map it to your DB entity after validation and then persist that. Here is a video showing this approach: Elixir…

[image] blazejcm: I am starting to get the feeling that LiveView is the kind of framework where my UI choices are going to be dictated by the (somewhat undocumented) capabilities of the framework Just so we’re clear here, the things discussed on this thread are very documented. Make sure you …

Funny, I hadn’t noticed this reply indeed also used a virtual field. So you see that I have in fact changed very little: all my example does, really, is split the length field into two.

Ha, it’s actually pretty validating seeing someone give essentially the same advice :sweat_smile:

Thank you, guys! Virtual fields were the ticket. For the record, I do have the book and audiobook lengths stored separately in the DB but I wanted to simplify the UI. Regarding documentation, this is exactly what I could not find online: an in-depth presentation of how forms and Ecto go together. …