Ahh, die Verbindung ist weg, man hört mich auf dem Video nicht… und es ist nicht das richtige Fenster aufgenommen worden… was für ein IT-Experte bin ich nur!
Ach Mist. Ich versuche es dieses Wochenende mit der Dokumentation, die du erstellt hast (ich habe irgendwo ein README oder einen Post gelesen) und sage dir Bescheid, falls ich mehr Dokumentation benötige.
Mist! 
Na gut, poste wenigstens deine Präsentation hier 
Die Präsentation ist hier
Sorry !! Ich bin gerade erst mit der Arbeit fertig geworden !! Naja, verpasst ^^ Also mache ich jetzt erstmal so wie @cicoub13 mit der Präsentation als Unterstützung und wir schauen uns das nochmal an !! Danke für all die Details in jedem Fall @AlexTrovato
Nach dem Merge des PR von @AlexTrovato zu den Cypress-Tests können wir nun Tests hinzufügen und mit der Migration zur neuen Version von preact-cli fortfahren, sowie einige etwas schwere Bibliotheken entfernen!
Zum Spaß habe ich mir angesehen, was im JS-Bundle viel Platz einnimmt
In den node_modules des Hauptbundles:
Ich bemerke, dass die Lib « vis » viel Platz einnimmt und vor allem nicht korrekt « route gesplittet » ist. Da diese Lib nur im Zwave-Service verwendet wird, dachte ich, dass die Lib nur im Bundle der Seite enthalten ist.
Aber wie die preact-cli-Dokumentation sagt (GitHub - preactjs/preact-cli: 😺 Your next Preact PWA starts in 30 seconds. · GitHub):
Ich denke, dass etwas mit dem Code-Splitting nicht funktioniert, wie wir die Dateien derzeit importieren. Wir müssen ermitteln
Edit: Ich bin auf diesen super Blog-Post gestoßen:
Ich habe eine kleine Analyse der Pakete durchgeführt, die unser Frontend am meisten belasten:
| Library | Size | Action |
|---|---|---|
| vis-network | 509 kb | Entfernen und durch eine einfache Tabelle in der Z-Wave-Integration ersetzen |
| vis-data | 220 kb | Entfernen und durch eine einfache Tabelle in der Z-Wave-Integration ersetzen |
| date-fns | 240kb | Durch dayjs ersetzen (bereits im Frontend verwendet) |
| leaflet | 408 kb | Prüfen, ob wir es dynamisch nur in der Kartenansicht, Anmeldeformular und Home-Einstellungen importieren können |
| cropper | 110kb | Prüfen, ob wir es nur in der Anmeldung und Einstellungen importieren können |
| tagify | 59 kb | Prüfen, ob wir es dynamisch nur in der Szenenansicht importieren können |
| @jaames/iro | 27kb | Prüfen, ob wir es dynamisch importieren können? |
Zu einem anderen Thema gibt es auch die Lib « tabler-ui », die wir für die UI verwenden und die in letzter Zeit wirklich viele neue Funktionen herausgebracht hat. Irgendwann müssen wir uns damit beschäftigen, aber das wird ein großes Projekt!! 
Okay, am Ende ist es mit date-fns nicht so einfach…
Die Lib « react-datepicker » hängt davon ab, um ihre UI auf Französisch zu formatieren. Ich habe nicht den Eindruck, dass sich das ändern lässt.
Ich werde versuchen, nur das Minimum der Lib zu behalten…
Nichts mehr hinzuzufügen
Sobald wir ein bisschen aufgeräumt haben, können wir das hier zum CI hinzufügen:
Ich weiß nicht, ob das zusammenhängt, aber wenn man Gladys zum ersten Mal installiert und ihr über den Chat schreiben möchte, dann antwortet sie nicht. Und wenn ich die Seite neu lade, braucht sie leicht 15 Sekunden zum Laden, und dann habe ich meine Antwort verzögert, also über meiner Frage… Ich reproduziere das immer wieder, aber ich habe vergessen, Screenshots zu machen.
@Jean34 Ich weiß nicht, ob das zusammenhängt, können wir das im Thema „Verschiedene Bugs“ (oder einem anderen neuen Thema, wie du möchtest) besprechen?
Machst du noch ein neues Dev-Release wegen des Bugs, den ich dir gestern für die Wetterbox gesagt habe? Wenn ja, reproduziere ich den Bug in dem anderen Thread, okay 
Ich habe gerade einen Dev-Build gestartet
Ich habe einen PR für eine Sicherheitslücke mit hoher Priorität auf der Server-Seite erstellt: security(server): CVE-2021-23358 by cicoub13 · Pull Request #1195 · GladysAssistant/Gladys · GitHub
Was haltet ihr davon? Ist es besser, die Abhängigkeiten schrittweise zu aktualisieren, wenn man sie sieht? Oder lieber eine „Aktualisierungssitzung“ einmal im Monat durchzuführen?
Ich denke, Cypress wird es ermöglichen, die Abhängigkeiten ruhiger zu aktualisieren, wenn es eine größere Abdeckung der Funktionen hat 
Das hängt von der Schwachstelle und dem Einfluss ab
In Gladys blockiert der Build aktuell bei allen Schwachstellen mit einer Kritikalität >= HIGH für Produktionsabhängigkeiten (nicht für devDependencies) (wir führen bei jedem Push npm audit aus) (siehe Gladys/.github/workflows/docker-pr-build.yml at master · GladysAssistant/Gladys · GitHub), also haben wir bereits einen automatisierten Prozess für Abhängigkeiten, die in die Produktion gehen.
In diesem Fall handelt es sich um eine devDependency, also ist es keine Abhängigkeit, die in die Produktion geht, sondern nur ein lokales Build-Tool, daher hat die Schwachstelle keinen Sicherheitsbezug auf Gladys.
Ja, ab und zu eine kleine Runde für diese Art von devDependencies zu machen, denke ich, ist der richtige Ansatz
Danke für die klare Antwort. Super für den blockierenden Build für echte Abhängigkeiten 
Hallo zusammen!
Ich habe Donnerstag und Freitag damit verbracht, Stabilität zu verbessern, Updates durchzuführen, aufzuräumen und eine große Neuigkeit: Ich habe es geschafft, auf preact-cli 3.xx umzusteigen!!!
Das ist einfach unglaublich, es verändert alles:
- Keine seltsamen Bugs mehr beim Entwickeln (Komponenten, die sich verdoppeln)
- Das JS-Bundle wird für moderne Browser gebaut und lädt Polyfills intelligent. Das macht einen echten Unterschied in der Bundle-Größe. Wir bleiben kompatibel mit > 99% der Browser im Umlauf, keine Panik Meine Zielsetzung für Gladys im Allgemeinen ist es, mit Firefox, Chrome und Safari kompatibel zu sein. Das ist schon mal gut für das Projekt, das wir haben.
- Möglichkeit, Komponenten asynchron zu laden und somit kein riesiges zentrales Bundle zu haben, sondern kleine Bundles. Mal sehen, ob wir das wirklich pro Seite trennen wollen. Ich habe Tests durchgeführt, um zu sehen, wie es wäre, wenn alle Routen separate Bundles hätten, und die Benutzererfahrung ist nicht unbedingt besser: Statt eines etwas langsameren initialen Ladens wirkt die App langsamer, wenn man sie durchstöbert, weil für jede Route eine Anfrage gestellt werden muss, und das ergibt Hunderte von Bundles statt einem. Da die App eine PWA ist, muss sie sich durch Hunderte von sequenziellen Anfragen aktualisieren, was langsamer ist, während es mit einem einzigen Bundle nur eine Anfrage (zwar etwas langsamer, aber nur eine) ist. Ich denke, wir sollten lieber klug vorgehen: das nur tun, wenn es notwendig ist, auf den Routen, die wirklich sehr schwere Komponenten haben (z.B. die Karte mit Leaflet, so etwas)
Ich bin sehr zufrieden mit dem Ergebnis, der PR ist hier für alle, die es interessiert:
https://github.com/GladysAssistant/Gladys/pull/1242
Edit: Ich habe einen Dev-Build erstellt, falls ihr testen wollt.
Die Gladys-Demo-Website ist auch auf diesen neuen Build umgestiegen
Ich verwende diesen Build und habe bisher keine Nebenwirkungen festgestellt 
Gut gemacht!