We all know that one of the most challenging task in software development is state management. This is especially true for the JavaScript world. There are thousands of articles on this topic and so I decided to write another one 😁. I wanted to share my current thoughts on the different state types. I found that answering "What lives where?" question is far more important than the actual state management. Which more or less is an implementation detail.

We spent a day with Open Source-“Wunderkind” Max Stoiber in Vienna. Despite his young age of only 23, Max has achieved incredible things: he's created react-boilerplate and styled-components, his start-up, Spectrum, was recently acquired by GitHub and he gives talks all over the world. Learn more about his journey - and how he dropped out of university (twice!) - in this mini-doc.

I just started using TypeScript. I did couple of React projects and noticed a pattern in the setup. I decided to export that to a starter kit 👉 beginning. It is based on Webpack with Babel and TypeScript loader.

Recently I stumbled upon on an interesting bug which reminded me what is actually happening with my components when React is rendering them.

When we start using React we very soon also start asking questions. Where I’m suppose to put my data, how to communicate changes or how to manage state? The answers of this questions are very often matter of context and sometimes just practice and experience with the library. However, there is a pattern which is used widely and helps organizing React based applications - splitting the components into presentational and containers.

The Dependency Inversion Principle relates to the stability and reusability of higher-level components within an application. The principle states:_A. High-level modules should not depend on low-level modules. Both should depend on abstractions.B. Abstractions should not depend upon details. Details should depend upon abstractions._Read more here.