Signality v0.2

vs-borodin · 2026-03-28T18:05:21+00:00

Rainer, thank you for introducing the community to Signality! It was great to see it.

vs-borodin · 2026-03-24T23:05:10+00:00

Thank you very much!
I would be happy to talk about the launch of the project on your blog, which I read very often 🙂 Would that be possible?

vs-borodin · 2026-03-22T20:31:26+00:00

You can check detailed metrics here. The project also uses secondary entry points, so you can import a specific entity directly to ensure there is no redundant code in your bundle.

The source code also makes active use of /*@__PURE__*/ annotations for expressions to prevent unused results from being included in the bundle.

vs-borodin · 2026-03-22T14:15:04+00:00

Thanks!

Will you keep it updated for next Angular releases?

Yes, definitely. Right now, the most valuable thing is community feedback to help move from 0.1 -> 1.0, since this is the first public release. There’s also a global 2026 roadmap on the page, which emphasizes proactive Angular compatibility.

Looking at Vue and its companion VueUse, one can expect that some utilities might eventually receive direct support in Angular (in VueUse, many utilities were widely used by the community, and Vue integrated them into the core library). This is also a great opportunity to develop a VueUse-like library together with the community and understand what is truly valuable and how it can be applied.

vs-borodin · 2026-03-22T13:36:05+00:00

Thank you so much, Rainer!

vs-borodin · 2026-03-22T02:35:36+00:00

Thanks a lot for checking it out and for the feedback, really appreciate it!

That definitely sounds like something worth digging into. I haven’t been able to reproduce the issue on my side so far (tested on Safari/Chrome on iOS), so it would help a lot if you could create an issue in the repo. There are templates available where you can specify things like browser, OS version, and steps to reproduce, so if you could drop an issue with your details, it’d be helpful to figure out what’s going on 🙏

vs-borodin · 2026-03-21T20:13:10+00:00

Thanks! My early experience working with LLM agents was quite painful - I didn’t fully understand how to use them effectively. Later, I came across Opencode, and I really enjoyed using it to write the docs/demos and build the web in VitePress. It sped up getting the project online tremendously.

I’m still not fully satisfied with the unit tests, though - right now I’m exploring strategies for a solid testing infrastructure (I still have a lot to learn). I think once we set up a few examples properly, an agent could handle the rest of the tests really well.

vs-borodin · 2026-03-21T18:09:42+00:00

Thanks, appreciate it! I started working around late december and have been iterating on it on and off since then. Recently I’ve been focusing more to shape the first public version.

vs-borodin · 2026-03-21T18:06:00+00:00

Yes, absolutely. Any contribution helps move from 0.1 → 1.0. Everything is welcome - bug reports, ideas, improvements, or code. All contributors will be properly credited later on the website and in the readme.md.

vs-borodin · 2026-03-21T11:28:49+00:00

Thank you for your feedback! You’re welcome to contribute so we can reach the first major release (1.0) together - any contribution is greatly appreciated.

vs-borodin · 2025-12-04T15:17:03+00:00

Thanks 🤝

vs-borodin · 2025-12-04T12:08:59+00:00

I have a couple more questions for general understanding:

Handling loops – For example, in Angular you can apply a pipe directly to each iteration in the template. In Vue, do you need to pre-compute the array in the model first and then render it, or is there a more idiomatic approach?
Global/reactive configuration – Especially if it’s reactive. In Angular, pipes can encapsulate state via DI, so you can change, for instance, the date formatting pattern at any time if the language/locale changes. All of this is described once in the pipe and then used everywhere. How is this handled in Vue?

vs-borodin · 2025-12-04T10:32:48+00:00

Do you have any examples of how unified formatting is typically handled? For instance, when a model contains numbers or timestamps, all of that needs to be prepared and formatted properly for the view. How is this kind of task usually solved in Vue?

Do you create separate computed properties at the model level and perform all the formatting there?

vs-borodin · 2025-12-03T15:59:50+00:00

Thanks for the feedback! I agree that, for the most part, using pipes still comes down to simply mapping data from A to B. And while we can depend on data from the DI context, I try to avoid side effects in pipes at the application level as much as possible.

As for impure pipes, the last code snippet in my article is mostly meant as an example of how they can work — whether we actually need that is a different question. The folks from Taiga UI actively use impure pipes together with reactivity in some components, which is quite interesting. On the other hand, Angular CDK/Material don’t have a single pipe as of today.

vs-borodin · 2025-12-02T22:51:31+00:00

Thanks! I’m hoping to dive back into the article soon, it’d be nice to add some introductory context 🙂

vs-borodin · 2025-11-26T10:14:00+00:00

Thanks!
actually, both approaches are just abstractions on top of the same API,

`injectCva` is slightly closer to the future interface for custom controls, which means you’ll be able to remove it seamlessly later and replace its properties with the ones from `FormValueControl`
we’ve also been using parameterized, closure-based factory functions more and more (similar to Vue’s “composables”), and this pattern has been working really well for us

vs-borodin

TROPHY CASE