iiinova — where your digital self keeps evolving

Yeah it's deceptively tricky. In the next version of our design system at work we're gonna remove the tooltip component, it's just too hard to get people to use it correctly. We'll just have props to allow relevant components to have a tooltip (eg. IconButton)

010

For example if a tooltip just shows the full value of a piece of truncated text, it shouldn't be linked with aria-describedby lest the label be announced twice by screen readers In this use case the tooltip only exists for users _not_ using a screen reader

On top of that it's not even clear what the best default experience is, because there are always use cases where having an accessible label is required and where it absolutely shouldn't exist

But this is actually impossible to implement in React without relying on mutation observers. And even that relies on being able to get a ref to the trigger's HTML node, which isn't always possible

100

Firstly, what if the trigger supplies a description of it's own? Should Tooltip content A: Override it B: Merge with it C: Yield to it I'd say B is the best default behaviour because A & B throw away context

Tom Sherman @tom.sherman.is · 16/09/2026

Accessible tooltips are incredibly hard to build as a generic component in React (and I assume other component-based frameworks) It's way harder than just linking the tooltip text to the trigger with aria-describedby

130

The novel UX benefit over using a password manager is that a passkey is also time based, so you don't need a secondary TOTP.

030

Tom Sherman @tom.sherman.is · 10/09/2026

It's massively inspired by Effective RSC. It extracts the parts out that make sense for use in a framework agnostic way

nikhilsnayak.dev

Introducing effective-rsc

An Effect-native React Server Components framework for Bun, built on Rspack and the Navigation API.

000

Tom Sherman @tom.sherman.is · 10/09/2026

I'm still not sold on the syntax noise, it feels weird when you're trying to just compose UI. But if all of your data layer and business logic is in already in Effect it might make sense instead of doing `await Effect.runPromise(e)` in every server component

100

Tom Sherman @tom.sherman.is · 10/09/2026

You write server components and server functions using Effect, and it integrates into React and the framework (Next.js adapter in the repo) to scope resources to the request or the process

100

For React Server Components, yeah. But that's not render blocking either.

Maybe in a bad React app, but a good one will return usable HTML from the server.

I know this question is mostly rhetorical but one answer is: Not all bytes are created equal. CSS is render blocking, JS is not.

Tom Sherman @tom.sherman.is · 07/09/2026

I'd love to see an example if you have one!

000

People that self host their observability stack: what do you use for frontend RUM?

Tom Sherman @tom.sherman.is · 06/09/2026

No caption button on either on Android for me

000

bsky.app/profile/tom....

100

Yeah I remember @jakearchibald.com writing about how this is deceptively complicated to add

100

Can you share a link to this post?

100

What apps have you used that do this well/correctly? Specifically apps that have some complex shell-like navigation, like Jira or Notion. I haven't found one that implements this pattern yet

100

None of the people recommending that you do this seem to capture the nuance, it's just "move the focus". I've found zero apps that do this so it begs the question: is implementing it the "correct" way more surprising than keeping the focus on the nav link?

000

Agree. But I think there are genuine reasons for some UIs (not all) to keep the focus on the nav item, I'm thinking of UIs that have a shell with sidebar back items. I feel like it's a bit weird to move the focus to the inner frame on navigate, that feels more disruptive than helpful

100

I think that's the reason why frameworks or routers don't build it in by default, they can't guarantee a good experience so they just fall back to the safe decision of keeping focus on the link.

010

I feel like this is just a massive case of "it depends", with moving focus at least. It depends on the exact UI, app, demographic, user type, demographic etc. Adding live region announcements for a route change seems like a no brainer, very little reason not to do that that I can see.

000

Many apps/routers/frameworks do include live region announcements for route changes but don't move focus, even though I see that both measures are recommended equally by accessibility advocates

100

Tom Sherman @tom.sherman.is · 29/08/2026

So, it's recommended that nav links move focus to the main content by #a11y experts. But I can't find a single app that actually does this outside of static content apps. All of the apps of any complexity that I've checked don't work this way What gives?

411

Get business idea Realise I can't do sales Realise I don't have any friends that are good at sales Give up on idea Repeat 😂

030

Tom Sherman @tom.sherman.is · 26/08/2026

And just like clockwork GitHub actions is down. The same time every day it feels like. You'd think GitHub would have worked out which time Americans wake up at this point and pre warm their infra or something

280

Tom Sherman @tom.sherman.is · 23/08/2026

Time for a bloom filter maybe?

100

The important thing is that there is full suspense support and my understanding was that the prefetchInRender flag was the closest thing to that in RQ today

This part is why I'm not fussed about the actual API being use(promise) or not, if RQ needs to encapsulate it inside use(Suepense)Query to keep those features then so be it

100

I'm not seeing any problems with either of those tbh, pretty sure it's the recommended approach with RQ today anyway. Put it in the fetcher or derive it in render. They removed the onSuccess callbacks a while ago

100

they can never convince me that sin and cosine are the same. sin is a wave and cos is literally just a v like what do you mean

140

@ricky.fm was discussing with the team about this but I don't know where it got to. My assumption was that the reason this didn't get traction was because there was tension in these changes and the way the RQ API (or maybe the core/react split pattern) works, but I don't know for sure

My understanding was that RQ's cache needed to be changed to be based around [next, prev] states to properly support concurrent rendering, which sounds like the root of the issue you described

Both Relay and Fate both work by reusing promises (well, they both use their own thenable resources but same thing really)

100

Customising the result can just be done in render or in the fetch function, no?

100

With that in place I think you'd be able to use() a promise in the same component just fine. Unmounting wouldn't be an issue because there would be no effect to worry about (for the fetch, you'd still have a subscriber for revalidation ofc)

Otherwise, how is useRequest in Fate or useLazyLoadQuery/useQueryLoader in Relay supposed to work?

I'm not sure I follow completely. Surely allowed to initialize a promise in render (not in uSES/useEffect) as long as it's cached/idempotent. Multiple renders give you back the same promise etc. If this isn't the case then I dunno wtf "render as you fetch" is supposed to mean

Can you say more about the blockers within the library stopping this from being possible? Tbh I'm not attached to the API, "full suspense support" is much more important. I assume that's entangled here too?

Tom Sherman @tom.sherman.is · 14/08/2026

Preloading can still be done with useEffectEvent right? Or just calling prefetchQuery in render? It's just that it's not enforced in the API itself

220

Custom protocol handlers have really bad browser support and even worse UX, there's a reason why universal links are preferred these days over custom protocols even in native apps It's a dead end IMO

130

Tom Sherman @tom.sherman.is · 13/08/2026

Doesn't apply to X obviously but Meta is a public company and so has a legal duty to it's shareholders to not lie about these numbers right? ... Right?!