The issues: CORS errors while fetching files from Firebase storage bucket, leaking RTL styling in styled-components 5, missing trace in console log wrapper, and header not found in Axios response interceptor.

The issues: Firestore index disappearing after deploy, Firestore deploy failing because "index already exists", deployment failing on installing Firebase CLI, MUI X Date Picker stopped informing about invalid date, warning about unnecessary React useEffect dependency on ref, and toast message unusable for copying.

The issues: Firebase app GitHub Actions deploy failing (IAM_PERMISSION_DENIED), SignatureDoesNotMatch error while fetching file from a bucket, no level config per handler in @datadog/browser-logs, and grep skipping hidden files (fzf-lua+ripgrep in Neovim).

The issues: logout not working in React + Capacitor app (Auth Connect), login action stuck in React + Capacitor app (Auth Connect), no details in Capacitor/Console logs, unable to start application on Android Virtual Device (activity class does not exist), and problems with accessing internal NPM dependency.

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.

The Redux Thunks offer a good way of separating logic from UI components. Within a thunk, you can: access the entire state, dispatch actions and thunks, generate side effects (contrary to reducers)… Redux Toolkit contains the redux-thunk middleware and adds it during standard store configuration, nice.

A couple of months ago, I’ve migrated my vim.morzel.net hobby project from Create React App to Vite and noted down a few things that required attention. Recently, while adding dark mode to the same project, I’ve spotted another difference between CRA and Vite: class names for CSS modules were build differently.

I’ve recently made the decision to migrate my vim.morzel.net pet-project from Create React App to Vite. To be honest, I was quite content with how CRA (with a bit of React App Rewired) functioned, and updating might not have been necessary. However, I wanted to use this migration as practice before possibly employing Vite on something more serious (where the speed and active development of Vite might prove a blessing).