mirror of
https://github.com/ash-project/ash_phoenix.git
synced 2024-09-20 07:12:49 +12:00
chore: add explanation for add_form
oddities
This commit is contained in:
parent
ec9aca942e
commit
e8bf9d648d
1 changed files with 10 additions and 2 deletions
|
@ -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(
|
||||
|
|
Loading…
Reference in a new issue