Frontend: Verschiedene Verbesserungen / Entwicklererfahrung

Entwicklung
1

Hallo Entwickler von Gladys :slight_smile:

Das « frontend »-Projekt von Gladys 4 wurde 2018/2019 erstellt, und bestimmte Konfigurationspunkte werden mit der Zeit veraltet/ungünstiger.

Ich würde gerne mit euch über die verschiedenen Dinge sprechen, die aktualisiert werden können, damit der Code moderner wird, und um zu iterieren, was im Frontend gut/laut schiefgegangen ist.

ESLint aktualisieren

Die ESLint-Konfiguration aktualisieren, um die neuesten JS-ES2023-Verbesserungen zu ermöglichen (z. B. den Operator ?., darüber haben wir mit @bertrandda in seinem letzten PR gesprochen)

Das erinnert mich daran, dass wir das auch im Backend tun sollten, weil bestimmte JSDoc-Fehler unmöglich zu verstehen sind, und in einer neueren Version viel verständlicher sind!

Verwendung der @connect-Dekoratoren von unistore beenden

Das war damals in Mode, und am Ende empfiehlt unistore es nicht mehr, es war ein « Hack », der vom Transpiler erlaubt wurde, ich glaube nicht einmal, dass es 2023 in der JS-Spezifikation ist.

Früher:

Screenshot 2023-04-28 at 11.59.24
Screenshot 2023-04-28 at 11.59.24590×234 18.8 KB

Jetzt:

Screenshot 2023-04-28 at 12.00.17
Screenshot 2023-04-28 at 12.00.17870×176 10.3 KB

Ich muss eine ESLint-Regel hinzufügen, um dieses Verhalten zu verbieten.

Verwendung des globalen unistore-Speichers stark einschränken

Ich gebe es zu, es ist meine Schuld, zu Beginn der v4 dachte ich, ein globaler Speicher wäre eine gute Idee, wahrscheinlich aufgrund von mangelnder Erfahrung in der React-Entwicklung. Das Ergebnis: Wir hatten viele Bugs, die mit dem globalen Speicher zusammenhängen, weil sich natürlich Variablen zwischen den Komponenten gegenseitig verschmutzen.

Mein Vorschlag: Die Verwendung des Speichers auf die « globalen » Variablen beschränken: user, session, httpClient, und das war’s.

Der Rest sollte Klassenstates sein, lokal zur Klasse. Das verhindert die Verschmutzung zwischen Komponenten.

Ebenso sollten wir prüfen, ob ESLint uns helfen kann, den Entwickler zu warnen.

Vereinheitlichung des Styling-Verhaltens

Das Styling im Frontend wurde nicht unbedingt auf ESLint-Ebene durchgesetzt, und das halte ich für einen Fehler.

Bestimmte Komponenten verwenden inline-Styles (style={{}}), was eine schlechte Praxis in Bezug auf die Performance ist, weil bei jedem Render ein Objekt neu erstellt wird.

Außerdem sind diese Styles schwer zu modifizieren, um das responsive Design zu verwalten.

Mein Vorschlag: Style-Dateien in .css (eine für jedes Feature, grob gesagt), die in die Komponente importiert werden.

Media Queries werden möglich und ermöglichen die Verwaltung kleiner/großer Geräte:

Screenshot 2023-04-28 at 12.08.20
Screenshot 2023-04-28 at 12.08.20546×374 22.3 KB

Mehr ESLint-Regeln, um PR-Reviews zu beschleunigen

Ich habe festgestellt, dass ich bei der Überprüfung des letzten PR von @bertrandda oft die gleichen Anmerkungen zum Frontend-Code in den PRs mache (Achtung vor inline-Funktionen, inline-Styles usw.), und dass dieses Feedback in ESLint sein könnte, damit die Reviews schneller gehen :slight_smile:

@contributors: Was denkt ihr? Andere Rückmeldungen zum Frontend? :slight_smile:

2

Also, ich habe mich heute warmgelaufen, ich habe ESLint serverseitig aktualisiert, insbesondere auf der JSDoc-Seite

Das sind viele Änderungen, aber die Fehler sind jetzt viel klarer

3

Ich habe einen PR gestartet, um eine Warnung zur Verwendung des Decorators @connect hinzuzufügen (und durch einen Funktionsaufruf zu ersetzen)

Bisher 113 Warnungen:

Screenshot 2023-05-01 at 13.36.17
Screenshot 2023-05-01 at 13.36.171912×260 29.9 KB

Ameisenarbeit, aber ich komme schnell voran :stuck_out_tongue:

4

Also habe ich vorerst 2 Regeln hinzugefügt:

Screenshot 2023-05-01 at 15.19.46
Screenshot 2023-05-01 at 15.19.462180×622 67.4 KB

  1. Eine Warnung für Inline-Styles
  2. Ein Fehler für die Dekoratoren @connect
  3. Für später: Eine große Warnung bei der Verwendung von store.setState, um die Nutzung lokaler setState für Komponenten zu fördern

Alles ist in diesem PR festgelegt: Upgrade front Eslint, remove all @connect decorator by Pierre-Gilles · Pull Request #1766 · GladysAssistant/Gladys · GitHub

5

Ich habe diese 2 PRs zusammengeführt!

Wer gerade an PRs für Gladys arbeitet (@AlexTrovato, @bertrandda, @Pti_Nico, @euguuu, @Romuald_Pochet), ich empfehle euch, eure Branches zu rebase, ein npm install (server/front) durchzuführen und einen Eslint zu machen, um sicherzustellen, dass euer Code aktuell ist :slight_smile:

Falls ihr Probleme habt, die Änderungen vorzunehmen, zögert nicht!

6

Super, ich unterstütze deine Aktion.
Jetzt liegt es an uns, die Warnungen Integration für Integration zu beheben, oder bist du heiß und übernimmst du das @pierre-gilles?

7

Guten Abend,

Ich habe begonnen, die Änderungen in die zwave-js-ui-Integration einzubeziehen, und habe ein Problem mit der folgenden Methode:

/**
* @description Gibt ein Array von Knoten zurück.
* @param {string} orderDir - Sortierung.
* @param {string} search - Schlüsselwort zum Abgleichen.
* @returns {Array} Gibt eine Liste von Knoten zurück.
* @example
* const nodes = zwaveManager.getNodes();
function getNodes({ orderDir = undefined, search = undefined } = {}) {

Nach dem Update von SE Lint erhalte ich den folgenden Fehler:

  30:1  error  @param "search" does not match an existing function parameter  jsdoc/check-param-names

Ideen?

8

@Romuald_Pochet Ja, das sind keine Funktionsparameter, die du beschreibst, sondern ein Objekt!

Du musst es also so machen:

Screenshot 2023-05-02 at 09.41.30
Screenshot 2023-05-02 at 09.41.301168×502 64 KB

Übrigens, ein kleiner Feedback: Das = undefined ist nicht nötig, denn wenn du keine orderDir angibst, ist es ohnehin undefined :slight_smile:

9

Ich habe alles in den 2 PRs gestern korrigiert :slight_smile:

Das Einzige, was ich nicht gemacht habe, war die ESLint-Regel zu aktivieren, um eine Warnung bei der Verwendung von unistore (Datei actions.js) zu setzen, da das 600 Warnungen erzeugt hat

In Zukunft versucht bitte, diese Dateien actions.js nicht mehr zu verwenden und stattdessen lokale States zu nutzen, und wenn ihr etwas Zeit habt, migriert schrittweise die bestehenden Komponenten :slight_smile: Danach ist es aber auch nicht die Priorität, es ist eher eine Richtlinie für die Zukunft

10

Ich sprach davon, die 146 Warnings auf der Frontend-Seite zu beheben, hauptsächlich bei der Verwendung des Attributs « style »: « Inline-Stile werden nicht empfohlen. Bitte verwenden Sie eine .css-Datei »
Es gibt auch Warnings zu Promises für « Bevorzuge await anstelle von then()/catch()/finally() »

11

Ah tatsächlich! Ja, bei denen könnte ich Hilfe gebrauchen. Für mich ist es aber keine Priorität, alles auf einmal zu erledigen, wir können das schrittweise angehen. :blush:

Für mich gibt es im Moment andere Entwicklungs-Prioritäten, typischerweise das Zigbee-Projekt, das du gestartet hast, um die Marke des USB-Sticks auszuwählen. Das ist etwas, das für den Nutzer mehr Mehrwert bietet, weil es alle blockiert, die mit Gladys anfangen (da Domadoo nur noch den Sonoff-E-Dongle verkauft). :winking_face_with_tongue: