Getting tasks working, part 3

My UI sucks. My codebase is cactus. But we must remember the power of the indomitable human spirit.

He’s making a list, he’s checking it twice

I’m doing the same thing over and over again for each new feature but I’m still being quite slow. I’m going to formalise the process so then I can follow the steps blindly and turn my brain off and listen to podcasts or something while I work on the features. Here is that formalisation:

New Basic Feature Procedure, HTMX Edition, v1.0

Draw a simple state diagram for the feature as it should appear to the end user. HATEOAS is your friend.
Identify all components that issue HTTP requests in each state ("trigger components"). Annotate triggers with desired custom behaviour (e.g. on hover, debouncing).
For each unique HTTP request, determine an appropriate URL and HTTP verb. Reusing URLs for different verbs is acceptable and even smiled upon. For each such URL, create the appropriate entry in the appropriate urlconf.
For each state, create a template that represents it. For each trigger component in that state, add the appropriate HTMX attributes that issue requests to the appropriate step 3 URLs and perform the desired kind of swap with the desired behaviour as per annotations.
For each URL in step 3, create a view that renders the appropriate state template in step 4, handling errors gracefully.

If we follow these steps for the variation of the Click to Edit pattern I'm working on now:

Steps 1 and 2: Make simple state diagram, annotating trigger components.

These states apply to all individual nodes independently of each other. The relevant URLs should incorporate the node IDs.

Base state: Individual node component as it currently stands. All existing trigger components, plus:

Node text: when clicked, issues a GET request that transitions the node to state 2.

Edit state: Individual node component with all actions disabled and the node text changed to an <input type="text"> element, and the additional trigger components:

Save button: when clicked, issues a PUT request that transitions the node to state 1 (modifying the node text in the database).
Cancel button: when clicked, issues a GET request that transitions the node to state 1 without making any changes.

Step 3: Add URLs to the urlconf that handles /app/node.

“editnodetext”: corresponds to the first GET request above. /app/node/<uuid:pk>/text/edit
“handlenodetext”: corresponds to the other GET request and the PUT request. /app/node/<uuid:pk>

Actually, “handlenodetext” already exists in our codebase as “node”, corresponding to the get_node view. So we need to change this to handle_node and add the PUT request handling.

Step 4: Create templates.

The base state template already exists; we need change its text span to be a trigger element that GETs “handlenodetext”.

We need to create the edit state template according to the above spec.

This is annoying because the base node template is horrifying copy-pasted spaghetti code now. Really need to refactor with some clever template work!! But it’s still horrifying for the time being.

Step 5: Create views.

We're modifying one view (get_node → handle_node) and creating a new one (edit_node_text).

Result:

GIF that demonstrates editing tasks via the workflow described in the text. — Excuse the styling bug for the left borders of the tasks—will fix—and the screencast cutting off early for some reason.

Underwhelming! But the formula works.

(Version v1.0.1 will add a “write tests for the views” step.)

Hey, it’s probably more natural to just automatically save the change when the user clicks off. (If we do that, would we even need the cancel button?) It would also be neat to make your cursor immediately go to where you clicked when you edit, and we need to do input validation so users can’t change the node text to be empty, and the styling needs a lot of work, but! I think I should refactor the templates before doing anything more with this.

Actually, what do we need to work on next?

What we need to work on next

- (B) Get settings working to a basic extent
  - Determine and implement a proper backend settings model
  - Implement changing nickname (as warmup)
  - Implement basic scheduling options
* (B) Get scheduling working
  - Figure out what to do here (planning)
    # We currently have a database of all tasks. Need to add more metadata to task lists wrt scheduling parameters
    # Revisit CLI version's behaviour (and what didn't work/what features were missing!)
    # Add placeholder support for calendar data (scheduleable hours)
    # Remember: (pre-processed) calendar + scheduleable tasks -> schedule.
    # Convert tasks into scheduleable task chunks on trigger
    # Display "next up" tasks on the dashboard, see how it feels, go from there
    # Draw this all up with pen and paper. Do the HTMX design procedure!
  - Make edits to existing backend models and create new ones; roughly define interactions
* (C) Annoying things to fix!
  * Quality-of-life features
    * Make separate "add task" button work
    * Make adding comments work
    * Make it possible to delete tasks
    * Make it possible to click-and-drag to rearrange tasks
    * Make it possible to edit priorities, prefixes, etc. on rendered text
    * Add keyboard navigation and shortcuts?
    * Generally, make working with the rendered text more pleasant
      # May need to significantly overhaul considering I much prefer editing the text directly
      # ...That is to say, the UX of editing the text directly is the minimum bar to achieve
      # Maybe just make task rendering much more text-like a la TaskTXT?
      * Characterise typical high-level user actions (e.g. creating a new task) in terms of their keystrokes
      * Record self making edits to source text and understand behaviour/keystrokes in terms of higher level actions
      - Synthesise collected data into a better UX approach
      # May need to move away from HTMX!
  * UI improvements
    * Display priorities and other task tags as badges
    * Improve node text editing UI
    * Better UI pattern for frontend tasks? (See QoL features above)
      # emergent pattern: supertasks/parent tasks as task categories?
  * Bugs
    * Fix "Show completed tasks" bug
    * Fix objectively incorrect task dependency styling (left border, highlighting, etc.)
  * Code hygiene
    * Refactor horrifying `tasks/templates` spaghetti code
    * Install coverage.py
    * Write basic tests to cover all existing views
    * Handle 400 Bad Requests properly on client side

A scared hamster with the text 'I got this. Seriously I'm got this.' — :-)

I think the best approach is to alternate between doing two core things and fixing one annoying thing – a balance between expansion and consolidation.

But I think this webpage is useful to reference directly online, so I’m publishing it now. Hi!