HTMX CSQL Fixture UI

[esoergel]

Product Description

Technical Summary

Feature Flag

Safety Assurance

Safety story

Automated test coverage

QA Plan

Migrations

• The migrations in this code can be safely applied first independently of the code

Rollback instructions

• This PR can be reverted after deploy with no further considerations

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[AddisonDunn]

Looks like a great approach, very smooth and simple.

[biyeun]

Suggested change

	<form hx-post="{{ request.path_info }}"
	hq-hx-action="save_expression"
	hx-swap="outerHTML"
	x-data="{ isUnsaved: false }"
	@change="isUnsaved = true;"
	@submit="isUnsaved = false;">
	<form
	hx-post="{{ request.path_info }}"
	hq-hx-action="save_expression"
	hx-swap="outerHTML"
	x-data="{ isUnsaved: false }"
	@change="isUnsaved = true;"
	@submit="isUnsaved = false;"
	>

[biyeun]

Suggested change

	<button type="submit" class="btn btn-outline-primary" x-bind:disabled="!isUnsaved">
	<button
	class="btn btn-outline-primary" type="submit"
	:disabled="!isUnsaved"
	>

1. I like to always have class be the first attribute
2. if there is a HTMX or alpine attribute (:bind in this case), we want it on a second line
3. I prefer shorthand alpine bindings, but could be convinced otherwise?

[biyeun]

Suggested change

	<button class="btn btn-outline-danger"
	hx-post="{{ request.path_info }}"
	hq-hx-action="delete_expression"
	hx-swap="delete"
	hx-target="closest form">
	<button
	class="btn btn-outline-danger"
	hx-post="{{ request.path_info }}"
	hq-hx-action="delete_expression"
	hx-swap="delete"
	hx-target="closest form"
	>

[biyeun]

Suggested change

	<button type="button"
	class="btn btn-default"
	hx-post="{{ request.path_info }}"
	hq-hx-action="new_expression"
	hx-target="#csql-fixture-rows"
	hx-swap="beforeend">
	<button
	class="btn btn-default" type="button"
	hx-post="{{ request.path_info }}"
	hq-hx-action="new_expression"
	hx-target="#csql-fixture-rows"
	hx-swap="beforeend"
	>

[biyeun]

yes, this was exactly the approach i was thinking when reviewing the page with @AddisonDunn. Less front end logic being front-loaded from the backend into Alpine, and more on the python side.

[esoergel]

Yeah, I was super pleased to see how well this plays with Django templates! I'm still not totally sold on the second commit here though - I do think I liked it better before adding Django forms, but if I find the time I might try a compromise - like maybe I make a partial template with the <form> tags and the buttons, but have the fields themselves rendered by the Django form (at present, I set a custom template on the form, so it contains everything, which sounds nice in principle, but means I lose error handling in the template)