I found that this approach has several drawbacks: Record, and each step was hidden until you hit “next”, so every change in the It was a single that handled all the fields for the database-backed Show that managed state in multiple places. Eventually, this LiveView became an ugly 1000+-line horror I was still trying to figure out what I wanted on the form and still learning
Let me share with you my journey and some techniques I This is accomplished without any AJAX calls, no SPAs, and no page reloads. A great example is a form, especially long-running or multi-step forms. Some of common front-end logic into the backend, where the source of truthīelongs.
One of the benefits I love about LiveView is that it enables me to consolidate Phoenix LiveView with some Vue sprinklings has been the most enjoyable tech Looking at it for your next web application.
PHOENIX LIVEVIEW FORM REGISTRATION
In this case, we want to trigger the form submit, and log the new user in, after saving their registration data in the database without errors if this doesn't happen, the action should not trigger, and instead we need to keep our LiveView connected and display any generated errors.Phoenix LiveView has been a dream to work with so far. We can make an HTTP route call to a controller when the form is submitted by adding the :action attribute to our forms, specifying the URL we want to use.Īnd the :phx-trigger-action attribute allows us to make form submission conditional on some criteria. So writing data in session can't be done directly from a LiveView.Ĭan we call the controller's :create action from our LiveView form, and have it write the data for us? And can we make sure that happens only once the new user's registration process is complete: their data validated and saved? Solution Why is this important? Because session data is stored in cookies, and cookies are only exchanged during an HTTP request/response. The LiveView lifecycle starts as an HTTP request, but then a WebSocket connection is established with the server, and all communication between your LiveView and the server takes place over that connection. This means saving the session data from within the LiveView-and only after the new user is finished signing up and you're happy for them to have access to the app. You continue building your authentication system and decide that once a user signs up, using a form in a LiveView, they should be automatically logged in. generate_user_session_token ( user ) conn |> put_session ( :user_token, token ) |> redirect ( to: signed_in_path ( conn )) end end SessionController do use MyAppWeb, :controller def create ( conn, %) do token = Accounts. You can create a Phoenix controller with a :create action that generates a token, then saves it in the session using functions of the Plug.Conn module:ĭefmodule MyAppWeb.
The obvious solution is to store this token or unique identifier in the session. This can be a token or some unique identifier, and it needs to persist even as the user navigates around your app and different LiveViews get created and destroyed. Have you ever wanted to use LiveViews for a site's authentication? Among many other implementation details, you need to save some data to identify the logged-in user.
PHOENIX LIVEVIEW FORM HOW TO
If you want to deploy a Phoenix LiveView app right now, then check out how to get started. This is a post about getting a form in a LiveView to invoke a Phoenix controller action, on your terms.
0 kommentar(er)
