While working with large React applications, having a solid Redux architecture can keep data flow clean and easy to debug. A common point of confusion in Redux is the middleware pattern. We'll discuss why Redux middleware is beneficial, where it fits in, and step through an implementation of it.
As an AWS Advanced Consulting Partner, Metal Toad helps our clients identify their cloud solutions. However, one question I frequently hear is, “If we are building cloud solutions, then why is there a need for engineers in Android, iOS, and React specialties?”.
In Part 2 (http://www.metaltoad.com/blog/yagni-react-architecture-part-2), we discussed configuring Director to listen for route changes and run a route handler (conveniently all Director does (and why I love Director)). In this post, we will finally do some React writing. Not a lot. But some. This series is intended to be about React architecture, not necessarily React code creation (which maybe maybe we’ll do later).
In React Architecture: Part 1 we discussed a desire to configure a working React website with as few addons as possible. The post ended with the creation of a basic Webpack config, which left us with a project structure like...
React is awesome. 11/10. In my opinion, the best UI library currently in the ecosystem. It streamlines UI componentization, reusability, UI state, and a ton of other client side headaches devs have been mitigating for years. React's greatest flaw, in my opinion, isn't even really a React flaw as much as a "new stuff hype" flaw, where the infrastructure surrounding React changes almost hourly and can be extremely difficult to keep up with. What libraries are required, which ones will make devs' lives easier, which will bring performance gains?