I would hope the controllers folder structure to be more organized like live, Organise files under *controllers* folder similar to *live* and context folder
But ya, we still can do this manually after generating files.
alaadahmed
1
shahryarjb
When we are using as like this:
<.simple_form for={%{}} as={:tag} phx-submit="save_tag" phx-change="validate_tag">
We should get it in our handle_event like this, okay?
def handle_event(
"save_tag",
{"tag" => %{"tag" => tag, "type" => type, "id" => id, "parent_id" => parent_id}},
socket
) do
But I got:
def handle_event(
"save_tag",
%{"tag" => tag, "type" => type, "id" => id, "parent_id" => parent_id},
socket
) do
Am I wrong in understanding as keyword?
It should be noted, I updated my mix file to phoenix 1.7 and after that I copied the
core_components.exfrom a fresh phoenix 1.7 installed
Other problem is, why we should pass value to input, when it is empty by default
<.input name="tag" label="Tag Name" id={"field-tag-#{@type}-#{@block_id}"} value=""/>
without value="" I have error, I can edit the core component or create new one to have this, but I am curious why it should be like this, Something like this is my preference
attr :value, :any, default: nil // or , default: ""
...
value={Phoenix.HTML.Form.normalize_value(@type, @value)}
0
amym114
I see where you have a file in your directory structure, live/home_live.ex. Can you show us what the contents of it would look like?
Basically I want to know, in a project created with default settings, are you envisioning that it is utilizing the same template file as the controller-based view since everything uses function components now (and you could choose in your router whether to use a live or controller-based view), or does it have its own render or colocated template?
I’m assuming the latter, but I want to make sure I’m not overlooking anything. The generated live files follow the pattern you outlined above of having their own directory and Index module etc. Thank you!
0
josevalim
Creator of Elixir
The point of passing as is that you will use a form struct to generate the inputs for you with the correct names and values. Therefore, you must do this:
<.simple_form :let={f} for={%{}} as={:tag} phx-submit="save_tag" phx-change="validate_tag">
And then pass field={f[:foo]} to your input. Alternatively, call to_form(%{}, as: :tag) in your LiveView and pass the result of to_form as for and use field={@form[...]}. In other words, you must let <.input generate the names for you.
6
LostKobrakai
I think this needs some better documentation or even warnings. I just ran into this as well updating a form to 1.7.0 and removing the :let={f} as per all the new documentation around using @form. It took me a solid while till I figured out why my as="form" was no longer working.
7
josevalim
Creator of Elixir
Can you take a stab at a PR? In a nutshell, as=... works, but you need to capture the form with :let. Unfortunately, there is no way for the component to know at the moment a :let was given or not, so the best we can do is document. Perhaps the best way to go about this is to deprecate as in the long term.
2
aiwaiwa
At least some of these prepositions are a bit ambiguous 
Beginning with for, it is generally used for comprehensions so it hints naturally, hey, write this:
<.form :for={f <- @form} phx-change="validate" phx-submit="save">
<.input field={f[:username]} type="text" />
instead of this:
<.form :let={f} for={@form} phx-change="validate" phx-submit="save">
<.input field={f[:username]} type="text" />
I guess the confusion is coming from using :for and an atom vs for as attribute, as they look so similar.
0
DaAnalyst
superchris
Eiji
No, there’s no such option. Even with --no-assets in core_components.ex there are still tailwind classes.
If you want to see all phx.new task options call: mix help phx.new
0