Editing Bookmark / Reply Titles with HTMX
by
This post is a followup to Allow editing of replies/titles and describes some of the changes made to enable this functionality (#265) and my thoughts after my first steps with HTMX.
Above is the before state, which is a static view of title/url of a bookmark/reply. Below is aΒ gif of what I built and the finished state. There's a new change button, which you can click to reveal a form that allows you to edit the record. This form allows you to save or cancel. Save updates the record and changes the screen back to the "read only" view, while cancel just loads the current "read only" view. Zero custom Javascript.
Powering this is two new simple views in the admin site. One loads the entry's bookmark/reply and returns the read only view. The other loads the same record and displays a form on get, updates it on post.
The htmx and these two small views were the simple part of this feature. The heavier lift was decoupling the Tanzawa micropub endpoint from the admin views/forms, and then updating the admin views to no longer expect IndieWeb extension data (reply/bookmark url/titles etc...) on update (it's still required on create).
Thankfully I had functional tests for my micropub endpoint, so I could be confident that my refactoring didn't break existing functionality. Those tests allowed me to extract the logic from the admin forms and put them into a application function. This new application functions are reused by all interfaces creating/updating entries.
The next phase was adding tests to the admin views and then updating them to use the common application functions. This work was mostly a slog because I needed to add tests and better factories for my tests before doing the actual refactor. There's still more improvement that can be made in the test factories to make them a bit more DRY, but they're good enough for now.
Working with HTMX has been a dream. Rather than usingΒ Javascript to tweak DOM, I can simply make calls to the backend to get html from the backend by adding just a couple of attributes to my template dom. All of this using the same django templates.
My next steps with HTMX are going to be to look into integrating django-components, so I can wrap up the Javascript I do need with the their templates/css and do some more refactoring. For example, right now reply/bookmarks have effectively the same templates / views duplicated. Using components, I should be able to have a single logical component to power both.
If the components strategy works, I will look at breaking out various parts of Tanzawa into htmx/django-components for easier maintenance e.g. the location selector or location view on the bottom of checkins.
Above is the before state, which is a static view of title/url of a bookmark/reply. Below is aΒ gif of what I built and the finished state. There's a new change button, which you can click to reveal a form that allows you to edit the record. This form allows you to save or cancel. Save updates the record and changes the screen back to the "read only" view, while cancel just loads the current "read only" view. Zero custom Javascript.
Powering this is two new simple views in the admin site. One loads the entry's bookmark/reply and returns the read only view. The other loads the same record and displays a form on get, updates it on post.
The htmx and these two small views were the simple part of this feature. The heavier lift was decoupling the Tanzawa micropub endpoint from the admin views/forms, and then updating the admin views to no longer expect IndieWeb extension data (reply/bookmark url/titles etc...) on update (it's still required on create).
Thankfully I had functional tests for my micropub endpoint, so I could be confident that my refactoring didn't break existing functionality. Those tests allowed me to extract the logic from the admin forms and put them into a application function. This new application functions are reused by all interfaces creating/updating entries.
The next phase was adding tests to the admin views and then updating them to use the common application functions. This work was mostly a slog because I needed to add tests and better factories for my tests before doing the actual refactor. There's still more improvement that can be made in the test factories to make them a bit more DRY, but they're good enough for now.
Working with HTMX has been a dream. Rather than usingΒ Javascript to tweak DOM, I can simply make calls to the backend to get html from the backend by adding just a couple of attributes to my template dom. All of this using the same django templates.
My next steps with HTMX are going to be to look into integrating django-components, so I can wrap up the Javascript I do need with the their templates/css and do some more refactoring. For example, right now reply/bookmarks have effectively the same templates / views duplicated. Using components, I should be able to have a single logical component to power both.
If the components strategy works, I will look at breaking out various parts of Tanzawa into htmx/django-components for easier maintenance e.g. the location selector or location view on the bottom of checkins.