Fix readyState check#3365
Fix readyState check#3365wxiaoguang wants to merge 1 commit intobigskysoftware:devfrom wxiaoguang:fix-readystate-check
Conversation
|
See #2264 This issue has been attempted to be fixed many times. We used to have the exact same change you are proposing in place but there were issues this caused with extensions being loaded in the wrong order causing issues which lead to the current implementation. There was attempts to fix it but this just caused other regressions. Right now the current implementation works for all users who are not trying to load htmx via non standard async methods when it really should just be loaded like a normal script to keep things simple. There was a proposal to implement a custom initialize function that could be called manually by users with weird edge cases to trigger the load at a different time but this may not have been easy to implement and looks like it has not happened. |
|
Could you elaborate which case leads to "extensions being loaded in the wrong order causing issues"? If I understand correctly, the old code does this:
The the new code:
Which case would make new code doesn't work? |
|
Hopefully the tricky (and problematic) designs could be fixed. |
|
I think we need to add a note about this to the quirks page. |
|
TBH I am going to stay away from htmx ..... too many quirks and unsuitable for a large project. |
Description
See MDN: https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
loading -> (prepare DOM tree) -> interactive (DOM tree is ready) ->
DOMContentLoadedevent -> (load sub-resources such as scripts, images, stylesheets and frames) -> complete ->loadeventWithout the fix, there is a bug: if the
htmxis loaded inDOMContentLoadedwithreadyState="interactive"(for example: async chunked import) , then htmx will not initialize.Checklist
masterfor website changes,devforsource changes)
approved via an issue
npm run test) and verified that it succeeded