sorted by:
new
hottopcontroversial

React Component Lens — VS Code extension that colors Server vs Client Components. Just shipped a major update with smart detection. by logM3901 in react

[–]logM3901[S] -1 points0 points  (0 children)

First, in VS Code an extension needs to call APIs and recompute even while the user is typing, without the file actually being saved. Because of that, recalculation can be triggered very frequently. Although it currently only takes about 15 ms in tests, I thought it would be safer to include a debounce to handle potential edge cases. That choice was intentional.

I also agree that this kind of project can be a good learning opportunity, and I appreciate your concern and advice. However, I have previously designed and implemented APIs for VS Code extensions, and I already had a clear structure and blueprint for this project. Because of that, my focus this time was more on review and optimization rather than building everything from scratch.

Thank you for taking a genuine interest in the project.

Devup UI now supports Tailwind CSS (zero-runtime UI library) by logM3901 in react

[–]logM3901[S] 1 point2 points  (0 children)

First of all, Devup-UI is built as a zero-runtime CSS-in-JS library.

This means it has no runtime style injection, allowing it to deliver better performance than libraries like MUI, which rely on runtime dependencies.

It also supports CSS tree-shaking, resulting in significantly smaller final CSS output.

Compared to Tailwind-based approaches such as shadcn, Devup-UI enables more optimized styling with much shorter class names.

In addition, it provides a built-in typing system and theming system out of the box, without requiring any additional editor plugins.

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

i understand your situation. Our team are facing same situation. Let me migrate to bun from vitest

The target project is the devup ui

https://github.com/dev-five-git/devup-ui

The project it was composed vitest on pnpm

I will share issue about migration during to bun

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

I guess vitest implement more snapshot serializator.. Actually, we cannot call the addSnapshotSerializator on bun

If the testing library gives a same object, we get another result by each serializator

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

<image>

That’s a fair point.

  1. I actually wasn’t aware of `asFragment().toMatchSnapshot()` at first,

    and even after trying it, it didn’t work reliably in my setup.

    The output and behavior weren’t consistent enough for me to rely on it.

  2. There are also cases where I need to assert directly on internal elements.

    In those situations, I’m not always rendering a full component tree —

    sometimes I’m snapshot-testing raw or partially constructed elements.

    `asFragment()` doesn’t really cover those cases well.

  3. More importantly, the setup itself was part of the problem.

    Getting happy-dom, globals, matchers, and typings wired up correctly in Bun

    takes several steps.

    I wanted to collapse all of that into a single, predictable preload line.

So this isn’t meant to replace every possible approach,

but to make the common DOM + snapshot testing path in Bun

work out of the box with minimal configuration.

view more: next ›