ar7casper
Working with to_form and inputs_for without Ecto & chageset
Hi,
I’m building an app that uses SurrealDB, I connect to it via RPC and I want to be able to present a form to the user that lets it add and edit some data.
So far, pretty much straight forward, no issues.
That’s what I got in my mount currently -
form_simple = %{
"title" => "list a",
"category" => "movies",
"description" => "",
"items" => [%{"value" => "38"}]
}
socket
|> assign(form: to_form(form_simple, as: "new-list"))
The issue rises when I want to enable the functionality for adding and removing more items.
For that, I’ve been trying to make -
<.form
:let={form}
id="new-list"
name="new-list"
for={@form}
action={~p"/user/signin"}
class="space-y-6"
>
.....
<.inputs_for :let={f_items} field={form[:items]}>
<.input type="text" field={f_items[:value]} />
</.inputs_for>
</.form>
work.
You can ignore the action attribute, it’s WIP.
No matter what I do, I can’t find a way to render stuff via inputs_for, I’m getting different errors, for every attempt I make.
I’m getting -
the Access module supports only keyword lists (with atom keys), got: "_persistent_id",
This is only the current error, when I try other approaches, then I get other errors (a bit difficult to reproduce for the purpose of this post)
Can’t find a way to make it work.
The only option I can think of now, is to simply track the :items separately and do the appropriate work on submitting the form.
Would love to get some ideas
Most Liked
Hermanverschooten
The easiest way to do this is to use an Ecto.Schema with an embedded_schema to drive the form.
@PJUllrich has a couple of videos about this on his Indie courses, it’s not free, but worth the investment.
Marcus
I’m working on something similar. It seems that to_form and inputs_for is tailored to be used with Ecto.schema. When you want to use to_form with a map then inputs_for needs some options:
<.inputs_for :let={f_items} field={form[:items]} options={[id: "items", as: "items"]}>
For more information and further details I have to have a look at the Phoenix code, which I have planned for later.
LostKobrakai
That shouldn’t be the case. There’s a protocol for different form inputs for a reason. I’d argue the observed behaviour here to be a bug with inputs_for.







