One of the sources I like to use is Skypack. Since I don’t want to add the library to my javascript bundle, I need to import it from an external source. Since my entire site is a LiveView site, I want to set this up by using a LiveView hook. This works by adding an event listener to the click event on the copy button. For this I use the library which is available as a NPM package but I prefer to keep my bundle as small as possible.
#Phoenix liveview hooks code#
On the top right in the code box, there is an icon that when you click on it, it copies the entire code snippet. The first example is when a user wants to copy a snippet of code.
On my new site, I use this in a couple of places. This is a pattern that I have started to follow recently and that I feel good about.
#Phoenix liveview hooks download#
In this tutorial, I want to show how I use option two, import the javascript from external CDN:s and use that in conjunction with Phoenix LiveView to avoid having the user to download a larger javascript bundle that is not needed on most pages. The solution for this is to either setup your javascript build system to output several bundles that you can include on the pages you want or import the script files from the CDN sources on the pages you want and then use them in your code. There are quite a few changes here so I added a mini FAQ.In most applications you have some page specific javascript that is only used in one or just a few pages. That means we’re responsible for setting the user before we get to the changeset, which requires a few more changes to the context and the associated tests, namely converting the arity of create_user_phone_number/1 to create_user_phone_number/2: - def create_user_phone_number ( attrs \\ % assert_receive ^ user_event end As that variable contains user-supplied data, we can’t trust it to enforce security. Note that we don’t pass the user_id in as attrs. You can see the migration correctly references the users table: add :user_id, references ( :users, on_delete : :nothing )īut we need to change the schema: schema "user_phone_number" do field :phone_number, :string - field :user_id, :id + belongs_to :user, timestamps ( ) end false def changeset ( user_phone_number, attrs ) do user_phone_number |> cast ( attrs, ) - |> validate_required ( ) + |> validate_required ( ) end (Note: the table should have been called user_phone_numbers, but I didn’t notice this typo until several commits later) mix ContactInfo UserPhoneNumber user_phone_number phone_number:string user_id:references:users
We can use the generators to get running quickly, but we’ll need to make a couple changes to ensure the user is being set correctly. mix phx.serverįor this demonstration, we’ll create a user_phone_number, which is just a phone_number associated with a user. I also added support for authentication using mix : mix Accounts User usersĪt this point, you should be able to start the app and Log in. Note: These instructions use phoenix v1.6.6 and liveview v0.17.5 mix phx.new liveview_pubsub_demo I’ll create a new application and document the steps in this tutorial as distinct commits. As Severus is a phoenix application, Livewiew made this requirement easy, but hooking it into Ecto took a little work.
Perform optimistic updates and transitions via JavaScript commands () Code reuse via stateful components. phx-hook is included for the cases where you have to write JavaScript.
#Phoenix liveview hooks update#
In an ideal world, that update would be instantaneous, and not require a browser refresh. Phoenix LiveView enables rich, real-time user experiences with server-rendered HTML. If one user updates their phone number, their connections should see that update. The initial MVP of Severus is as platform to keep contact information up to date.
0 kommentar(er)
