Image for post
Image for post
Photo by Jan Huber on Unsplash

Throughout the history of React there have been many ways to describe what it does that makes its programming model successful and for sure there are multiple aspects to it, but let's have a look into its foundation — components.

One of the most important characteristics for building large software is its maintainability and the most scalable mental framework for maintainability is the ability to delete and replace pieces of the system. So what makes React so special about code removal?

Props

Props are the main way for a React component to receive information. It is its standard input interface. Props are pretty much the same to a React component as arguments are to a function, but with a small but important difference — components are automatically “subscribed” to the latest version of props and are getting executed automatically by React. …


Image for post
Image for post
Photo by Marcus Löfvenberg on Unsplash

I woke up today with a bunch of ideas about how a particular problem could be solved or at least what could be a better attempt than what I had so far because the problem is non-trivial and there is no standard well-known way to do it.

At the same time, I realized why it took me so long.

I was blocked for over a year

The problem I was thinking about was something I started to work on over a year ago. I did a prototype, settled on one particular implementation and then realized the problem is hard and doing it that way will result in too many problems later. This realization made me feel frustrated. …


Image for post
Image for post

Ok, I have spent some time by now with a Wear OS watch to get frustrated enough and make myself write a blog post which I really don’t like to do, but the status quo is so disappointing that I can’t keep it for myself.

My experience so far

I have a long history of using fitness trackers, starting with the very first jawbone up in 2012, then going over to Fitbit and finally Mi Band in recent years. …


Twitter is a platform where people tend to misunderstand intentions and nuances of a tweet, jump to a conclusion and escalate a debate in the wrong direction.
To avoid this, I wrote a set of hints which will hopefully help you understand me correctly and react in a better way.

  1. If you get hurt or see me misbehave badly, contact me in DM and I will see reason and remove or clarify my tweet.
  2. If I sound negative or harmful to you, please always assume a good intent first.
  3. Before you make up your mind about something and decide to escalate the thread, please ask me first if I meant what you think I said. …


Image for post
Image for post

A long-awaited stable version of JSS v10 is out and here is a summary of what happened. This is a higher-level summary, a full changelog is here and a migration guide here.

It took us almost a year to release this version with much fewer features and improvements than originally planned, because most of the work happens in our spare time and current Open Collective status isn’t usable to pay contributors, not to mention myself.

New hooks-based API for React-JSS

The problem with HOCs besides of some level of indirection is also performance cost. In the end, a HOC needs to generate an additional component, which still needs to add up to React’s reconciliation work. Also, HOCs are not nice to look at in dev tools. …


Image for post
Image for post
Photo by Benoit Gauzere on Unsplash

Many people in both engineering and managing positions see pair programming as basically, two engineers working on one problem and spending twice as much time to solve it, even though one could do it alone. I thought the same myself until some time ago.

While in some cases this assumption might be true, in other cases pair programming will actually save you tons of money.

Maintaining a complex codebase

When a codebase is very complex, often the problem is not to actually fix a bug, but to do it in the right way, according to the current architecture and while taking legacy decisions into account. …


Image for post
Image for post
Photo by Artem Bali

Recently I wrote a higher level overview of CSS-in-JS, mostly talking about the problems this approach is trying to solve. Library authors rarely invest time into describing the tradeoffs of their solution. Sometimes it’s because they are too biased, and sometimes they just don’t know how the users apply the tool. So this is an attempt to describe the tradeoffs I have seen so far. I think it is important to mention that I am the author of JSS, so I should be considered biased.

Social impact

There is a layer of people who work on the web platform and don’t know any JavaScript. Those people are getting paid to write HTML and CSS. CSS-in-JS has made a huge impact on the developers' workflow. A truly transformative change can never be done without some people being left behind. I don’t know if CSS-in-JS has to be the only way, but the mass adoption is a clear sign of problems with using CSS in modern applications. …


Image for post
Image for post
Photo by Bruno van der Kraan
Image for post
Image for post

CSS-in-JS refers to a collection of ideas to solve complex problems with CSS. Since it is NOT a particular library, different libs might solve a different subset of problems and use different approaches, depending on their implementation details.

However, all implementations have in common that they tackle the problems using APIs instead of convention and they leverage JavaScript as a language for styles authoring.

If you are interested in learning the tradeoffs of CSS-in-JS approach, I wrote a separate article for that.

Lack of modules

CSS historically never had actual modules, neither did JavaScript. Requirements for web applications evolved and JavaScript has added a module system. First in the form of a bolt-on solution (CommonJS), later as a standard, statically analyzable module system known as ECMAScript Modules (ESM). …


Image for post
Image for post
Photo by Valentin Lacoste on Unsplash

Currently, DOM and Browser APIs seem to be using null in some cases and undefined in some others. While they had their historical reasons, the result of this inconsistency is that we have to rely on type coercion more often than we should be, which brings an entire set of problems.

What I would like to discuss though is what we would gain if we stop using null and stick with undefined in user code.

1. Semantics — fewer things to think about

Is there really such a big difference in semantics? To me, both null and undefined mean pretty much the same — an absence of a value. …


Image for post
Image for post
https://unsplash.com/photos/pKeF6Tt3c08

This topic is already well discussed and the intent of this article is to share how I prefer to use arrow functions in React and my view on PureComponent optimizations.

Function Components

In function components, we have currently no other choice but to either pass the callback directly from the props to the child component or to create an inline arrow function. You may want the latter if you need to control the arguments passed to the original callback.

Image for post
Image for post

You need to be aware of 2 things in this example:

  1. You generate a function on every render, which will obviously have a new reference. …

About

Oleg Isonen

Eng. @webflow, React, CSSinJS and co. Creator of http://cssinjs.org. Stealing ideas is great. Semantics is just meaning. Twitter: https://twitter.com/oleg008

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store