AshPhoenix.Form.Auto (ash_phoenix v0.5.7) View Source
A (slightly) experimental tool to automatically generate available nested forms based on a resource and action.
To use this, specify
forms: [auto?: true] when creating the form.
There are two things that this builds forms for:
- Attributes/arguments who's type is an embedded resource.
- Arguments that have a corresponding
For more on relationships see the documentation for
When building forms, you can switch on the action type and/or resource of the form, in order to have different
fields depending on the form. For example, if you have a simple relationship called
on_match: :update and
on_no_match: :create, there are two types of forms that can be in
In which case you may have something like this:
<%= for comment_form <- inputs_for(f, :comments) do %> <%= hidden_inputs_for(comment_form) %> <%= if comment_form.source.type == :create do %> <%= text_input comment_form, :text %> <%= text_input comment_form, :on_create_field %> <% else %> <%= text_input comment_form, :text %> <%= text_input comment_form, :on_create_field %> <% end %> <button phx-click="remove_form" phx-value-path="<%= comment_form.name %>">Add Comment</button> <button phx-click="add_form" phx-value-path="<%= comment_form.name %>">Add Comment</button> <% end %>
This also applies to adding forms of different types manually. For instance, if you had a "search" field
to allow them to search for a record (e.g in a liveview), and you had an
on_lookup read action, you could
render a search form for that read action, and once they've selected a record, you could render the fields
to update that record (in the case of
on_lookup: :relate_and_update configurations).
on_lookup: :relate_and_update configurations, the "read" form for that relationship will use the appropriate read action.
However, you may also want to include the relevant fields for the update that would subsequently occur. To that end, a special
nested form called
:_update is created, that uses an empty instance of that resource as the base of its changeset. This may require
some manual manipulation of that data before rendering the relevant form because it assumes all the default values. To solve for this,
if you are using liveview, you could actually look up the record using the input from the read action, and then use
to set that looked up record as the data of the
In the case that a manage_change option points to a join relationship, that form is presented via a special nested form called
_join. So the first form in
inputs_for(form, :relationship) would be for the destination, and then inside of that you could say
inputs_for(nested_form, :_join). The parameters are merged together during submission.