3.7 KiB
Bekannte Probleme im Entwicklungsprozess mit TibiCMS
In diesem Abschnitt werden bekannte Probleme während des Entwicklungsprozesses mit TibiCMS beschrieben und Lösungsansätze aufgezeigt. Sollten ein Problem auftauchen, welches hier nicht beschrieben ist, ist es gerne gesehen, wenn dieses Problem hier dokumentiert wird.
Probleme mit CollectionEntry Objekten
Problemstellung
Wenn ein Objekt vom Typ CollectionEntry zurückgegeben wird, zeigt sich teilweise eine eingeschränkte Kompatibilität mit JavaScript. Beispielsweise funktioniert die push-Methode nicht bei Attributen, die einen Array-Datentyp speichern.
Ursache
Die Problematik entsteht durch die Übersetzung des Objekts von Go nach JavaScript. Hierbei werden die Attribute nicht als native JavaScript-Objekte, sondern als Go-Objekte übersetzt, was zu einer eingeschränkten Kompatibilität führt. Insbesondere unterstützen sie nicht gängige Methoden wie push, pop etc. Ein weiteres Problem ist, dass bei diesen Inkompatibilitäten keine Fehlermeldungen generiert werden, sondern schlichtweg keine Aktion erfolgt.
Lösungsansatz
Beim Manipulieren von CollectionEntry-Objekten innerhalb eines Hooks sollte man zur Sicherheit eine tiefe Kopie (Deep Copy) des Objekts erstellen, um es vollständig in ein JavaScript-Objekt zu konvertieren. Die Verwendung von {...} reicht hierbei nicht aus, da dies nur die oberste Ebene des Objekts konvertiert. JSON.stringify und JSON.parse sind nur dann zu empfehlen, wenn die Reihenfolge der Attribute irrelevant ist. Für Fälle, in denen die Reihenfolge wichtig ist, existiert bereits eine spezielle Funktion, die dies beibehält. Diese Funktion ist unter dem Namen „obj2str“ in der Utils-Datei zu finden.
Warum die Ursache nicht behoben wurde
Die Ursache wurde nicht behoben, da die Standardmäßige, uneingeschränkte übersetzung von Go zu JS einen performancemäßigen totalschaden darstellt.
Probleme mit SSR kompilierung
Problemstellung
Website wird nur teilweise oder gar nicht gerendert.
Ursache
In meinem Fall war das Problem, dass ein Button element in einem anderen Button Element enthalten war. Dies hat dazu geführt, dass der Compiler manchmal die Vollständige Seite nicht gerendert hat, manchmal auch nur vereinzelte Elemente.
Lösungsansatz
Semantisch arbeiten.
Warum die Ursache nicht behoben wurde
In dem fall liegt der Programmcode fehler nicht bei uns, da die Kompillierung von svelte übernommen wird.
Probleme mit Variablen werten in #each loops
Problemstellung
Wenn in einem each block die länge der liste, über die iteriert wurde, verändert wird, kann es zu fehlern kommen, wenn kein einzigartiger key für jedes element angegeben wurde.
Ursache
Die Ursache ist, dass svelte die liste nicht neu rendert, sondern nur die die properties neu zuordnet. Sprich ursprünglich gab es 3 Elemente El1, El2, El3. Wenn nun El1 entfernt wird, wird in der DOM tatsächlich El3 entfernt und die properties von El3 zu El2 und von El2 zu El1 zugewiesen. Das bedeutet, dass nicht reaktive variablen weiterhin den Wert von der vorherigen Komponente beeinhalten!
Lösungsansatz
Die einfachste Lösung wäre eine Id als key zu haben, die einzigartig für das jeweilige Element ist, da svelte dann in der DOM genau das Element entfernt und nicht das letzte. Hat man das nicht und möchte , dass der inhalt bei Veränderung der Array länge tatsächlich neu gerendert wird, so muss man explizit ein {#key} block drum rum bauen mit den jeweiligen Wert wo es neu gerendert werden soll (key nutzt ebenfalls reactive statements....).
Warum die Ursache nicht behoben wurde
Gibt keine Lösung, da es standard Svelte verhalten ist. Gibt nur den vorgestellten workaround