Using validate with partial params

Hmm…yeah, this may be a bug. As a test, you could try something like this before calling update_params

params = AshPhoenix.Form.params(form)
form = AshPhoenix.Form.validate(form, params)
# update params

Would nested forms / embedded resources be causing this? (I’ve tried including fields that are not nested, and they also don’t appear in AshPhoenix.Form.params(socket.assigns.form))

(Again, this is only if socket.assigns.form is the form assigned on mount. If I’ve interacted with the form via a validate function or something (passing params from the phx-change action) then params are present)

A specific question: Would you expect a form to have params if it’s straight out of AshPhoenix.Form.for_update(socket.assigns.current_user, :update_settings) ?

Here is my simplified code if it helps. I’ve also pasted a gist (look in handle_event("choose_profile_photo" for the URL) to give some dbg content.

  @impl true
  def mount(_params, session, socket) do
    form = AshPhoenix.Form.for_update(socket.assigns.current_user, :update_settings)

    socket
    |> assign(:form, form)
    |> ok()
  end

  def render(assigns) do
    ~H"""
    <div>
      <.form
        :let={f}
        for={@form}
        id="account-form"
        phx-submit="save"
        phx-change="validate"
        class="max-w-2xl space-y-4"
      >
        <.error :if={Enum.any?(@form.source.errors)}>
          Oops, something went wrong! Please check the errors below. %>
        </.error>

        <.inputs_for :let={settings} field={f[:settings]}>
          <div>
            <.label>First Name</.label>
            <.input field={settings[:first_name]} />
          </div>
          <div>
            <.label>Profile Photo ID</.label>
            <.input field={settings[:profile_photo_id]} />
          </div>
          <div>
            <.label>Profile Photo</.label>
            <div class="p-4 border border-gray-200 rounded shadow-md">
              <.live_component
                module={WinkWeb.EditorComponents.FilePicker}
                id="profile-photo-picker"
                files_context={@files_context}
                selected_file={@form.source.data.settings.profile_photo_id}
                file_chosen_callback="choose_profile_photo"
                file_position="profile"
                allowed_types={["asset"]}
                current_view="Assets"
              />
            </div>
          </div>
        </.inputs_for>
        <.button type="submit">Save Changes</.button>
      </.form>
    </div>
    """
  end

  @impl true
  def handle_event("choose_profile_photo", %{"file-id" => file_id}, socket) do
    params = AshPhoenix.Form.params(socket.assigns.form)
    dbg(params)
    # params #=> %{"_form_type" => "update", "id" => "47f9713d-499a-4079-b35b-adba01397a0a"}

    dbg(socket.assigns.form)
    # gist - https://gist.github.com/alexslade/2ea996d74394b3a344cf0f72e8a0c892

    socket
    |> noreply()
  end

actions do 
  ...
    update :update_settings do
      accept [:settings, :email]
    end
  ...
end

no, the params wouldn’t be there at first because only_touched? defaults to true when generating params. Try doing params = AshPhoenix.Form.params(form, only_touched?: false) on that first button click. It’s possible that what you may need to do is, on mount, if you want this to work, validate the form with those full params.

Adding only_touched?: false gives me a new “settings” key but without any fields. Compare to if the form has previously gone through a validate call (phx-change="validate") which sends all the form payload to get the params set up .

   
  def handle_event("choose_profile_photo", %{"file-id" => file_id}, socket) do
    # TODO: This is a temporary hack implementation, I've got an open question on the forum about how to handle this properly.
    # https://forum.elixirforum.com/t/using-validate-with-partial-params/71334
    params = AshPhoenix.Form.params(socket.assigns.form, only_touched?: false)
    dbg(params)

    socket
    |> assign(:chosen_image_id, file_id)
    |> noreply()
  end

Without a validate step:

    params #=> %{
      "_form_type" => "update",
      "id" => "47f9713d-499a-4079-b35b-adba01397a0a",
      "settings" => %{"_form_type" => "update"}
    }

With a change to “email”

params #=> %{
  "_form_type" => "update",
  "_touched" => "email,settings",
  "email" => "alex@upmailsolutions.coms",
  "id" => "47f9713d-499a-4079-b35b-adba01397a0a",
  "settings" => %{
    "_form_type" => "update",
    "_persistent_id" => "0",
    "_touched" => "_form_type,_persistent_id,_touched,_unused_date_format,_unused_first_name,_unused_profile_photo_id,_unused_time_format,_unused_timezone,date_format,first_name,profile_photo_id,time_format,timezone",
    "_unused_date_format" => "",
    "_unused_first_name" => "",
    "_unused_profile_photo_id" => "",
    "_unused_time_format" => "",
    "_unused_timezone" => "",
    "date_format" => "%d/%m/%Y",
    "first_name" => "Alex",
    "profile_photo_id" => "5",
    "time_format" => "%H:%M",
    "timezone" => "UTC"
  }
}

Yeah, so the problem effectively is that there is a sort of bidirectional communication here. The underlying form data structure doesn’t know what fields you are or are not going to include in the UI, those fields get their defaults from the form, and then on type the client sends it back to us. Until then, we don’t have a full picture of what params looks like. It isn’t ideal.

You could likely do this with a bit of js on the button.

phx-click={JS.dispatch("validate", to: "#your-form") |> JS.push("time-selected", value: %{time: time})}

EDIT: "validate" probably wouldn’t be what you want, you’d want to trigger some input as if it was typed into potentially, or find some way to trigger the phx-change hook etc. I’m sure it can be done but I can’t recall how

Thanks for confirming. I’ll find another way around. Likely modifying the form inputs for now, as we don’t need validation when this image is changed. I also think our form should be factored to split this stuff up more, instead of having complex state across many entities with different validation rules, so we’ll do that if we need to make this more sophisticated.