Does the the Phoenix "simple_form" let me access data that the table belongs_to?

[prime pawn]

The original code below was created with the HTML generator when I created TestBed table. The first field is referencing a field named "name" on TestBed. The second field I manually placed (the field with [:group]) in an attempt to reference the table data that TestBed belongs_to.

`<.simple_form :let={f} for={@changeset} action={@action}>
<.error :if={@changeset.action}>
Oops, something went wrong! Please check the errors below.
</.error>
<.input field={f[:name]} type="text" label="Name" />
<.input field={f[:group]} type="text" label="Group" />

<:actions>
<.button>Save Test bed</.button>
</:actions>
</.simple_form>`

In the field with the :group atom what I really want is the group name. In code that looks like this:

tb = App.TestBeds.get_test_bed!(1) tb.group.name

It just so happens if I write it like this it does not work as atoms do not have keys:

<.input field={f[:group.name]} type="text" label="Group" />

Is there a syntax that lets me capture the data I want using this form? Something like:

<.input field={f[:group],[:name]} type="text" label="Group" />

The error is attached. The only place I've seen that error before is when I referenced this data without preload, but as far as I can tell I am using preload in App.TestBeds.list_testbeds. I tried looking at the simple_form definition and docs but it's just too much for me to understand at this stage.

Thanks

[terse vapor]

Are you editing a testbed or creating a new one? Do you want a new group to be created with the given name or do you want to attach an existing group?

the inputs_for component is what you're looking for to add the nesting:https://hexdocs.pm/phoenix_live_view/Phoenix.Component.html#inputs_for/1

but how exactly you use it or whether you need to use it at all in this case depends on what specifically you want to accomplish

e.g. if what you want to do is just attach an existing group, I would use a select input instead of a text input, and use the group_id field of the testbed. Your LiveView would just need to get a list of all groups to populate the select options

if you want to create a new group, you'd need to use nested inputs and then use cast_assoc in your changeset

[prime pawn]

In the short term I just wanted to render the data, the end goal is to let the user choose the group a testbed is assigned to via a drop down or some equivalent UI choice. In an even broader sense I am trying to get a real understanding of how the generated forms simply "work" . I fumble on simple things like how to Inspect form input with IO.inspect . To answer your question directly, for the moment I am "editing" the testbed but ultimately users should be able to create one with a chosen group and change them. "Do you want a new group to be created with the given name or do you want to attach an existing group?" I'll probably create new groups in the** generated** table page and once created, let users assign them from the choices they have. This makes it simpler for now. So the answer is "attached a testbed to an existing group"

[terse vapor]

the select/drop down is the right way to go then I think, without worrying about inputs_for for now

use f[:group_id] as your field and render a select input with a list of all groups, and it will render the form with the correct group selected.

[prime pawn]

Cool , I used input_for just to do it and get my hands on it.

Now I know that is how to render belong_to data. I have no idea how you would know that as the docs do not seem to spell it out.

[terse vapor]

that will display the name you wanted, but it won't be useful when submitted

[prime pawn]

I understand

[terse vapor]

which docs?

[prime pawn]

The one you linked to, it just looks like a big blob of text

[terse vapor]

I think it's because all these libraries are very separate from each other, and work in much wider scenarios than just ecto

[prime pawn]

I just can't learn trying to understand that , that's why each time I learn something (like this) I just document it in my own words

[terse vapor]

I understand, feel free to keep asking questions and people in this server will try and help

[prime pawn]

In LiveView the interaction between data and forms seems a bit easier for me to understand. If I needed to get this nested data in a LiveView, I don't have problems understanding the relationship between data and forms as I mostly try to use generic HTML-looking forms. I have experience with SVELTE, REACT and JS so LiveView feels similar. The mental context shift of understanding the relationship between the Generated forms and passing data around is a barrier for me. I want to keep using the genrators even though I read experienced Phoenix developers say not to. I'm not experienced and I figure if I understand the patterns in the Generators it would put my on solid footing. I'm urious what you think about that approach - using the Generators as a template to learn from