# 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 Svelte 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. Svelte behandelt keinen key wie den idx als key. Sprich ursprünglich gab es 3 Elemente El1, El2, El3. Wenn nun El1 entfernt wird, wird in der DOM tatsächlich El3 entfernt, da 2 ja nun der key ist, der nicht mehr existiert (idx 2/element 3) 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
