![]() ![]() LiveView also has some strict requirements about the structure of the form in templates. You can learn more about that in the documentation. We also need to change how the form is rendered in its parent ( in our case): #. Now we need a module that will implement the server-side logic. It will generally have a function that is called when the LiveView establishes the connection and one or multiple functions that handle the events. Ĭef handle_event("change", % = Posts.update_post() The most interesting part in our case is the callback that reacts on changes in the form: #. terminate/2 callback will be called when the LiveView connection is terminated.This can happen for many reasons: timeout, the user navigates to another page, browser window is closed. In our case we are not interested in the termination reason (first argument).Whenever something went wrong we want to save the data. Post is saved using Posts.update_post/1 - exactly the same as we do in handle_event/3.What about new posts? Our approach assumes that the post already exists in the database and this is not the case on the create form. One way to solve this would be to save an empty post before loading the form, which is obviously not ideal. Proper solution would be to use one of the approaches that I already mentioned at the beginning - drafts, "forward" revisions. I hope that you will find this writing useful and maybe use auto save for one of your projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |