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.

This weekend I decided to play with the new kid on the block - Facebook's Recoil library for managing state. I did the trivial counter example to see how it works. It's pretty simple idea so I wondered how much it takes to replicate its features. I found the exact answer - 70 lines of code. Obviously, my implementation didn't cover everything but it was fun so I decided to share my findings.

(A side note: I did not look at the code of Recoil. I didn't want to be bias on how to write my version.)

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.

I had an interesting bug in my React application. It happened that the problem was in the fact that I was using forEach instead of for.

The bug that I was encounter was

Years ago when Facebook announced their JSX syntax we had a wave of comments how this was against some of the well established good practices. The main point of most people was that it violates the separation of concerns. They said that React and its JSX are mixing HTML, CSS and JavaScript which were suppose to be separated.

In this article we will see how React and its ecosystem has quite good separation of concerns. We will prove that markup, styles and logic may live in the same JavaScript land and still be separated.

If you are writing React applications you probably know about higher order components or render props (which by the way I think is kind of a form of higher order component pattern). In both cases we have a component that encapsulates logic and passes props down to children. Recently at work we came to the idea that we may push this further and represent some functionalities which are out of React in the same fashion - with a single tag in our components tree.

There are lots of things which I like in React. Mostly the fact that it teaches interesting patterns. One of my favorites ones is higher-order component. In this article we’ll do a couple of experiments and will see how powerful this approach could be.

(This article is part of React in patterns series.)

React is highly composable. And the API that enables that is props.children. It gives us the power to create a placeholder that is later filled with content from the outside.

React is probably one of the best choices for building UI. Good design, support and community. However, there are cases where we want to use an external service or we want to integrate something completely different. We all know that React works heavily with the actual DOM and basically controls what’s rendered on the screen. That’s why integrating of third-party components could be tricky. In this article we will see how to mix React and jQuery’s UI plugin and do it safely.

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.

Long time I was searching for a good front-end framework. Framework that will help me write scalable and easy to maintain UI. Even though React is just a library for rendering it comes with so many benefits that I can easily say “I found it”. And like every thing that I use a lot I started seeing some patterns. Techniques that are applied over and over again and I see in the code of other developers. It’s time that I start documenting, discussing and sharing these patterns.

While I was open sourcing react-place I noticed that there is some complexity around preparing the component for releasing. I decided to document the process here so I have a solid resource next time. You may be surprised but writing the working jsx file doesn’t mean that the component is ready for publishing and is usable for other developers.

You've probably heard about ToDoMVC project. It's same ToDo application made with different frameworks. It's interesting how the same problem is solved by different programmers following different concepts. This article is about making the ToDoMVC application with AbsurdJS.

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.