New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI: revert PJAX to 5.11 behaviour #4337
Conversation
|
||
// handle redaxo links to pages other than current page | ||
// hint: check global `rex.page` variable | ||
// hint: use custom `data-pjax-cancel-request` since `data-pjax-state` would be overwritten |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wann soll man jetzt data-pjax-cancel-request
notieren? Und warum?
data-pjax=false haben wir ja auch noch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data-pjax-cancel-request
wird nur von uns intern benutzt, wenn wir nach Prüfung feststellen, dass ein Element nicht das dynamische Laden von PJAX auslösen soll. Habe es gerade im nachfolgenden Kommentar ausführlich beschrieben.
Ein eigenes Data-Attribut deshalb, weil PJAX sein data-pjax-state
eigenständig überschreibt, ohne dass wir es vorher auswerten konnten.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Achso, und du hast natürlich recht, @staabm, wir nutzen bereits das data-pjax
-Attribut. Das wird aber initial als Selector verwendet und nur auf false
geprüft. Ich habe dieses neue data-pjax-cancel-request
eingeführt, weil ich hinterlegen wollte, was der Grund fürs Cancel ist, falls man zukünftig darauf noch weiter eingehen wollte.
Okay, ich bin mit den Anpassungen durch und möchte aber anmerken, dass ich nur einige Situationen getestet habe, die REDAXO mir standardmäßig mitbringt. Also die typischen Core-AddOns, das Speichern von Formularen, Editieren von Inhalten, usw. Ich bin über eine Sache bei PJAX etwas unglücklich und hadere sogar im Stillen, ob wir den Switch wirklich vorgenehmen wollen, oder ob wir vorerst doch lieber wieder auf die alte jQuery-PJAX-Lib zurückwechseln wollen: Die neue Lib funktioniert so, dass es die angegebenen Selektoren verwendet werden, um mittels querySelectorAll Unser Problem ist, dass wir bei Klick auf unsere Links gerne noch selbst prüfen möchten, ob das Ziel dynamisch geladen werden soll. Beim Wechsel der Seiten ( tl;dr: Es fehlt also eine sinnvolle Möglichkeit, nach dem Klick auf ein PJAX-Element den Ladeprozess zu umgehen. Wenn sich nun nach Tests zeigt, dass alles funktioniert wie es soll: Okay, dann könnte man die neue PJAX-Lib verwenden. Ich habe nur etwas Sorge, dass manche AddOns oder deren Nutzer mit Event-Konstrukten arbeiten, die nicht mehr erreicht werden, weil zuvor entweder PJAX eingegriffen hat oder wir bereits einen manuellen Ladevorgang angestoßen haben. |
Also ich habe mir das technische Problem noch nicht weiter angeschaut. Erstmal nur so allgemein: Einerseits fände ich es natürlich sehr schade, wenn wir deine ganze Arbeit wieder rückgängig machen würden. Vor allem, weil es ja eine von allen gewollte Richtung ist (modernere PJAX-Lib, ohne jQuery). Bin mir unsicher. |
Ich denke wir sollten eine längere beta starten und auf feedback von den testern warten, um zu sehen wie problematisch es ist |
Danke für euer Feedback! Ich habe etwas Sorge, dass wir im Main-Branch nun mit der neuen PJAX-Lib weiter laufen und womöglich beim Testen mit Nutzern bemerken, dass es in manchen Situationen klemmt. Dann wären wir im Zugzwang, die Probleme fixen zu müssen, und müssten dafür womöglich die Lib anpassen. Die Lib ist zwar neuer und moderner und vor allem ohne jQuery, allerdings wird sie auch bereits nicht mehr wirklich gepflegt. Alle Maintainer kümmern sich inzwischen um andere Themen und haben kein offensichtliches Interesse mehr an PJAX. Aufgrund der im letzten Kommentar genannten technischen Dinge habe ich das Gefühl, dass wir selbst eingreifen müssten, um PJAX für REDAXO tauglich zu machen. Es fehlt uns wie beschrieben die Möglichkeit, nach Prüfung den Ladeprozess abzubrechen. Und eben habe ich bemerkt, dass auch der Umgang mit Ankern/Hashes in der URL ungünstig ist: Speichert man in REDAXO einen Slice ein zweites Mal, hakt PJAX aufgrund des Hashes aus, so dass das Formular klassisch abgeschickt wird und die Seite manuell lädt. Mein Bauchgefühl ist deshalb:
Mein Vorschlag wäre deshalb, diesen PR zunächst zu mergen und anschließend den Stand in einen neuen WIP-Branch auszulagern. Einen neuen PR aufsetzen, um aufs alte jQuery-PJAX zurückzuwechseln. |
Die Sorge ist schon nicht ganz unberechtigt, denke ich.
Das ist auch etwas, was mich bisschen stört. Also dass wir zu einer Lib wechseln, die auch nicht so richtig mehr weiterentwickelt wird. Bloß halt nicht schon ganz so lange, wie unsere bisherige. Also ich glaube, ich würde daher Dirks Vorschlag folgen. Auch wenn ich mir weiter unsicher bin. |
Dem stimme ich zu. Wir sollten das doch lieber zu einem späteren Zeitpunkt angehen. Ich schmeiß dann noch gleich ne Alternative in den Ring https://htmx.org/ |
TODO:
page
-Parameter in URL vergleichen und PJAX nicht nutzen, wenn eine andere Seite aus dem Contentbereich heraus geladen wirdfixes #4335