Posts

Here’s a 4th round of random problems and quick tips for working around them (previous: 3, 2, 1).

Here’s a third round of random issues and quick tips for working around them. Part one is here, part two is here.

Here’s a second round of random issues and quick tips for working around them. Part one is here.

This post will be different from other texts I’ve put on this blog so far. Instead of digging deep into a singe topic, I’ll mention some issues that stumped me recently and suggest solutions. These issues might be quite niche, but I hope it will help at least one person get unstuck. Well, it might be me in the future. I’m 40 now - it’s about time I started writing things down ;)

Previous two posts (1, 2) were about rendering performance, now it’s time for something from the back-of-the-fronted: state management. More specifically: checking the speed at which Redux Toolkit can create slices/reducers and handle dispatched actions. The RTK addressed Redux’s primary criticism: amount of boilerplate. Now (read: for many years) a couple of lines of code is enough to get fully functioning store setup with dev tools enabled, reducers with Immer, actions (creators), thunks etc. All with great TypeScript support… Plenty of nice features, but how about the speed?

I’ve recently checked whether using a Box in Material UI 5, instead of plain div, has significant performance impact. I don’t think it would matter much in practice, but read the post if you are interested in details… Doing this check got me thinking: how much faster making the little square divs would be if we were to drop React and do the DOM manipulation with plain JS? Let’s find out!

I’ve been relying on Material UI Box components quite a lot, because doing so allows use of theme-aware sx property and common attributes such as display or gap. It makes code more consistent with other uses of MUI components.