Umstellung von Keys auf IDs

[yannisgu]

Wir müssen uns entscheiden ob wir in den Config-Files sprechenden Keys oder IDs oder beides verwenden.

Ich sehe folgende Szenarien:

(1) Keys als Referenzen

So wie es aktuell umgesetzt ist. Jede Trainingsart, Trainingswert, etc... hat einen key. Alle Referenzen unter den Config geschehen mit diesem Key. Alle Referenzen in der DB sind mit der ID.

Pro

• Referenzen im Config sind einfacher zu verstehen. Mit

  "activityDetails": [
            {
              "key": "orienteering-discipline"
            },
            {
              "key": "importance"
            }
          ],

  sieht man was gemeint ist. Mit "activityDetails": [12, 34] muss man im activityDetails nachschauen was hinter den IDs 12 oder 34 versteckt ist.

Contra

• Im Code ist das handling mühsamer, da in der DB immer die ID steht.
• Keys müssen noch gestrählt werden, da die Übersetzung nicht wirklich korrekt ist

(2) Keys nur für Dictionary und als erklärung

Referenzen im Config-File sind grundsätzlich mit IDs. Auch sind die Config-Files als hashmap aufgebaut mit der ID als key. Pro

• Dictionary ist verständlicher
• Handling im Code einfacher

Contra

• Immer noch doppelte id/key.
• Keys müssen wohl immer noch gestrählt werden
• Referenzen im Config weniger gut lesbar

(3) Nur IDs und description

Alle Referenzen geschehen via ID - auch im Dictionary. Damit für der Übersetzer weiss, was er übersetzen muss, exportiert das Übersetzungs-Tooling den Deutschen Wert mit. Damit die Config-Files noch verständlich ist, erhält jeder Eintrag (Trainingsart, Einheitswert, etc) ein Feld "description", wo der Deutsche Wert angegeben wird. Dieses Feld wird in der Applikation nicht verwendet.

Pro

• Handling im Code einfacher
• Wir müssen jetzt die Keys nicht definieren

Contra

• Config und Dictionary weniger verständlich

[yannisgu]

@andreasrueedlinger ich habe die Diskussion in ein Issue ausgelagert. Ich persönlich finde Variante 2 suboptimal. Ich habe ein bisschen das Gefühl es kombiniert die Nachteile von Variante 1 und 3.

Ich bevorzuge etwas Variante 1, Variante 3 passt mir aber auch.

[andreasrueedlinger]

@yannisgu du hast jetzt ja erste Erfahrungen gemacht bezüglich dieser Thematik bei der ersten Implementierung activity und config services im client. So wie ich sehe kreierst du mal beide Hashmaps und verwendest immer die ids ausser bei den relations. Was meinst du mittlerweile? Ich tendiere weiterhin auf Variante 3, aber nicht weil es beim Client irgendwelche Vorteile hat, sondern weil ich gerade die keys durchstrählen wollte und gemerkt habe, dass wir ja erst den einen Verband haben. Du hast zwar recht, dass die config files besser verständlich sind und das debuggen ist sicher einfacher. Aber der Vorteil beim Übersetzen fällt weg, da wir ja sowieso deutsch als Vorlage mitgeben müssen (oder englisch oder was auch immer). Und was machen wir nun für die anderen Verbände? Es gibt ja solche die noch aktiv sind und die wir auch "portieren" müssen. Und da habe ich gesehen, dass zum Teil gleiche Sportarten existieren (gleicher Name) mit unterschiedlicher Beschreibung und dann natürlich unterschiedlicher Config. Nun müssen wir da sehr sauber bleiben und die Einträge separat belassen, dass eine id/ein key jeweils auf das richtige zeigt. Und falls ein Verband etwas anpassen will, dass nicht der andere auch betroffen ist. Auch wenn das doppelt übersetzen heisst.

[andreasrueedlinger]

Langer Rede kurzer Sinn: Variante 1 und 3 ziemlich gleichwertig. 3 = weniger Aufwand jetzt, dafür mühsameres debuggen, verstehen von configs. 1 = mehr Aufwand jetzt (alle keys müssen im Vorfeld kreiert werden! Alle Verbände ausser was wirklich nicht mehr benötigt wird), nachher einfacher zum lesen/debuggen von configs. Variante 3 wäre zudem noch sparsamer was Datentransfer betrifft. Schwierige Entscheidung...

[yannisgu]

@andreasrueedlinger: Ich habe mir das eine Weile überlegt und tendiere darauf die Keys wieder fallen zu lassen (Variante 3). Die Argumente hast ja alle nochmals aufgeschrieben. Für mich ausschlaggebend ist, dass nun zur Hälfte Keys und zur hälfte ID's verwendet werden. Das verkompliziert den Code unnötig.

Eventuell würde es dafür Sinn machen comments in den Config's zu erlauben und zum parsen des JSON's die library https://www.npmjs.com/package/comment-json zu verwenden?

[andreasrueedlinger]

Ok, Entscheid: zurück zu IDs! Kommentare oder Descriptions Feld in Json

[andreasrueedlinger]

Umsetzen zusammen mit #15

[andreasrueedlinger]

Done, siehe PR: https://github.com/t-pak/code/pull/44 Habe es jetzt so gelöst, dass überall die Ids drin sind, per default aber auch eine description geschrieben wird, damit fürs Debuggen etwas mehr Übersicht herrscht. Mit flag -p oder --prod werden diese descriptions unterdrückt (für Produktion dann)