Sandro

Lucky you - we use a component library that often re-creates DOM elements when unstable values or callbacks are passed in 🤷‍♂️ 😢

Isn't that expected as Recoil is no longer maintained?

> Reproduction: I'm not lying

😂

I don't have many email newsletters and just keep them in Readwise Reader. What's your workflow? Maybe you can use Kill the Newsletter.

Here we go 🥳

Finally found a way to archive interesting blog posts.

From RSS into Readwise Reader → Download via Reader API → Extract content as Markdown → Create Markdown file with Frontmatter → Move into Obsidian Vault → Create table with Obsidian Base 🚀

I'm struggling a lot with that 🤔 I use Readwise for RSS and email, but it’s not great for code-heavy articles or long-term bookmarking. Raindrop is good for bookmarks but lacks RSS/email. Obsidian + Clipper sounds nice for archiving, but syncing from Readwise is manual (and I'm lazy).

You can already display properties 🤨

Nice setup 👍 We use Vitest + happy-dom but we'll evaluate Vitest's browser mode when it's stable.

We have units tests for transition-heavy machines that are not fully covered by UI tests. UI tests give as much more confidence, they test everything together (just API request are mocked).

Then you don't test the UI components?

> [...] to validate my machines

Do you test your machines directly? I sometimes write test for the machine itself but mostly prefer to test the UI and treat the machine as an implementation detail.

And the UI doesn't even have to be implemented as a state machine for model-based testing.

I still need to learn more about how to model the machine for model-based testing, I think it's harder than modelling a machine for the app itself.

@davidkpiano.bsky.social Maybe something for your next talk 😉

I think Model-based testing is helpful if there are many UI states and interactions. Writing tests manually for all the possible transitions is a lot of work and it's easy to overlook some paths.

I just used Model-based testing for the first time. It's in a small side-projection and traditional tests would actually work fine for this use case. I'm still waiting for a good use case to come up at work.

I could be wrong but I think it happens if the promise resolves in less than 300ms (min duration for Suspense AFAIK) and the sibling component is updated after the promise resolved but before the 300ms are reached.

Interesting, I just have 3 snapshots (not 4) with the Body only being rendered once ("This is the first time the component rendered"), but render count is 2.

It's also reproducible with just `use(someStaticPromise)` without a query, so it's not doesn't seem to be related to uSES.

Model-based testing with XState helps you test your app more thoroughly without writing every test by hand. You define the model, add test code for states and events, and XState generates the rest. Here, I’m running over 60 tests from just one model. 🚀

#testing #xstate #statemachine

Not that bad 😇 but I'm unsure if it's a good idea, as plain HTML introduces other issues, such as overly long text lines that hinder readability 🤔

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...

It should not be needed in upcoming versions: github.com/facebook/rea...

My interactive playground for CSS selectors now uses @tanstack.com Start + Router. I also redesigned the homepage and added a few more selectors.

Do you miss a selector?

#css #react #tanstack

- Integration of other libs/state like a router.
- Simplify machines with many transitions (e.g. wizards, users can nav back to any not skipped step until submit state). Not sure how this could look like.
- Derived context/selectors
- Better type-safety
- Tell Copilot that v5 was released

A Visual Studio Code screenshot showing a TypeScript code snippet for defining German translations. The cursor is positioned at the value of the translation key "sidebar.navItemToggle.label," and an autocomplete popover suggests the default English translation "Toggle {{ title }}" as a possible value.

Using string union types for handling translations not only autocompletes the keys but also provides their default English translations. This helps you understand what to translate and identifies available dynamic values. TypeScript is incredibly powerful! 🚀

#TypeScript #i18n

```tsx <!-- Approach 1: as prop --> <Dialog.Close as={MyButton} variant="outlined"> <Icon /> <span>Close</span> </Dialog.Close> <!-- Approach 2: asChild prop (Radix UI) --> <Dialog.Close asChild> <MyButton variant="outlined"> <Icon /> <span>Close</span> </MyButton> </Dialog.Close> <!-- Approach 3: render prop (Ariakit) --> <Dialog.Close render={<MyButton variant="outlined" />}> <Icon /> <span>Close</span> </Dialog.Close> ```

React Component Composition with polymorphism is quite tricky. You loose type-safety and it's easy to break a11y.

The `as` prop is probably the worst (slow type checking + ambiguous props). `asChild` hurts readability and introduces additional nesting. Is @ariakit.org's `render` approach the best?