edisonywh / backoffice

Admin tool built with the PETAL stack
MIT License
217 stars 15 forks source link

LiveComponent support for rendering form fields #2

Open edisonywh opened 3 years ago

edisonywh commented 3 years ago

Rendering the LiveComponent isn't the hard part, but the hard part is in figuring out how to handle_events.

The markup would look like this:

Index.Live > FormComponent > CustomField

But users don't really get access to the FormComponent itself, so maybe we can define a generic fallback handle_event for FormComponent like so (pseudo code):

def handle_event({:update, field, value}) do
   # somehow update the current changeset and validate it (and re-render so the child component gets new values/validation error)
end

This means that maybe we can have a bit more of a complex logic in our CustomField component, then just send over a normalized version that can be popped into the changeset.

For example, I have a Listing form that can belong to a single Newsletter. I would love to be able to have a typeahead & suggestion box for Newsletters while I'm typing, and then when I click on the value, I want it to store it to the newsletter_id field in the Listing changeset instead.

Not sure how feasible this is


EDIT: It doesn't really seem possible because phx-change works on a form level, and we can't nest form in HTML (correct me if I'm wrong).

One way to do this is maybe via JS hooks?

edisonywh commented 3 years ago

The solution in #13 is to use phx-keyup and then bubble event to parent LiveView (whichever module that use Backoffice.Resources), and then the Resource's LiveView will call out to the FormComponent, which will update the corresponding fields in hidden_input.

edisonywh commented 3 years ago

I am going to merge #13 for now but I will keep this issue open as I'd like to have more discussions surrounding it: how does the API feel to you? Or is this a valid enough usecase?