Hm this is just a "this is how you use react-virtualized" tut, it's actually pretty easy to roll your own virtualization but the crux of the matter is that the native scrollbar on touch devices with acceleration like a touchpad is simply too fast for HTML rendering to keep up. I tried even with one of the fastest rendering frameworks in the world and vanilla. Ultimately for things like grids you need to use canvas with simulated scroll and always draw the cell lines, this way even if the content appear a moment later from some slow framework like React or Angular, it doesn't have jarring flashes of blankness. For a log I guess it doesn't matter so much.

Also I recommend you use https://github.com/bvaughn/react-window instead. Same author but more focused and lightweight.

I like the convenience of CSS-in-JS especially being able to co-locate styling but I’m not convinced on a few of things:

  1. That hashed classes are a “must have” instead of namespaced classes, and could even be annoying in 3rd party components.
  2. That using logic in your CSS is necessarily better or more readable, and is also a performance killer (more on that below).
  3. That it’s a good idea to add 25kb+ of minified JavaScript to your 10kb NPM component (not a big deal for an app however).

At first you go on your merry way and don’t notice any performance…

JS-in-CSS is now common practice, and your framework of choice probably provides a means to theme with JS Objects and a Provider. I’m going to put the case forward that you’re better off choosing CSS Variables for performance, and how you can easily use them with any framework and still allow the consumer of your components to use JS Objects for convenience.

Changing CSS Variables (e.g. changing themes) is significantly more performant, it doesn’t require React to re-render your entire app (or re-render almost anything in fact) and the changes will be instant. This is why frameworks like Emotion have…

When hooks came out there were various articles suggesting Redux might no longer be needed, and ripostes like these which argue (rightly) that useReducer is not a replacement of Redux as it’s cumbersome for a global store:

Then as a counter-counter argument some suggested using React Context as a solution to share the state and dispatcher throughout the app:

However this method has a significant drawback to performance — as per Caveats in the React docs, whenever a new object reference is passed into <Provider value={..}>, all consumers will be re-rendered. …

When you search online OAuth seems intimidating; you’ll find lots of useless flow diagrams, and packages like PassportJS make it seem complicated because configuration is challenging as it is.

In this express example we’ll authenticate with GitHub, but the same process applies to all OAuth providers.

Step 1: Redirect the user to the providers auth access page

We could do this directly, but going to our API first allows us to set cookies so that we can share state between the auth request and success responses.

This is important for two reasons:

  1. We can pass the recommended but optional “state” query param to the OAuth provider which prevents Cross-Site-Request-Forgery
  2. (Optional) We…

2020 Update: You might be interested in learning how to build a store from scratch which works with Redux Devtools and uses React Hooks to access it anywhere instead:

I was inspired to write this today after a colleague new to React complained about how much boilerplate is involved when using Redux (and Redux-Saga). So I put this together for a couple reasons:

  1. We mistakenly think verbosity is necessary for a one-way data-flow.
  2. We use Redux without understanding how it works.

For our simple Redux store we want the following features:

  • A function to update the store state (because we…

JavaScript has grown up and people feel their large UI projects must be tested. But I argue that while we’ve moved more logic to the client, testing as it’s usually done is wrong and will cost your product time and money whilst not adding much value.

The problem with Unit Tests

Unit tests originated from non-UI projects, and it makes sense for them. At least most of the time. Take a utility library like LoDash for example. It has a method called cloneDeep. Deep cloning an object in JavaScript has gotchas that would trip-up a naive implementation. Tests could be written in advance (TDD) to…

Dominic Tobias

I make UIs and such. Using JS mostly but I like to dabble.

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