A user can log in, select a game to play, and even invite friends to play games with them. Imagine that you're responsible for a Phoenix web app, Arcade, that provides in-browser games to users. Check it out for an even deeper dive into LiveView testing and so much more.īefore we dive into writing any actual code, let's talk about the feature we'll build.
The form examples we'll be looking at in this post are inspired by the "Forms and Changesets" chapter in my book, Programming LiveView, co-authored with Bruce Tate. The Feature: Adding a Form to a Phoenix LiveView App
#Phoenix liveview form how to#
Along the way, you'll learn how to model change in your Phoenix application with schemaless changesets and compose LiveView code to handle that change. In this post, I'll show you how to build LiveView forms that validate changes and provide feedback to the user in real-time.
These days, users expect to see form feedback presented to them in real-time, and LiveView offers first-class support for exactly that. Some of the most common interactions on the web are form validation and submission. This can empower you to deliver interactive features in single-page apps faster than ever before. LiveView keeps the developer's mind firmly rooted on the server-side, even when testing and debugging. Built on top of Elixir's OTP tooling and leveraging WebSockets, it offers super-fast real-time, interactive features alongside impressive developer productivity. You can be running in minutes.LiveView is a compelling choice for building modern web apps. Fly.io ❤️ Elixirįly.io is a great way to run your Phoenix LiveView app close to your users.
#Phoenix liveview form password#
Then, we execute the controller action specified in the :action attribute using the follow_trigger_action/2 function, and we use new_password_conn to check that:ġ) The user's token was renewed with the new password.Ģ) The expected flash message was added to the connection.ģ) The user's password was updated. We build a form and pass it to the render_submit/1 function, which returns the new content of our LiveView after handling the phx-submit event so that we can assert that the phx-trigger-action option is added to the form. Test "Update password: renders errors with invalid data", %) assert render_submit ( form ) =~ ~r/phx-trigger-action/ new_password_conn = follow_trigger_action ( form, conn ) assert get_session ( new_password_conn, :user_token ) != get_session ( conn, :user_token ) assert get_flash ( new_password_conn, :info ) =~ "Password updated successfully" assert Accounts. It is useful if we want to test the contents of our LiveView right after handling the submit event.įor example, this form checks what happens if we submit a password-update form with a too-short password and a non-matching password confirmation: Verified routes can be used in tests too, Phoenix 1.7 will bring really cool stuff! The render_submit/2 function sends a form submit event and returns the rendered result. We can test the behavior of our LiveView when the event specified with the phx-submit option is handled. In this post we'll take a walk around some functions of the LiveViewTest module that come in handy for testing forms. In previous posts we've used forms for different purposes, but we've never talked about how to test that our app does the right thing when a form is submitted. If you want to deploy your Phoenix LiveView app right now, then check out how to get started. This is a post about a few functions to test that our app does what we think it does when a form is submitted.
0 kommentar(er)
