portmb.blogg.se

1. #PHOENIX LIVEVIEW FORM HOW TO#
2. #PHOENIX LIVEVIEW FORM CODE#
3. #PHOENIX LIVEVIEW FORM PLUS#
4. #PHOENIX LIVEVIEW FORM FREE#

You still need to sprinkle a little JavaScript here and there. 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

|> unique_constraint(:name, name: :variants_name_value_product_id_index)ĭefp maybe_mark_for_deletion(%īack in the form, I should now be able to add a new variant line:Īnd if I click the cross in the delete column, it should be removed.Document. |> Map.put(:temp_id, (variant.temp_id || attrs)) # So its persisted So, in the schema, add: field :temp_id, :string, virtual: trueĪnd in the changeset, change to: def changeset(variant, attrs) do And then in the changeset, look if that is filled in, and if so, delete it.įor my example, I also need another virtual field so I can keep track on the non persisted lines. To be able to delete a nested resource from a parent form, you need to add a virtual :delete field. Speaking of Variant, we need to do changes there as well. Make sure that has_many-relationship is setup. Now, when the attributes contain the "variants" key, the attached data will be handled of the changeset in the Variant-module. Open lib/tutorial/products/product.ex and in the changeset, add the line: |> cast_assoc(:variants) To be able for a product changeset to handle the variants, I need to tell the changeset do just that.

That ensures better UX when using the form later. 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. I my last article, I set up a relationship between products and variants.