bigskysoftware / bigskysoftware/htmx

[4.0.0-beta6] No event after hx-disable re-enables element; simple focus() after request is no longer possible

Open
#3,947 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
49.4k
Forks
1.7k
Avg merge
3d 22h
Merged PRs (30d)
30

Description

In Four, `hx-disable` controls remain disabled throughout `__issueRequest` with no event fired after they are re-enabled. The issue-request sequence is roughly:

- disable elements
- `htmx:before:request`
- await fetch
- `htmx:before:response`
- await response.text()
- `htmx:after:request`
- `htmx:finally:request`
- re-enable disabled elements

https://github.com/bigskysoftware/htmx/blob/85b8378db6ddfe964066017ae63a4cc57827f3e2/src/htmx.js#L579-L662

---

`hx-disable` exists to prevent the user from interacting with the form while a request is in flight. One obvious thing one might want to do after the request is completed is re-focus the form element so the user can continue, say, typing in todo list items.

Without any event after the disabled status is removed, this kind of workflow becomes awkward to implement:

```html

hx-on:htmx:after:request="find('form').reset(), setTimeout(() => find('find input').focus(), 0)"
>
```

---

It would be nice if there were some event that fired after the elements are re-enabled.

A few ideas:

- Move enableElements call to before the `htmx:finally:request` event. This would be my preference; IMO "finally" should be fired after all default request behavior is completed.
- Add a new event that fires after all default request behavior is completed. `htmx:finallyfinally:request` (joke)
- Add `hx-disable`-specific event(s): `htmx:{before,after}:{disable,reenable}`. Maybe just `htmx:after:reenable`

---

Related issue: #3363

Contributor guide

Open the contributing guide

Research direction

Start in src/htmx.js around lines 579-662 and trace the __issueRequest sequence, especially the ordering of htmx:after:request, htmx:finally:request, and re-enabling hx-disable elements. Review the related issue #3363 and choose a completion point consistent with the existing event model. Done means a documented event or ordering reliably lets listeners act after the elements are enabled, including the focus workflow described here.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.