However, LiveView isn’t meant to solve all of your problems.
#Phoenix liveview form code
For me, this significantly reduced the amount of JavaScript code I needed. However, I would encourage you to start migrating parts of your app to LiveView if it makes sense. Features, bugs and major revisions will likely come before any stable release. As you can see, architecting a LiveView app requires you to carefully understand the tradeoffs involved. But if another user posts a comment, the work to show/hide a reply form would be undone when the server sends an update/2 with new UI state. On the other hand, in showing or hiding the reply form, I could have went with toggling an HTML class directly with JavaScript rather than using state to manage its visibility. In this case, I want to allow users to submit a comment with their keyboard. In the repo, I used JavaScript to attach some listeners to each comment block! How dare I? Well, you will have to decide which parts of your app can be handled by JavaScript or LiveView.
#Phoenix liveview form free
If you are curious about any of the concepts, feel free to dive into the GitHub commit that contains the specific pieces to wire up this comment form.
#Phoenix liveview form plus
With both LiveView plus a little bit of JavaScript to add some event listeners, we have a working LiveView comment form. addEventListener ( 'turbolinks:load', function ( ) end end end JS.navigate( ~p"/products/ #, socket) do |> stream( :products, Products.list_products()) |> assign( :page_title, "Listing Products") Lib/mercury_web/live/product_live/index.ex: defmodule do use MercuryWeb, :live_view alias true def mount(_params, _session, socket) do Replace the contents or create the following files. Live "/products/:id/edit", ProductLive.Edit, :edit end Live "/products/new", ProductLive.New, :new We'll start from the generated code and we'll adapt it by adding the code from the official docs.Īdd the following routes to router.ex: scope "/", MercuryWeb do Let's write the code for file uploads manually following the official docs for live_file_input. (Find the code for this part on the phoenix-code-generator branch of the git repo) Official live_file_input docs That's reasonable because the code generators have no way to know that we intended the array of strings to be image URLs and that the input should have a type of file and be supported by the live_file_input component.Īs powerful as the generators are for CRUD pages, in this case, we need to do it by ourselves. We'll see that the generated code for the images attribute is an input field with type of select ( lib/mercury_web/live/product_live/form_component.ex): Our first attempt is to use the Phoenix code generators: mix Products Product products name:string images:array:string We'll use a simple migration and schema for a Product with two attributes: name and a list of images, stored as an array of strings. I'll name mine mercury: mix phx.new mercury -install Mix archive.install hex phx_new 1.7.2 -force Let's start by creating a new project with the latest Phoenix version. Keep reading to discover what I learned in the last couple of days trying to code this simple task. When editing a Product, you should be able to remove any of the already associated images and add new images to the Product, always respecting the limit of 3 images per product.Īnd given that Phoenix has pretty good code generators and LiveView now has an amazing live_file_input component that automates uploading files in an interactive way, it should be pretty easy to implement. Each Product has up to 3 images associated with it. Imagine you are writing an app to handle products for a marketplace.
0 kommentar(er)
