Hans und Peter diskutieren über Patterns in React!
Schaunotizen
- [00:01:25] React, Redux, Hooks und HOCs
- Redux-Hooks werden ein offizielles Feature, was Hans und Peter zu einer Grundsatzdiskussion über Patterns in React verleitet. Hooks (siehe Revision 385) wurden vor nicht allzulanger Zeit in React eingeführt und haben sich seither in diversen Code Bases breit gemacht – nach einhelliger Meinung (zumindest im Podcast-Studio) mit nicht nur positiven Auswirkungen. Wir diskutieren über verschiedene Patterns rund um State Management in React, Higher-Order Components und Mittel und Wege, Hook-Benutzung von den Nachteilen zu befreien. Hans schlägt hierfür ein Architekturpattern im Stile von Flux vor.
Kommentare
Andreas Sander (@andi1984) #
Geschrieben am 7.11.2019 um 21:39
Danke für das interessante Thema und diese Folge. Mich hat das Thema React vor grob zwei Jahren erstmalig erreicht. Zwei Jahre und einige hunderte React Komponenten später kann ich vieles was Hans und Peter sagen so bejahen.
– Redux: Die gute Testbarkeit der Redux Reducer war sehr hilfreich, da darin sehr viel Business-Logik abgehandelt und dadurch auch gut getestet werden konnte. Dies war dann natürlich auch hilfreich bei folgenden Refactorings.
– Hooks, functional components, useEffect etc.: Ich mache gerade die gleichen Erfahrungen wie Hans, dass einige unserer funktionalen Komponenten relativ groß werden, mit verschiedensten useEffects. Ich finde es mittels hooks und useEffect sehr viel einfacher Rerenderings zu provozieren (z.B. wenn Objektinhalte komplett identisch, aber neu referenziert werden). React Profiler fand ich in dem Zusammenhang relativ hilfreich, da dieser auch den Grund für Rerenderings anzeigen kann, womit das Debuggen etwas vereinfacht wird (https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html).
Nach aktuellem Stand sind folgende Punkte beim Maintainen einer größeren React-Codebase am Wichtigsten:
– Linting-Rules festzurren um einheitliche und besser lesbare Komponenten zu erzeugen
– Naming conventions für wiederkehrende Properties definieren um Verständlichkeit über die Codebase hinweg zu verbessern
– Regelmäßiges Überprüfen der Komponenten auf evtl. nicht mehr benötigte Props und vermeiden Props über eine gewisse Anzahl an Layern weiterzuleiten
– Codebase-Struktur: Wir folgen hier dem Atomic Design Prinzip und haben entsprechende Ordnerstrukturen (http://atomicdesign.bradfrost.com/chapter-2/). Allerdings selbst da stößt man irgendwann an die Grenzen der Übersichtlichkeit. :)
LG Andi
Hans #
Geschrieben am 8.11.2019 um 07:53
Hi Andi,
danke für deine Anmerkungen zur Episode. Gut zu wissen, dass nicht nur wir diese Probleme haben.
Ich habe mal Peters und meine Ideen in einem Artikel zusammen gefasst: https://drublic.de/blog/conceptual-components/
Viele Grüße
Hans
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.