Note, that I want to preload variants in the specific order they where created in. |> Repo.preload(variants: from(v in Variant, order_by: v.id)) Open lib/tutorial/products.exĪnd change def get_product!(id), do: Repo.get!(Product, id) to: def get_product!(id) do However, if the lines are persisted and I edit the lines, I need to be able to mark them as being deleted.įirst thing I need to do is to preload variants when I get one product. I also want to be able to remove individual lines that are not yet persisted. I want to the form to be able to add dynamically add several lines of variant forms and save them in one shot.
Phoenix liveview form how to#
The topic for this tutorial is to show you how to setup a nested model form with Phoenix LiveView where you can add and remove fields on the fly. But what I didn’t go through was to setup a form where you can manage the variants.
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.I my last article, I set up a relationship between products and variants. 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. 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)
