|> cast(attrs, ) # Add delete hereĭefp maybe_mark_for_deletion(%ĭefp get_temp_id, do: :crypto.strong_rand_bytes( 5) |> Base.url_encode64 |> binary_part(0, 5)
|> Map.put( :temp_id, (feature.temp_id || attrs)) # So its persisted + |> cast_embed( :features, with: &/ 2, required: true) |> validate_number( :price, greater_than: 0) |> validate_length( :description, min: 5) Modify pricing plan changeset in the same file, by adding cast_embed function that does the job: 1 + embeds_many :features, Feature, on_replace: :delete # add this line You can find an installation guide here: Īfter setting up a live view let’s add our features to the schema of a pricing plan: 1ĭefmodule do I used the second approach and the whole process is not complicated.
You can add a flag during project generation or setup it manually. Surprisingly to me, not every Phoenix app is ready to play with LiveView. To achieve my goal with Phoenix it took me a bit of time, so I decided to describe the process of adding this feature to my SaaS app. There are a few ways to achieve it with Elixir, after analyzing all of them the most efficient and the most Phonix-way in my opinion is the one that uses LiveView, one of the flag features of Web Framework that is getting more traction. The user experience perspective it saves a lot of time when adding data to the tables that have one-to-many relationships. Some community members considered this as an anti-pattern, however from To allow users to type all related data in one form we want to implement something that is called “Nested form” and is well known from other Web Frameworks - Ruby on Rails, thanks to a dedicated gem that handles it out of the box. Messages to the client.Every pricing plan needs to list of features. The LiveSocket with a custom channel that allow passing granular Using channels with LiveView for better UX.(but sadly not nice enough for my edge case). Using hooks and events to make LiveView and Alpine play nice together Integrating Phoenix LiveView with JavaScript and AlpineJS.If you enjoy reading about this topic, I encourage you to read those twoĪrticles I stumbled upon during my research on this subject. Pretty useful to documented as it’s pretty easy to implement and Iĭidn’t find anything similar online. Numerous attempts at dealing with that issue and I found it would be While I didn’t end up needing that method, I found this trick during my This gives pretty useful informations that can allow to hook to LiveView The first thing I thought about was to use LiveView hooks as documented Only then (to avoid the quick text flash mentioned earlier). Submission was completed so that I can make sure to reset the To deal with this, I wanted a way to tell from JavaScript when the form Is great, except it leaves us with the open even if the
#Phoenix liveview form update
The input state didn’t change, it doesn’t need to update the DOM. If we just added a bunch of spaces to the existing text and the backendĭecides to trim the value, Phoenix is smart enough to notice that since Phoenix resets the DOM to the and everything is good, but In the happy path where the form submission triggers a DOM update Processed by the backend and the DOM is updated, which causes a quick I don’t want to reset the state back to the on submission,īecause it would temporarily show the old text until the update is Submitted, it triggers a Phoenix event that might or might not update For reactivity, this is done in JavaScript. To give the context, I have a that is transformed to a Processed by the backend even if that event didn’t trigger a DOM Typically, I wanted to know when a form was done being submitted and Intercept some events from the LiveSocket to take specific action in Recently, I was dealing with a Phoenix LiveView where I wanted to
0 kommentar(er)
