A different story however is, that there may be issues when third party scripts employ DOMContentLoaded, albeit these would be noticeable in most Ajax environments.
Here is a description of the problem, which in our own terms:
DOMContentLoaded relies on detecting page load after browser refresh and not after ajax/fetch request.
This is why jQuery's ready function has additions that covers ajax/fetch requests.
Whenever the former happens, our users could actually regard this as a bug.
We are thinking of generically patching this effect somehow.
Proposed solution(s):
One suggested approach is for Ajaxify to provide a built-in but public function onReady() that makes it easier to substitute calls to
EDIT: Fixed from version 8.1.3
We noticed, that when porting from the jQuery
ready()
event toDOMContentLoaded
, that jQuery does a bit more than just calling the latter.The new entry point of Ajaxify looks like this:
...where
run()
does the actual initialisation...(Source: https://www.sitepoint.com/jquery-document-ready-plain-javascript/)
There is no problem assumed with that.
The actual problem:
A different story however is, that there may be issues when third party scripts employ
DOMContentLoaded
, albeit these would be noticeable in most Ajax environments.Here is a description of the problem, which in our own terms:
Whenever the former happens, our users could actually regard this as a bug. We are thinking of generically patching this effect somehow.
Proposed solution(s):
One suggested approach is for Ajaxify to provide a built-in but public function
onReady()
that makes it easier to substitute calls toonReady()
source code:(This is hand-made code and obviously changes a bit of the browsers default behaviour)
onReady()
could be then used as follows :...becomes...
Is there a more "official" way of dealing with the problem already on the net?