Sebastian Kranz
@sebastiankranz.de
Another disadvantage is that you loose reactivity on the props. Since dialogs are short-lived you may not run into this for a while, but it still breaks one of the core-assumptions of the framework.
December 18, 2025 at 12:08 PM
Another disadvantage is that you loose reactivity on the props. Since dialogs are short-lived you may not run into this for a while, but it still breaks one of the core-assumptions of the framework.
I eventually went back to declaring it in JSX, because I couldn't find an elegant way to express the aria-attributes on the trigger and return focus to it.
December 18, 2025 at 12:08 PM
I eventually went back to declaring it in JSX, because I couldn't find an elegant way to express the aria-attributes on the trigger and return focus to it.
I don't doubt that, just like you can build a data fetching library on top of hooks/signals/stores/whatever, you can build these coordination-abstractions on top of events. But you still need the abstraction itself. In that sense, it's a bit like saying events let you replace useQuery.
December 10, 2025 at 5:29 PM
I don't doubt that, just like you can build a data fetching library on top of hooks/signals/stores/whatever, you can build these coordination-abstractions on top of events. But you still need the abstraction itself. In that sense, it's a bit like saying events let you replace useQuery.
That's a level below what these hooks are trying to solve though.
What if multiple optimistic updates overlap and are possibly entangled? What if a transition triggers one or multiple loading states? What if the user fires two requests and now you have a race-condition?
What if multiple optimistic updates overlap and are possibly entangled? What if a transition triggers one or multiple loading states? What if the user fires two requests and now you have a race-condition?
December 10, 2025 at 5:29 PM
That's a level below what these hooks are trying to solve though.
What if multiple optimistic updates overlap and are possibly entangled? What if a transition triggers one or multiple loading states? What if the user fires two requests and now you have a race-condition?
What if multiple optimistic updates overlap and are possibly entangled? What if a transition triggers one or multiple loading states? What if the user fires two requests and now you have a race-condition?
Feels like a workaround, but you can double tap (...).
I'm sticking to the other layout. This wouldn't be the first time Apple backtracks on Safari's design.
I'm sticking to the other layout. This wouldn't be the first time Apple backtracks on Safari's design.
December 10, 2025 at 12:30 PM
Feels like a workaround, but you can double tap (...).
I'm sticking to the other layout. This wouldn't be the first time Apple backtracks on Safari's design.
I'm sticking to the other layout. This wouldn't be the first time Apple backtracks on Safari's design.
use(DeferredValue|Transition|Optimistic) are for handling loading states. How does R3's model remove the need for these?
December 10, 2025 at 12:14 AM
use(DeferredValue|Transition|Optimistic) are for handling loading states. How does R3's model remove the need for these?
Is that Fork?
I use the following custom command as a commit action.
Works both from the commit log and when viewing the history for a single file (right click / history).
I use the following custom command as a commit action.
Works both from the commit log and when viewing the history for a single file (right click / history).
November 29, 2025 at 10:05 AM
Is that Fork?
I use the following custom command as a commit action.
Works both from the commit log and when viewing the history for a single file (right click / history).
I use the following custom command as a commit action.
Works both from the commit log and when viewing the history for a single file (right click / history).
It's still the best overall, but all the papercuts and bugs make me want something else.
For example, when replying to someone named "Lastname, Firstname", Spark will sometimes interpret that as 2 recipients.
For example, when replying to someone named "Lastname, Firstname", Spark will sometimes interpret that as 2 recipients.
November 20, 2025 at 12:05 PM
It's still the best overall, but all the papercuts and bugs make me want something else.
For example, when replying to someone named "Lastname, Firstname", Spark will sometimes interpret that as 2 recipients.
For example, when replying to someone named "Lastname, Firstname", Spark will sometimes interpret that as 2 recipients.
It's funny how we can't rely on our intuition anymore, when the code we're reviewing is stochastically engineered to look maximally correct.
November 4, 2025 at 11:31 AM
It's funny how we can't rely on our intuition anymore, when the code we're reviewing is stochastically engineered to look maximally correct.
Am I the only one who dislikes hiding based on scroll direction?
You scroll slightly to far, go back up and immediately have a title bar in your face.
You scroll slightly to far, go back up and immediately have a title bar in your face.
October 22, 2025 at 6:12 PM
Am I the only one who dislikes hiding based on scroll direction?
You scroll slightly to far, go back up and immediately have a title bar in your face.
You scroll slightly to far, go back up and immediately have a title bar in your face.
There's getOwnPropertySymbols, but now I feel like we're just bending the system to stop others from bending the system.
My issue isn't with performance, but readability. One of the documented use-cases for Symbols is weak information hiding, so it feels more obvious to me.
My issue isn't with performance, but readability. One of the documented use-cases for Symbols is weak information hiding, so it feels more obvious to me.
October 15, 2025 at 3:50 PM
There's getOwnPropertySymbols, but now I feel like we're just bending the system to stop others from bending the system.
My issue isn't with performance, but readability. One of the documented use-cases for Symbols is weak information hiding, so it feels more obvious to me.
My issue isn't with performance, but readability. One of the documented use-cases for Symbols is weak information hiding, so it feels more obvious to me.
If we're trying to keep the member inaccessible outside the module, isn't this what symbols are for?
const value = Symbol()
class A {
[value]: ... // can't be accessed without the symbol
}
developer.mozilla.org/en-US/docs/W...
const value = Symbol()
class A {
[value]: ... // can't be accessed without the symbol
}
developer.mozilla.org/en-US/docs/W...
Symbol - JavaScript | MDN
Symbol is a built-in object whose constructor returns a symbol primitive — also called a Symbol value or just a Symbol — that's guaranteed to be unique. Symbols are often used to add unique property k...
developer.mozilla.org
October 14, 2025 at 6:18 PM
If we're trying to keep the member inaccessible outside the module, isn't this what symbols are for?
const value = Symbol()
class A {
[value]: ... // can't be accessed without the symbol
}
developer.mozilla.org/en-US/docs/W...
const value = Symbol()
class A {
[value]: ... // can't be accessed without the symbol
}
developer.mozilla.org/en-US/docs/W...
I hope we get to see it on YouTube eventually. Your discussions in the last 2 weeks were really helpful for finally understanding the intentions behind transitions.
October 8, 2025 at 9:39 AM
I hope we get to see it on YouTube eventually. Your discussions in the last 2 weeks were really helpful for finally understanding the intentions behind transitions.
What is the advantage of tying actions directly to elements, rather than having a composable hook?
September 17, 2025 at 11:34 PM
What is the advantage of tying actions directly to elements, rather than having a composable hook?
I personally liked passing the pending state explicitly, since its more flexible, eg when the action is triggered from inside a menu:
<ComboBox>
<TriggerButton loading={...} />
<Content>
<Item onClick={...} />
</Content>
<ComboBox>
<ComboBox>
<TriggerButton loading={...} />
<Content>
<Item onClick={...} />
</Content>
<ComboBox>
September 17, 2025 at 11:34 PM
I personally liked passing the pending state explicitly, since its more flexible, eg when the action is triggered from inside a menu:
<ComboBox>
<TriggerButton loading={...} />
<Content>
<Item onClick={...} />
</Content>
<ComboBox>
<ComboBox>
<TriggerButton loading={...} />
<Content>
<Item onClick={...} />
</Content>
<ComboBox>
The docs have this example, which also uses state for portal targets: react.dev/reference/re...
createPortal – React
The library for web and native user interfaces
react.dev
August 25, 2025 at 8:30 AM
The docs have this example, which also uses state for portal targets: react.dev/reference/re...
…right, I forgot that useRef wouldn’t trigger a rerender anyways. Maybe like this?:
```
const [el, setEl] = useState()
return <>
<div ref={setEl} />
{el && createPortal(..., el)}
</>
```
I'd probably accept the rerender, since the only duplicate work is that one portal target.
```
const [el, setEl] = useState()
return <>
<div ref={setEl} />
{el && createPortal(..., el)}
</>
```
I'd probably accept the rerender, since the only duplicate work is that one portal target.
August 25, 2025 at 8:28 AM
…right, I forgot that useRef wouldn’t trigger a rerender anyways. Maybe like this?:
```
const [el, setEl] = useState()
return <>
<div ref={setEl} />
{el && createPortal(..., el)}
</>
```
I'd probably accept the rerender, since the only duplicate work is that one portal target.
```
const [el, setEl] = useState()
return <>
<div ref={setEl} />
{el && createPortal(..., el)}
</>
```
I'd probably accept the rerender, since the only duplicate work is that one portal target.
Why is useRef a problem?
August 24, 2025 at 7:33 PM
Why is useRef a problem?
The materials are all significantly less transparent. This may ofc be due to the screenshots only showing very controlled scenarios, but I take it as a sign that the current state of the beta isn't what they intended.
Also, the reduce-motion setting supposedly turns off some of the refractions.
Also, the reduce-motion setting supposedly turns off some of the refractions.
June 14, 2025 at 12:55 PM
The materials are all significantly less transparent. This may ofc be due to the screenshots only showing very controlled scenarios, but I take it as a sign that the current state of the beta isn't what they intended.
Also, the reduce-motion setting supposedly turns off some of the refractions.
Also, the reduce-motion setting supposedly turns off some of the refractions.
Things that I personally like:
- Scroll edge effects solve the issue of scrollable content just disappearing into a divider, like here on Bsky. Not knowing whether a view is scrollable has been a recurring complaint in the past.
- The toolbar design finally gives all buttons clear shapes again.
- Scroll edge effects solve the issue of scrollable content just disappearing into a divider, like here on Bsky. Not knowing whether a view is scrollable has been a recurring complaint in the past.
- The toolbar design finally gives all buttons clear shapes again.
June 14, 2025 at 9:35 AM
Things that I personally like:
- Scroll edge effects solve the issue of scrollable content just disappearing into a divider, like here on Bsky. Not knowing whether a view is scrollable has been a recurring complaint in the past.
- The toolbar design finally gives all buttons clear shapes again.
- Scroll edge effects solve the issue of scrollable content just disappearing into a divider, like here on Bsky. Not knowing whether a view is scrollable has been a recurring complaint in the past.
- The toolbar design finally gives all buttons clear shapes again.
They have a WWDC video explaining their rationale. IMO they're trying to address real problems.
Interestingly, the examples here have far fewer a11y-issues than the version shown at the keynote.
developer.apple.com/videos/play/...
Interestingly, the examples here have far fewer a11y-issues than the version shown at the keynote.
developer.apple.com/videos/play/...
Get to know the new design system - WWDC25 - Videos - Apple Developer
Dive deeper into the new design system to explore key changes to visual design, information architecture, and core system components...
developer.apple.com
June 14, 2025 at 9:35 AM
They have a WWDC video explaining their rationale. IMO they're trying to address real problems.
Interestingly, the examples here have far fewer a11y-issues than the version shown at the keynote.
developer.apple.com/videos/play/...
Interestingly, the examples here have far fewer a11y-issues than the version shown at the keynote.
developer.apple.com/videos/play/...
Many packages in the React-ecosystem seem to have spiked in 2025. Other frameworks declined. I wonder what's going on...
npmtrends.com/@tanstack/re...
npmtrends.com/@tanstack/re...
@tanstack/react-query vs react vs react-router vs svelte vs vue | npm trends
Comparing trends for @tanstack/react-query 5.76.1 which has 9,105,902 weekly downloads and 45,148 GitHub stars vs. react 19.1.0 which has 38,049,869 weekly downloads and 235,485 GitHub stars vs. react...
npmtrends.com
May 18, 2025 at 5:23 PM
Many packages in the React-ecosystem seem to have spiked in 2025. Other frameworks declined. I wonder what's going on...
npmtrends.com/@tanstack/re...
npmtrends.com/@tanstack/re...