windexoriginal
- Why is there !!@current_scope on line 33 of the generated code? What is this accomplishing?
- Why is there a :let={f} on line 26? I see that is accessed on line 34, but I don’t understand why we can’t just use @form here and avoid the let?
For context here is are lines 25-44 of the generated login page:
<.form
:let={f} #why the let binding?
for={@form}
id="login_form_magic"
action={~p"/users/log-in"}
phx-submit="submit_magic"
>
<.input
readonly={!!@current_scope} #why the double negation?
field={f[:email]}
type="email"
label="Email"
autocomplete="username"
required
phx-mounted={JS.focus()}
/>
<.button class="w-full" variant="primary">
Log in with email <span aria-hidden="true">→</span>
</.button>
</.form>
This pattern is repeated for the second form for logging in with email and password. I’ve searched through the Phoenix documentation and I haven’t found anything helpful. I’ll admit I don’t grok the :letspecial attribute 100% so maybe that is the source of my confusion.
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 6- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
codeanpeace
Probably to handle
nilvalues so when@current_scopeis not explicitly set, thereadonlyattribute gets set tofalse.I think it’s so that the login form submission can degrade gracefully by falling back to a regular HTTP request via the url specified by the
actionattribute.garrison
The login is always submitted via POST, the LiveView is just used for validation.
I don’t think that has anything to do with the
:letthough (unless there’s something I’m unaware of). It was changed from the@form[]syntax in this PR by @steffend - it’s a large diff with a lot going on, so it’s possible it just got left in as an oversight. Or perhaps it does something I’m not aware ofThe docs discourage the use of
:leton forms because it disables the fancy field change-tracking they added in LV1.0.steffend
The
:letis there because otherwise the inputs would have duplicate IDs, as we render the form twice. Another solution would be to assign two separate forms that already have an ID set.codeanpeace
Good to know, any idea what’s the purpose of
phx-submit="submit_magic"in that case?windexoriginal
My mind was in Elixir land where, in most cases, transforming
nilintofalsewouldn’t matter, but this makes sense for an HTML attribute.Thanks for the insight. I can say that the two form solution would be easier for me to read, but I’m glad to have learned something about reusing forms.
garrison
The form is submitted to the LiveView first for validation. If it passes validation, the LiveView uses phx-trigger-action to submit the form via POST to the session controller.
The form has to go through a POST because LiveView can’t set the session cookie. Only an HTTP request can set an HttpOnly cookie (the cookie is HttpOnly for security reasons).