Wann Redux sinnvoll ist – und wann nicht // deutsch

Redux ist eine Bibliothek zum Verwalten des States. Trotzdem ist der Einsatz von Redux nicht in jeder Anwendung sinnvoll. Stattdessen sollte die Entscheidung für oder gegen Redux nur nach sorgfältiger Abwägung und Evaluierung getroffen werden. Welche Argumente sprechen für, und welche gegen den Einsatz von Redux?

00:00 – Einleitung
01:20 – Was ist Redux?
02:53 – Redux + X
03:59 – Welche Probleme löst Redux?
04:58 – Code auf Lesbarkeit optimieren
06:06 – Komposition statt Vererbung
07:10 – Explizite Schnittstellen
08:24 – Die Fachlichkeit zentralisieren
09:12 – "You might not need Redux"
10:13 – Webseiten und -anwendungen
11:04 – Ausblick

────────────────────

Über the native web 🦄

Wir sind ein Beratungs-, Schulungs- und Entwicklungsunternehmen, das sich auf Web- und Cloud-Technologien spezialisiert hat. Wir streben nach intelligenten und eleganten Lösungen für komplexe Probleme, und wir glauben, dass Softwareentwicklung kein Selbstzweck ist. Stattdessen sollte Software tatsächliche Probleme der realen Welt lösen.

Wir glauben, dass native Web- und Cloud-Technologien das Fundament sind, auf dem die Zukunft aufbaut. Unsere Kernkompetenz ist der Entwurf und die Entwicklung verteilter Web- und Cloud-Anwendungen unter Verwendung dieser Technologien in interdisziplinären Teams. Wir entwickeln auch unser eigenes Open-Source-Framework namens wolkenkit. Und wir lieben es, unser Wissen in Schulungen und Workshops, auf Konferenzen und bei Usergroups zu teilen.

────────────────────

Weiterführende Links 🌍

[timopeter]

Dein Video bestätigt dass ich seit Jahren einen Bogen um den Einsatz von Redux mache.

Indirekte Abhängigkeiten und gesteigerte Code-Komplexität hielten mich bisher davon ab den Einsatz in unseren Projekten zu befürworten.

In Angular (und sicher auch in den anderen Bibliotheken und Frameworks) gibt es häufig andere Methoden mit "Bordmitteln" um Probleme zu lösen, für die so mancher Redux einführen möchte.
State-Changes z.B. in Angular einfach mit Singleton Services bekannt machen.
Singleton Services und rxjs Observables kennt man als Angular Dev sowieso bereits.

[gambo]

Vielen dank für diesen wertvollen Content ❤️🙏

[kyrospace]

Jetzt müssen wir mal klären wo der Unterschied zwischen einer Webseite und Webanwendung ist. Super Video.

[christianhorauf]

Hallo Golon, ich bin da irgendwie sehr Hin- und Hergerissen. Ich bin vor allem erst mal ein großer Fan von Funktionaler Programmierung. Und Redux wurde, soweit ich weiß von Elm abgekupfert, wo der Ansatz zum ersten mal Anwendung fand und wo es gar nicht anders geht, als dass man über ein zentrales Model die Ausgestaltung von Views implementiert. Das Trennen von fachlicher Logik und UI-Logik hattest Du ja in Deinem Video propagiert und würde eben diesem reinen Elm-Ansatz widersprechen. In Elm fühlt sich das ganze natürlich an und wenn man sich ein bisschen daran gewöhnt hat, dann kommt man auch ganz gut damit klar.
Nun hab ich aber bis vor kurzem auch an einem Angular-Projekt mit ngrx gearbeitet, also der Angular-Ausprägung von redux. Und das fand ich echt zäh und schwierig nach zu vollziehen. Denn diese Aufteilung in Actions und Reducers usw. wirkt doch ziemlich umständlich. Ich bin trotzdem dafür das zu verwenden, weil es zumindest theoretisch eine reine funktionale Entwicklung möglich macht, wie sich aber in meinem Team gezeigt hat, setzen das die wenigsten in der Angular/React-Welt so um. Und da frag ich mich dann schon wofür man Redux eigentlich nutzt. Vor allem (und das hast du glaub ich gar nicht erwähnt) weil Redux es einem ja auch erlaubt das sog. TimeTravel-Debugging einzusetzen. Das haben wir in unserem Team leider auch nicht gemacht obwohl das meines Erachtens eines der wichtigsten Features von Redux wäre. Aber das wird natürlich auch nur bedingt funktionieren, wenn man zwischen Fach-State und UI-State unterscheidet und trennt.
Vielleicht hab ich da auch den Zusammenhang zwischen Elm und Redux falsch verstanden. Aber ich fänd es super, wenn Du diese Hintergründe mal aufklären könntest und vielleicht auch Deine Meinung zu der Entwicklungsweise in Elm darstellst. Bzw. gibt es eine besserer Methode UIs mit Functional Programming zu implementieren, ohne die Komplexität von IO-Monaden mit sich zu bringen wie beispielsweise Haskell es täte? Und gleichzeitig will man aber auch nicht wieder in das letztendlich doch wieder "dreckige" State-Management abrutschen, das man in OOP zwangläufig hat. Danke für Dein Feedback.

[christians]

... Wird gemacht, damit man Redux macht. Leider trifft sowas viel zu häufig zu. Besser noch: Wir bauen jetzt Microservices - dann wird alles! einfacher 😉