Sebastian Markbåge

I moved to Bluesky for higher quality content that I’m more aligned with which is true to some extent. However I realized what I really like about it is *less* content and that I like zero even better. So I think I’m getting off of Bluesky as well. I didn’t need better social media but none.

Like I spent a ton of work getting RSC and owner stack traces to be easy to implement in any framework. Testing it out in Next.js, only to get comments like this:

bsky.app/profile/afuz...

I wish I had just kept it all in Next.js instead.

It can't have been more right. Both App Router and RSC are both coming from my vision for both. You may not like the outcome but there's no such thing as React taking it back.

This is why I don't want to contribute to new features to React anymore because anti-Next.js sentiment is souring it.

Tbh, I like the AI DJ voice on Spotify trained on Xavier Jernigan. It adds value over just randomly playing tracks.

The bug in development you ran into has been fixed.

We also added a warning for duplicate view transition names which is also in your demo.

You can try it out with latest Next.js canary.

React 19.1 enables Server Components in Parcel with React Stable (not only canary)! Just released Parcel v2.14.3 with the corresponding update. 🥳

Well, with one exception. It doesn't have a pending status. We went with `.status = "pending"` for that.

And the shape of the information exposed is already spec:ed in allSettled!

Promise.allSettled() - JavaScript | MDN The Promise.allSettled() static method takes an iterable of promises as input and returns a single Promise. This returned promise fulfills when all of the input's promises settle (including when an em...

React looks for the same names of the fields as allSettled.

developer.mozilla.org/en-US/docs/W...

They can also be updated after it resolves. This is used by RSC when it provides data to React to allow streaming to be free when it's already loaded. Other libraries can use the same optimization.

class RejectedPromise extends Promise {
constructor(reason) {
super((resolve, reject) => reject(reason));
this.status = 'rejected';
this.reason = reason;
}
}

class ResolvedPromise extends Promise {
constructor(value) {
super(resolve => resolve(value));
this.status = 'fulfilled';
this.value = value;
}
}

You can pass sub-classed Promises to React such as in use() with the fields status and value or reason.

This allows React synchronously read the value without waiting on a microtask. This is much faster but it also ensures compat when someone needs flushSync().

Microtasks are bad, mkay.

You're not from New York unless you were born in the five boroughs, definitely not New Jersey, but with the right attitude you can be a True New Yorker.

Long Island City is in Queens which is on Long Island but not out on Long Island.

Western New York is basically Canada.

Long Island excludes Queens which on Long Island.

Westchester is upstate from New York but not in Upstate New York.

Upstate New York includes Connecticut and Vermont.

New York, New York, New York so good they named it thrice+.

New York County is Manhattan.
New York City is larger than the county and includes the five boroughs.
New York State includes all of them.

The city is Manhattan, i.e. New York County.

The Tri-State area is the New York metropolitan area.

I learned from scuba and snorkeling not to trust sunscreen in water. I just reapply after dry and not expecting to get back in the water.

As a fellow ghost, long sleeve rash guard is the way.

It would be something you register with RN and then refer to by the generated "class" but it can also be built-ins.

The "className" prop name is expected to change though so in React it won't actually have the word "class" in it anyway. You often use the enter/exit/update/share ones instead.

The idea is that ideally you would actually have a CSS library specifying a bunch of different view-transition-classes and you'd just pick among those.

The React API makes more sense from that perspective because otherwise you might expect more low level helpers for filling in the values.

developer.chrome.com/blog/view-tr...

github.com/facebook/rea...

github.com/facebook/rea...

Use valid CSS selectors in useId format by sebmarkbage · Pull Request #32001 · facebook/react For the useId algorithm we used colon : before and after. #23360 This avoids collisions in general by using an unusual characters. It also avoids collisions when concatenated with some other ID. Un...

But yes, useId also works for generated styles that has to be dynamically generated for a specific instance.

github.com/facebook/rea...

You can also use programmatic approaches for generated styles. Those don't work with SSR triggered transitions (Suspense) though.

github.com/facebook/rea...

The recommended approach is to use view-transition-classes specified and not style using names.

<ViewTransition className="...">*

You can also specify different ones for enter/exit/update.

* Note this prop name is likely getting renamed.

Note that there was a period where the framework detection code relied on an HTML attribute which was removed in 18. Therefore adoption of 18 was lost for a period before the detection mechanism updated. Not sure but it might explain temporary gap in growth. It's a data collection bug.

Man, I love mainstream health science so much. It’s just so simple when you ignore all the made up stuff from influencers.

I've been working through a lot of browser bugs lately but tbh I wouldn't trade it for less ambitious work from browser vendors.

I can do a lot more with a buggy API than no API at all.

For example, in Next.js you'd call cookies.set() in a Server Action and then use that cookie to render the toast from a different Server Component. Then trigger an Action that resets it once shown.

We have some ideas for more built-in features around this pattern.

I think toasts in general should be a server-side side-effect that ends up getting stored in a more permanent storage. E.g. user database of notifications, or even just cookies.

The side-effect can then be observed by a toast system on the client.

Wouldn't you want MPA forms (not yet enhanced) to be able to show toasts too? At least in theory. It ideally should also be more permanent for example if you navigate away from the form while it's still sending, or if you switch tabs you should still be informed.