Links Technical

The Lean Web

Chris Ferdinandi has thrown in some absolute gems in this talk he put together for – The Lean Web, well worth 48 minutes (or less at > 1x) of your time.

Link – The Lean Web

Links Social Stream

I love how this post/tutorial is put together. A thorough illustration of the mindset shift thinking in hooks allows you to take.


Couple of thoughts on React

Pretty sure it’s nothing nobody has noticed already, but I farted out some thoughts about React a while back. I figured I should publish more of this type of rubbish:

I have been watching Kent C. Dodds’ fantastic Advanced React Patterns course on Front End Masters. It occurs to me that a lot of the React patterns and principles which are being uncovered and taught to us all by the likes of Kent relate quite directly to more traditional patterns & principles – in the Gang of Four sense, regarding SOLID and further.

Some examples off the top of my head:

  • Render props feel like a sensible way of implementing dependency injection.
  • Pretty much every major React pattern is a different take on Inversion of Control.
  • Compose-all-the-things is generally a decent approach, good React seems to encourage this.
  • Redux implements Event Sourcing and the concepts of CQRS in an extremely elegant manner.
  • The Single Responsibility Principle underlies the entire concept of web components and React itself.

At first, I was quite snobby about it all: “They’re just coming up with new names for old things”, “all of this has happened before and will happen again”. But when you think about it, this is such a visual way to implement and explain these patterns.

It’s a lot easier to explain event sourcing with “it’s like a distributed redux”. The metaphors feel simpler to solidify when a method hidden in a class called `component.setDependency()` or a hugely overloaded constructor (`new Component(dependency1, dependency2, dependency3);`) becomes ``. I find that coupling, and its costs are so much easier to visualise when you can see the logic spelled out in this way.

I think this has a lot to do with React making interfaces so explicit. If you’re writing sensible components, it is trivial to convert from React’s XML to the correlating UML in your head. (If that doesn’t exist as software yet, I expect it will eventually.)