Hacker News Reader

    >  ...when I could create a reactive external component that I can import into a .svelte template...That means you can write vitest tests against it, but get the benefits of reactivity. That is truly powerful and, AFAIK, unique in the frontend world.

Isn't this the same as Vue composables?

Composable: https://github.com/CharlieDigital/vue3-state-definemodel/blo...

Vue Component: https://github.com/CharlieDigital/vue3-state-definemodel/blo...

BTW, I agree it's a very good pattern in general; especially good if you end up reusing logic with different templates/UI.

Can you share an example of a testable vue component? I would like to see that.

I got disillusioned around Vue 2. When they had proxies in front of class attributes that looked like functions, it really made it hard to instrument inside of tests. Maybe this is fixed now. But, it left a bad taste in my mouth.

The VueUse library is a really good place for these since it's all composables like `useClipboard`.

Here's an example of a Vue composable for the clipboard: https://github.com/vueuse/vueuse/blob/main/packages/core/use...

Here is an example of how it's used: https://github.com/vueuse/vueuse/blob/main/packages/core/use...

And the unit tests: https://github.com/vueuse/vueuse/blob/main/packages/core/use...

Another one from the same lib: https://github.com/vueuse/vueuse/blob/main/packages/core/use...

Unit test: https://github.com/vueuse/vueuse/blob/main/packages/core/use...

I'm pretty certain that Svelte took inspiration from Vue composables and I'd also guess that the community will have a bit of friction before people start to get its use cases (same as it was with Vue when it was introduced).

With Vue 3 and the composition API, you can do basically the same things you're doing in Svelte. You can also add SolidJS and Preact to this list as well - the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events.

A good example in Vue is the top example in this page: https://test-utils.vuejs.org/guide/advanced/reusability-comp... The other examples show some other things you can do if you want, although I'd typically recommend against it - keep your signal-related code free of component/lifecycle-related logic, and it will almost always be much easier to test.

(As an aside, I'd add Angular to the list of frameworks that are easy to test, although the framework feels like it goes out of its way to convince you of the opposite. Services are just classes that maintain reactive data - originally via RxJS/Observables, although now signals are also supported - and if you keep them like that, they're fairly easy to test. Unfortunately, Angular's decorators/DI/module system is very pervasive, and at least when I was last using it, meant that even theoretically simple tests still needed lots of boilerplate. But theoretically, it belongs in the same category as the frameworks above.)

    > ...the magic ingredient in all these frameworks is signals, which allow you to have reactive data without having to have a UI framework to provide lifecycle events

This is something that I think a lot of devs don't fully appreciate. A recent writeup on the inverted reactivity model of React: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...

And short video walkthrough: https://youtu.be/7OhyP8H7KW0

That's just reactive programming, nothing new. It's sad that some people think it can only be achieved with wacky non-standard syntax.

This is something I didn't cover in my post, but I feel that's a bug, not a feature. Using runes instead of stores (which did the same thing in svelte 4) implicates the svelte compiler in every source file. This is ok if you're married to svelte, but it makes vendor lock-in even more rigid, since you would have to refactor all your regular utilities too when moving to a new framework.

If it's a similar transition to the one from Vue 2 Options API to Vue 3 Composition, then I expect there will be a bit of a bump, but it'll make a lot more sense afterwards. The VueUse library is probably the poster child for why this pattern is super useful.

These days, vendor lock-in hardly feels like a worthwhile consideration when evaluating frameworks. A near complete rewrite feels inevitable when transitioning from, say, React to Svelte.

One of my biggest gripe with svelte.

In the js world you're shooting yourself in the foot by choosing a framework that is as locked in as svelte (no vdom,domain-specific-language and their design philosophy), had to find this out the hard way.

I still respect svelte for it's engineering capability, but it's a 100% commitment with no off-road options ever, but if you need a framework for js and don't like react or angular then vue would be my choice.

I'm a bit confused about this - if I build something in React/Vue... I'm never going to be using Vue/React alongside it, or anything else. Am I missing something? Who's out there changing frameworks in existing projects?

Or is this about something else?

Not a lot of situations, but React in theory can be used down to specific pages enabling progressive adoption/ easier Swapping

Also, it's a things metaframeworks enable (Like Astro)

One way to reduce the lock-in would be to wrap runes in a Vue ref lookalike, it'd be no more worse than relying on Svelte 3/4's built-in store implementation.

I don't understand this comment. How is it different from hooks and JSX components? In React codebases theres a lot of logic in React-specific files.

I don’t even think it would be possible to "move to a new framework" without starting from near scratch.

I feel like I must be misunderstanding you. React is certainly unit testable and developers do test it - just ask react-testing-library (10M weekly downloads).

I'm not a Svelte dev, so I don't really follow the distinction you're drawing. What is it that supposedly makes Svelte more testable?

I haven't used React in a while so I'm happy to learn more.

When I look at this example it does not look like the code I would be using inside my webapp. I have a rule of thumb: my test code should look the same as the code when it is inside my app.

https://testing-library.com/docs/react-testing-library/examp...

My Svelte 5 runes test code uses the code in exactly the same way that I use it inside my .svelte templates. That's very different in my opinion.

testing-library (and react-testing-library by extension) has a very dogmatic "black box" approach to testing FE code. In many ways it more closely resembles e2e testing than more traditional unit testing does.

Personally, I think it's a PITA since it's pretty rare that copy (such as text labels) ever remains stable for very long, or are sufficiently unique on the page, so I do the "strongly discouraged" route of using data-testid attributes for everything (which also has the side effect of making people who write e2e tests happy, but I digress).

With all of that said, I find myself rather appreciating the approach. I don't need tests to mirror the implementation, only the interface.

Can you link to/post an example of how Svelte is tested that's different?

In the Full Example linked, the only code that it makes sense to talk about being in the app itself is the code to render the component, and that does look precisely the same.

The rest is the testing logic - inspecting the state of the DOM post-render, interacting with components by simulating events, and so on. I don't see how this could correspond to anything in the app proper.

Yeah to be fair testing a fetch request is not the best example right off the bat. That's an outlier IMO.

That said it's very very easy to write similar looking code using react testing library as long as you're good about separating business logic into a hook. Where it gets dicy & hard to test is when components have complex state/effects co-mingling with render logic.

Business logic is very easily testable as a hook, something like:

``` it('toggles switch state', () => { const {current} = renderHook(() => useSwitchState);

  expect(current.checked).toBe(false);
  current.toggle();
  expect(current.state).toBe(nextState);

} ```

Render logic is a bit different because React Testing Library's philosophy is to test as a user would interact with the UI, so that looks more like:

``` it('switches state on button click', () => { render(<Switch onToggle={mockOnToggle} checked={false} />);

  getByRole('switch').click();
  expect(mockOnToggle).toHaveBeenCalled();

}); ```

Fact is testing frontend code is really hard _because_ people don't build frontend code in isolation. I found that testing is much easier when using tools like storybook and browser-based testing tool (so no snapshot testing, no fake-dom).

Right now I am working on a legacy project with ~10 years of work into it, about 15% of the code in there I don't even know how to trigger in the application (lots of weird specific circumstances that require special types of accounts to trigger). I just had to make a small change to hundreds of files and it was hell to manually test it everywhere.

IMO almost all components should be able to be renderable in isolation and mocked data. Type systems help with this problem because they remove a whole layer of tests required, but it is not enough.

> It is as good as unit testing, but reactive in the browser.

I am confused about this because on the one hand, you seem to be hinting at my favorite, under-hyped aspect of testing, which is its use (via TDD) as a controlled-state print/debugger, but on the other you seem to be eliding the most popular--albeit, in my view, less important aspect (insofar as one aims for "working software over comprehensive documentation"[0])--the preservation of behavior across commits and into the future.

What am I missing?

Edit: re "reactive in the browser," that's how I run @benchristel/taste[1]

0. https://agilemanifesto.org/

1. https://github.com/benchristel/taste

> svelte people have always cast a narrow eye towards typescript and for good reasons as well.

Out of curiosity, could you elaborate on this a little?

Svelte supports TypeScript, but the project itself dropped it for JSDocs a year or so back.

Here's a discussion on it, with the first post from Rich Harris himself with some reasoning: https://news.ycombinator.com/item?id=35891259

But, briefly, TS is tricky if the entirety of the ecosystem isn't TS. It's becoming less of a problem, and things like deno and bun that have native support for TS are solving the problem, but Rich Harris made compelling arguments for why they went with JSDoc. And, I don't think that is a perfect solution either, but I can write code that runs even if the JSDoc isn't correct, and I can't do that when the TS compiler refuses to compile for some reason like an external library isn't right.

This is why the types-as-comments proposal for ecmascript could be a game changer, most ts files would magically become valid js files; no compilation needed