From e8bf9d648d91bdabe672b69bb48d6bb68c9616b7 Mon Sep 17 00:00:00 2001 From: Zach Daniel Date: Tue, 21 Jun 2022 18:33:03 -0400 Subject: [PATCH] chore: add explanation for `add_form` oddities --- lib/ash_phoenix/form/form.ex | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/lib/ash_phoenix/form/form.ex b/lib/ash_phoenix/form/form.ex index 23e75db..6cf51ab 100644 --- a/lib/ash_phoenix/form/form.ex +++ b/lib/ash_phoenix/form/form.ex @@ -940,7 +940,7 @@ defmodule AshPhoenix.Form do end end - {forms, Map.delete(params, [key, to_string(key)])} + {forms, params} end) end @@ -1707,6 +1707,14 @@ defmodule AshPhoenix.Form do 1. A list of atoms and integers that lead to a form in the `forms` option provided. `[:posts, 0, :comments]` to add a comment to the first post. 2. The html name of the form, e.g `form[posts][0][comments]` to mimic the above + If you pass parameters to this function, keep in mind that, unless they are string keyed in + the same shape they might come from your form, then the result of `params/1` will reflect that, + i.e `add_form(form, "foo", %{bar: 10})`, could produce params like `%{"field" => value, "foo" => [%{bar: 10}]}`"}. + Notice how they are not string keyed as you would expect. However, once the form is changed (in liveview) and a call + to `validate/2` is made with that input, then the parameters would become what you'd expect. In this way, if you are using + `add_form` with not string keys/values you may not be able to depend on the shape of the `params` map (which you should ideally + not depend on anyway). + #{Ash.OptionsHelpers.docs(@add_form_opts)} """ @spec add_form(t(), String.t() | list(atom | integer), Keyword.t()) :: t() @@ -2824,7 +2832,7 @@ defmodule AshPhoenix.Form do ) end - {Map.put(forms, key, form_values), Map.delete(params, [key, to_string(key)])} + {Map.put(forms, key, form_values), params} end defp handle_form_with_params_and_no_data(