Explore My Notes

Select your poison | Sarah Higley

A great overview of why a custom select component can be problematic:

  1. Windows and macOS both treat native equivalents differently, meaning you have different expected behaviour for screen readers and other accessibility software straight away (Android and iOS are same as macOS);
    1. And this gets even more confusing when you include <select multiple>, which is standardised across OSes but has very poor success rates in UX tests;
    2. And even-more even more confusing when you include autocomplete or filtering capabilities, which require use of an underlying combobox.
  2. ARIA already has three separate patterns (one still in discussion) so even the standards are confused;
  3. Different browsers (including different OS versions of the same browser) use different default keyboard configurations, and some are not "obvious" but are expected e.g. Enter should not trigger a form submission but most users may expect it to, making it hard to utilise in an accessible way (see second article as well for how confusing this can be).

In the followup article, user testing (albeit with a small sample size) showed that - to the surprise of none - the native select element is consistently the easiest to use across platforms for basic form requirements. However, <select multiple> was comfortably the worst user experience for multiselect. 🤔

Information wants to be free | Seth Godin

Information wants to be free or it wants to be expensive.

Both are true. It either benefits from everyone knowing it, or it becomes worthwhile because it is scarce.

The CSS Cascade | Amelia Wattenberger

I don't think I've come across a clearer explanation of the full cascade before, nor one so beautifully crafted. An excellent resource and inspiration.

The Perils of Rehydration | Josh W. Comeau

A great explanation of why two-pass rendering is a useful mental model to consider when working with server-side rendering/SSGs like Gatsby and JavaScript frameworks. The main point? Rehydration ≠ rendering, so don't load dynamic content until rehydration is finished if you want to avoid weird layout bugs and jankiness; use hooks or "Client-only" component abstractions instead.

Critically, rehydration is not the same thing as a render. In a typical render, when props or state change, React is prepared to reconcile any differences and update the DOM. In a rehydration, React assumes that the DOM won't change. It's just trying to adopt the existing DOM.

📆 04 Mar 2020  | 🔗

  • JavaScript
  • Gatsby
  • Jamstack
  • server-side rendering
  • React
  • rehydration
  • dynamic content 

CSS Grid Track Options | Dave Geddes

An excellent overview of (most of) the unit options you can use in CSS Grid columns and rows, with examples. (No RSS)

Web Performance Predictions for 2020 | Simon Hearne

Oh boy, there's a lot worth pulling out of this overview of upcoming web technologies:

[Mid-range Android phones are the] median device that web users have, Apple’s market share in terms of 2019 Q1 sales in the US is 39%, with Samsung at 28%, while the rest is a range of Android devices which sell for between $500 and $50 dollars.

In other words, as Simon says, the single biggest UX impact is the size of JS shipped. Mid-range phones don't just struggle to download large JS packages, they also struggle to process them quickly.

The web is an open and democratic place, when people are forced to use only native apps they have a limited window on the web experience and the knowledge available therein.

Truth. And, as noted, a part of that lock-in to native is the huge amount of framework code we're shipping, shuttering out those mid- or low-end phones. Jamstack static-site generators are marked here as one potential solution, though they still ship a lot more JavaScript then they might. I really hope Simon's prediction of more competition in the SSG hosting space comes true though; I love Netlify but shaking things up is always a positive.

Another potential solution is Web Assembly, which (apparently) compiles 20x faster than JS 😲 That could significantly decrease the JS load needed for, say, React by converting process-heavy parts to WASM. That could be a massive gain to the entire web community by one team's efforts:

In this example a single React release could raise the tide of web performance for all React-based websites.

In terms of Google's proposed "slow website" badge, Simon raises some interesting counter points:

Who knows what the workaround techniques will be: loading screens like 1999, screenshots rendered while the page loads in the background, UA sniffing to deliver a faster experience to googlebot.

He also takes aim at Google Analytics trailing behind on key UX features like Real User Measurements (things like largest contentful paint and blocking time). I'm not sure I buy this quite as much, but any (non-invasive) improvements to the metrics that GA provides would be welcome.

Slow sites cost money, and observability helps us to allocate funds to improve performance.

How to use React Context Effectively | Kent C. Dodds

I guess I'm reading up on React Context a lot today. Kent provides a useful step-by-step guide in his normal steady manner, which I found pretty easy to grasp. He also makes a very valid point:

Context does NOT have to be global to the whole app, but can be applied to one part of your tree

I've yet to need context very heavily, but this feels like a solid rule of thumb: if it can be localised, do it. It's also interesting hearing his thoughts on default states:

None of us likes runtime errors, so your knee-jerk reaction may be to add a default value to avoid the runtime error. However, what use would the context be if it didn't have an actual value? If it's just using the default value that's been provided, then it can't really do much good.

Finally, I'm a big fan of how he imports hooks as a priority via his context API. It just feels a lot cleaner that way 👍

📆 03 Mar 2020  | 🔗

  • JavaScript
  • React
  • JavaScript
  • Context API
  • state management 

And it Bends Towards Justice | Seth Godin

The Rev. Martin Luther King Jr. quoted Theodore Parker: “The arc of the moral universe is long, but it bends towards justice.”

But it’s not bending itself. And it’s not waiting for someone from away to bend it either.

It’s on us. Even when it doesn’t work (yet). Even when it’s difficult. Even when it’s inconvenient.

Manage Global State with Contact API and Hooks | React Christmas

Jonas has put together a useful overview of why the "new" Context API in React is probably a better option than Redux for many simple use cases, as well as step-by-step instructions on how to set up a Redux-like global store using it.

In combination with the useContext and useReducer hooks we can create a global store that manages the entire app’s state and supports convenient ways to update the state throughout the app regardless of how deep the component tree goes.

The only downside to this approach appears to be scalability, but honestly very few sites are going to need to track more than 2-3 pieces of global information which this should manage nicely.

📆 03 Mar 2020  | 🔗

  • JavaScript
  • React
  • state management
  • Redux
  • Context API
  • global state 

Inversion of Control | Kent C. Dodds

I have a tendency to prefer the kind of "inside-out" control that Kent is advocating in this piece, though I've never head it called "inversion of control" before. The idea of giving your users the ability to manipulate the output of a given function/API is a great way to futureproof your work and something I think is generally useful doing earlier rather than later.

The problem comes, as he identifies, when you overdo it:

What if that's all we ever needed filter to do and we never ran into a situation where we needed to filter on anything but null and undefined? In that case, adding inversion of control for a single use case would just make the code more complicated and not provide much value.

So how do you walk that fine line? Like most things, there's a lot of grey in the decision. Personally, I like to do things with no inversion first, sticking to the principle of "doing one thing well". Then, if I (or others) find that they need to extend that functionality, I begin adding overrides. Overrides are great for maintaining existing code and allowing for an inversion of control. For example, in the pseudo-array-filter example Kent uses, I would cede control of the filter options to a prop/variable (as he does), but then add a line that populates that variable with the original null and undefined checks if it's blank. That way existing implementations still work, nothing breaks, and moving forward the code is much more flexible (and, crucially, avoids the multiple-extension spaghetti that we're trying to avoid).

Sure, occasionally someone might inadvertently duplicate that setup, by re-specifying the default behaviour in the function call, but that's fine. If you didn't set the default behaviour every call would have to do that anyway, so it still saves time in the long run, and you avoid pre-extending code that never needs the flexibility in the first place.

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.