I love Redux. It’s such an elegant and simple concept that solves so many problems. But like every other solution, adding new concepts to your code base can also introduce the occasional headache.
One of these headaches is that Redux does not enforce a lot of it’s conventions, but when you don’t adhere to them, things start breaking further down the road in strange ways.
Today, I’m going refer to one of Redux‘ three principles: State is read-only
Weiterlesen
Disclaimer: this article targets developers that are using Redux with React. If you are using Redux with another Framework, this article might not be important for you.
Last thursday, Dan Abramov gave a talk on JSConf Iceland called „Beyond React 16“. A few hours later, react-etc.net featured an article titled RIP Redux: Dan Abramov announces future fetcher API. While I agree with almost nothing that article has to say about Redux, the article got one thing right: Somewhere between 6 or 12 months from now, the way we are using Redux (at least when starting a new project) will be drastically different from the way we are using it today.
But before we take a gaze into the crystal ball, let’s take a step back and see what happened.
In diesem Workshop gebe ich eine schnelle und praktische Einführung in das State-Handling-System Redux. Hierfür wollen wir unser bestehendes React-Projekt aus dem React-Workshop für Einsteiger so umschreiben und erweitern, dass das State-Handling unserer Task-Listen-Applikation komplett vom Redux-System übernommen wird und dessen Vorteile in der Praxis sichtbar werden.