Before I get started, I’d like to express how grateful I am for all of the work that the React team has put in over the years. They’ve created an awesome framework that, in many ways, was my introduction to the modern web. They have paved the path for me to believe in the ideas I’m about to present and I would not have arrived at these conclusions without their ingenuity.
Since the introduction of the React Hooks API, I’ve seen a lot of discussion about
useReducer, and when to use one over the other. From these conversations, one would conclude that
useState is best suited for simple state with simple update logic and that
useReducer is best for complex state shapes with complex update logic.
I’m here to convince you that when wrapped in a 4 line custom hook, useState can be just as powerful as, if not more powerful than, useReducer when managing complex state.
I don’t like reducers. I’ve tried using them, but I always end up…
An issue that’s plagued React apps everywhere: after updating a resource on the server, how do I update my UI state to reflect the changes?
Typically there are two solutions:
The first solution is easy but inefficient. It’s simple code, but it’s not particularly performant and it’s hard on the network.
The second solution is efficient but complex. It minimizes network calls, but it…
Form validation can be a tricky thing. There are a surprising number of edge cases as you get into the guts of a form implementation. Thankfully, there are many form validation libraries out there which provide the necessary flags and handlers to implement a robust form, but I challenged myself to build one in under 100 lines of code using the React Hooks API (currently in alpha). As React Hooks are still an experimental proposal, this is a proof of concept for the application of React Hooks to implement form validation.
Also, fair warning, the library I build is 100…
In 2015, Dan Abramov wrote an article, Presentational and Container Components, that some React new-comers misconstrued as commandments. In fact, I myself stumbled upon the article and many others echoing its teachings and I thought, this must be the best way to separate concerns amongst components.
But, Dan Abramov himself later addressed the community for clinging to the design patterns he outlined.
Angular is an MVVM-like framework comprised of several major conceptual components that work together to separate concerns.
Some of these major components include:
Routers: Use pattern matching to map urls to templates/controllers.
Services: Handle application business logic and make calls to web API’s. They’re used to pass data among controllers because only a single instance of each service exists for the lifetime of the application. These are lazily instantiated when you try to first access them.
Controllers: Glue services to html templates. Controllers are mostly used to mould data into a format that the UI can work with. They’re also…