Hallo,
Ich frage mich, warum nicht alle Konstanten von Gladys über die SDK ausgesetzt sind? Das würde in den Integrationen die Notwendigkeit vermeiden, sie zu duplizieren, und Fehler reduzieren. Beispiel einer Konstante:
Danke
Hallo @Sescandell 
Danke für den Vorschlag, der Bedarf ist tatsächlich real! Werte wie category: 'switch' oder die Codes von BUTTON_STATUS manuell abzutippen, mit dem Risiko von Tippfehlern, die die Geräteerkennung zum Scheitern bringen, ist keine gute Entwicklererfahrung.
Allerdings denke ich nicht, dass wir alle internen Konstanten exponieren werden. Die Datei constants.js des Kerns mischt zwei Dinge:
- Die Enums des öffentlichen Vertrags (Kategorien/Typen/Einheiten von Features,
STATE,BUTTON_STATUS, Wetterbedingungen, Verkehrsmittel…) → diese sollten im SDK exponiert werden, mit TypeScript-Typisierungen für Autovervollständigung und Kompilierungsfehler
- Die Implementierungskonstanten (interne Ereignisse, WebSocket-Nachrichtentypen, Timings…) → diese bleiben intern. Sie zu exponieren würde sie in eine öffentliche API verwandeln, und jede interne Umbenennung würde zu einem Breaking Change für alle Integrationen werden. Die Aufgabe des SDK besteht gerade darin, all das zu kapseln.
Also die Idee, die wir behalten: Im SDK den Teil der Konstanten exponieren, die zum öffentlichen Vertrag gehören (die, die die API tatsächlich validiert), mit einer automatischen Überprüfung in der CI, um sicherzustellen, dass sie mit dem Kern synchron bleiben.
Kleine Klarstellung: Die Referenz für die Ausführung bleibt immer die Version von Gladys, die beim Benutzer installiert ist. Wenn in einer zukünftigen Version eine neue Kategorie hinzugefügt wird, wird sie von einer älteren Gladys-Version nicht akzeptiert, selbst mit einem aktualisierten SDK.
Ich füge es zur Roadmap des SDK hinzu!