#19-Konfiguration-anzeigen #55
No reviewers
Labels
No Label
0 - 2 Std
1 - 2 Tag
2 - 5 Std
5 - 8 Std
Bug
Doing
Done
In Review
Kennzahlen Extraktion
Kennzahlen Konfigurieren
Kennzahlen überprüfen
Kennzahlen validieren
Kennzahlenwerte exportieren
Kunden Feedback
Nice to have
Pitchbook hochladen
To Do
Wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PSE2_FF/pse2_ff#55
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "#19-Konfiguration-anzeigen"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
NOTE: Ticket noch nicht komplett fertig, aber für weiter bearbeitung von andern Tickets kann der teil in main gemergt werden :)
Jetzt habe ich doch fertig gemacht.
@ -0,0 +14,4 @@useEffect(() => {const fetchKennzahlen = async () => {while (true) {Warum ist hier das while(true){}?
Das while (true) ist für eine "einfache" Retry-Logik:
Falls der API-Call beim ersten Mal fehlschlägt (z. B. weil der Backend-Service oder die Datenbank gerade erst gestartet wird oder temporär nicht verfügbar ist), wird der Fetch alle 2 Sekunden wiederholt, bis es erfolgreich ist. Dadurch muss der User die Seite nicht manuell neu laden, und es entstehen keine Fehler im Frontend, wenn z. B. der Coordinator oder die Datenbank neu startet oder gerade noch nicht bereit ist.
@ -0,0 +57,4 @@throw new Error(`HTTP error! status: ${response.status}`);}const updatedKennzahl = await response.json();Du updatest hier den state von der "active - checkbox" im frontend erst, wenn du das response vom Server bekommst. Wenn alles auf deinem Rechner läuft funktioniert das noch gut, aber sobald frontend und backend nicht so schnell kommunizieren fühlt sich das sehr schnell laggy an (kannst du mit simuliertem langsamen Internet testen. Das fällt schon bei 4G auf).
Was man hier macht heißt "optimistic update", vereinfacht zusammengefasst: man updated die ui im frontend direkt und nur wenn der request failed rollt man das update zurück.
Wenn dich das interessiert, zu der Umsetzung steht mehr in dem pdf. Dazu ein bisschen Hintergrund: Da geht es um die Bibliothek "Tanstack Query" (die kann nicht nur react), die kümmert sich mittels caching darum, einen asyncronen state zu verwalten (also den Server-State im Frontend). Hier eine kurze erklärung zu react-query: https://ui.dev/c/query/why-react-query (wenn dich das weiter interessiert). Für die Begriffserklärung in dem PDF: Die Bibliothek unterstützt mehrere Funktionen:
Diese Liste, die häufiger in den Code-Beispielen vorkommt:
['todos', 'list', { sort }], steht immer für den key, unter dem das Element im cache abgelegt ist.@ -0,0 +26,4 @@const [formData, setFormData] = useState<Partial<Kennzahl>>(emptyKPI);const [isSaving, setIsSaving] = useState(false);useEffect(() => {Du kannst dieses/n (keine ahnung ob das "der", "die" oder "das" hook ist) hook sparen, wenn du die initalData mit den Standard-Daten von emptyKPI vorbelegst:
Ich kenne es so, dass man für die Wiederverwendbarkeit der Komponente den useEffect benötigt. Wenn man zwischen den unterschiedlichen Modi (add/edit) wechselt oder im Edit-Modus zwischen verschiedenen KPIs zum Bearbeiten wechselt, verhindert der useEffect Fehler bei der initialen Datensetzung. Ohne den useEffect könnten z.B. alte Daten von einer KPI noch sichtbar bleiben, weil die neuen Daten nicht richtig "überschrieben" werden.
Wahrscheinlich ist es für unser Projekt eh nicht so wichtig. Oder ist es bei React ein bad practice/Soll ich es trotzdem ändern?
@ -0,0 +50,4 @@}};const handleCancel = () => {ich glaube, die funktion brauchst du gar nicht, da der state eh verloren geht durch das onCancel()