DEV Community: Daniela Bonvini

Codemotion Milan 2025

Daniela Bonvini — Wed, 22 Oct 2025 09:00:00 +0000

Highlights and reflections from Codemotion Milan 2025, covering key talks on testing strategies, modern CSS, Chrome DevTools, and AI prompt strategies.

Codemotion Milan 2025: Highlights and Reflections

Last week I had the chance to attend Codemotion Milan 2025, and honestly, it was a blast. Picture hundreds of developers, designers, and tech enthusiasts buzzing around packed rooms, debating over coffee, and getting genuinely excited about new ideas. It felt like the perfect mix of community, curiosity, and caffeine.

The schedule was stacked with everything from frontend magic to backend mysteries, and testing strategies to AI, DevOps, and software architecture. After two days of sessions, demos, and hallway chats, a few talks really stuck with me; for their substance, their delivery, and the sparks they set off in my brain.

Your Testing Strategy is Broken: Let’s Fix It! by Luise Freese

Luise Freese is an amazing speaker, funny but insightful (and it doesn't hurt that she likes pink and unicorns). I had the pleasure of seeing her speak last year, so I was really looking forward to her session this time around.
In this talk she took a refreshing look at what’s wrong with how we usually approach testing. Her point was simple but powerful: stop testing everything just for the sake of it. Aiming for 100% coverage sounds good on paper, but often just creates a mountain of useless unit tests that never actually catch the things that break in production.

Luise argued for a smarter, leaner approach — fewer tests, but better ones. Focus on how your system behaves under pressure, on integration points, on what your users will actually notice when things go wrong. As she put it, users don’t care how many tests you’ve written; they care that the software works.

It was one of those talks that make you rethink your day to day habits. I left the room thinking less about coverage reports and more about value.

Baseline Rhapsody: A Tale of Style & Motion by Emiliano Pisu

Emiliano Pisu’s talk was basically a love letter to modern CSS, and heaven knows if we need more CSS love in the developer community. He took us on a journey from the wild days of floats and tables to the sleek, expressive world of container queries, scroll-driven animations, and CSS custom properties. His main message: we’re living in a golden age of frontend styling, and we should start acting like it.

He introduced the new Baseline standard, a sort of “truth table” for web features that tells you what’s safe to use across browsers right now. No more endless guessing games or praying to the compatibility gods.

What I loved most was Emiliano’s mix of technical depth and creative energy. He made CSS feel exciting again, and honestly, I walked out wanting to rebuild half our design system just to play with the new toys.

ChromeDevTools: Are You Confident in Your Expertise? by Luca Del Puppo

This talk was like discovering hidden cheat codes in a game you’ve been playing for years. Luca Del Puppo took something every JavaScript dev uses daily, Chrome DevTools, and showed us just how much more it can do when you dig deep.

He demoed advanced debugging tricks, performance profiling, and how to uncover sneaky issues like layout thrashing and memory leaks. It wasn’t just a feature tour, it was a hands on masterclass in how to actually think with your tools.

What made it memorable was Luca’s energy and real-world examples. You could tell he’s spent countless hours battling tough bugs, and he made us feel like we could take on anything with DevTools as our sidekick. I walked away with a bunch of new debugging tricks and a renewed appreciation for a tool I thought I’d already mastered.

Prompt Strategies: Useful for AI (and Maybe for Everyday Life) by Francesco Sciuti

Right before my train home, I managed to squeeze in part of Francesco Sciuti’s workshop “Prompt Strategies: utile per l'AI e (forse) anche per l'uso quotidiano”, which roughly translates to “Prompt Strategies: useful for AI (and maybe also for everyday life).”

It was less of a formal talk and more of a round table conversation. Francesco walked us through how to write prompts that actually make AI behave, how to get the answers you want, in the format you need, without the weird hallucinations or vague replies we’ve all seen. He shared practical examples, frameworks for structuring prompts clearly, and even a few thoughts on Context Engineering. Basically, how to give an AI the right background to think straight.

Sadly, I had to leave halfway through to catch my train, but what I saw was genuinely enlightening. It wasn’t just about AI — it was about communication, precision, and how phrasing things clearly can make all the difference, whether you’re prompting a model or just talking to your team. Best new term of the year coined by Francesco: Vibe Prototyping, instead of the old Vibe Coding, which better represents how we can approach AI interactions in a more purposeful and cooperative way.

What Made These Talks Stand Out

Looking back, the sessions that I liked more had a few things in common. They were practical, grounded, and a little opinionated, the kind of talks that give you ideas to try the next morning, not just slides to bookmark and forget that are more like someone reading the documentation to you instead of explaining a new concept with their own voice and thoughts. They also had a strong personal touch — you could tell the speakers were passionate about their topics, and that enthusiasm was contagious.

Codemotion Milan 2025 nailed that vibe. It wasn’t about chasing buzzwords or hyping the latest framework. It was about building better software, with intention and creativity.

Overall, the event was a brilliant reminder that learning in tech doesn’t have to be dry or intimidating. It can be lively, surprising, and even a little fun. The mix of talks, workshops, and casual conversations made it clear that the heart of any tech community is curiosity, collaboration, and a willingness to experiment. And Codemotion Milan 2025 had all of that and even more.

The Lord Of The Stores: A Quest For Angular State Mastery

Daniela Bonvini — Thu, 04 Sep 2025 09:00:00 +0000

In the complex world of NgRx state management three powerful stores can guide us: Global Store, vast and unifying; Component Store, swift and precise; Signal Store, reactive and efficient. But wielding them unwisely leads to an unmanageable state. Join this journey through NgRx best practices, avoiding pitfalls, and mastering scalability. Will your app stand strong or fall into disorder? The fate of state management rests in your hands!

The framework has changed. I feel it in the code. I feel it in the builds. I smell it in the tech forums.

It began with the forging of the Great Stores. Three were given to Angular developers—structured, scalable, and reactive above all else.
The Global Store, vast and powerful. The Component Store, lightweight and precise. And the Signal Store, fresh and efficient.

For within these stores was bound the power to manage state, to bring order to applications. Each with its own strengths, each suited for different needs.
Because the world of state management is treacherous, and without guidance, chaos can still arise. For the time will soon come when NgRx will shape the fortunes of all devs.

Obligatory disclaimer: as you may have noticed after this slightly weird intro, in this article I will reference Lord Of The Rings lore, but if you’re not a fan of the movies or books don’t worry, of course it’s not needed to understand the explained concepts. (Although, I strongly suggest you to watch/read it, as it is an amazing saga).

An Unexpected Journey

The idea for this article came to me after I discussed with my team the option to start using a state management library for our application. At the time we used services that mimicked store slices and we wanted to switch them into full-fledged NgRx stores.

Until that moment I had only used the Global Store, heard of the Signal Store and didn’t even know the Component Store existed, until I read the NgRx official documentation (see, someone does RTFM sometimes).

As we didn’t have any specific requests on what to use, we were open to any one of them.

We took some time researching, and I found out that, as far as I know, there are no articles or videos directly comparing the differences between these stores, their use cases, and their pros and cons.

Fast forward a couple of months later and a lot of material revised, and here we are: I hope my findings will help someone in a similar position to mine figure out a little bit easier which store to choose for their own case.

The Global Store – Vilya, The Ring of Air

Let’s start with the Global Store, the most powerful option, associated with Vilya, the ring given to Elrond, symbolizing wisdom and governance.

Likewise, the Global Store manages large state in applications, providing structure and predictability. It is ideal for apps with complex state that multiple components must access and update.

However, this power comes with complexity: it requires a solid understanding of reducers, actions, effects, and RxJS, which adds to the learning curve. It demands boilerplate code and many interconnected parts, which can be overwhelming, especially for smaller apps or simpler state needs.

But this union of actions and effects is the Global Store’s strength, enabling features like time-travel debugging with native Redux DevTools integration. Developers can step backward and forward in the application’s state history, making changes easier to trace and debug.

Having matured over many years, the Global Store also offers an opinionated and structured way of managing state, helping teams organize logic across files and maintain consistency.

Global Store – Pros and Cons

Pros	Cons
Best for large-scale apps with complex state shared across multiple components	High complexity (reducers, actions, effects, selectors) + RxJS
Easier debugging using time-travel with Redux DevTools	Steep learning curve
Mature: opinionated and structured way of managing state	Lots of boilerplate code to interconnect everything
	Too much overhead for smaller applications

Example of use cases: large apps with complex, shared business logic (multi-step forms, shopping carts shared across multiple features) or global data like feature flags, notifications, or permissions.

Nenya – The Ring of Water, The Component Store

Then comes the Component Store, the underdog of the state management world, yet full of potential. I associate it with Nenya, Galadriel’s ring, symbolizing preservation and stability.

The Component Store works seamlessly with the Global Store without conflict, allowing effective state management with minimal changes to your codebase. You can see it like a service managing state with Subjects, but with added clarity and best practices.

It’s a lightweight solution ideal for managing local component or feature module state, promoting modularity and isolation. It supports multiple independent instances of the same component, maintaining clean separation of concerns.

Its API is simpler than that of the Global Store, as it doesn't require actions or reducers, making it easier to learn. However, it lacks developer tool support like time-travel debugging since it doesn't utilize trackable actions.

Trade-offs include scalability challenges: state, updaters, selectors, and effects typically reside in the same file, which can become difficult to manage as logic increases. Also, since state is tied to the component lifecycle, it is removed when the component is destroyed, making it inappropriate for persistent or shared state across components.

In summary, the Component Store offers store-like benefits without the Global Store's complexity.

Now, I must make a small confession: lately the NgRx team has put on the component store page a note saying that they consider the signal store the new default for local state management.

But, I nevertheless wanted to talk about component store as a lot of people may be stuck on older versions of Angular and may not be able to easily upgrade to signals and signal store usage.

As we can see from npm, still hundreds of thousands of people download Angular to versions less than 17 (signal store was released with NgRx version 17). But these same people may still be in need of a smaller store for their state management.

Component Store – Pros and Cons

Pros	Cons
Lightweight solution for local component state	Low scalability as everything is in the same file
Multiple independent instances of the same component allowing separation of concerns	No permanent state, as it is reset on component destruction
Simple syntax and state management (no actions or reducers)	No Redux DevTools time-travel debugging

Example of use cases: managing a form’s input values, validation, and submission state, or controlling the visibility and behavior of a modal within a component.

Narya – The Ring of Fire, The Signal Store

And lastly, the Signal Store, represented by Narya, Gandalf’s ring of courage and action.

It reflects the NgRx team’s bold shift toward simplicity and performance. Built on Angular signals, it provides reactive and efficient state management, removing unnecessary recalculations with a straightforward syntax that you can use right away.

In this store, state properties are signals, allowing components to access them directly without selectors or boilerplate code. Its lightweight design and optional RxJS support make it ideal for modern Angular apps that want to reduce complexity and bundle size.

However, it is still new, so official guidelines are limited. Features like selector composition, route guard integration, and DevTools support are still being developed. The Signal Store also forces you to use signals or convert Observables into signals. This makes it best suited for small to medium-scale features or isolated domains, while large-scale applications may still prefer the Global Store.

One downside is that the Signal Store does not support Redux DevTools yet. This means you lose features like time-travel debugging and state inspection.

There is an unofficial alternative, the Angular Architects NgRx Toolkit browser extension, which offers partial support but does not fully match the Redux DevTools experience.

Signal Store – Pros and Cons

Pros	Cons
State properties as signals (no selectors)	Still new, with limited official guidelines and documentation
Plug and play (simple syntax and small bundle size)	Advanced features are still evolving
Optional RxJS use	Obligatory use of signals
Good for reactive programming	Best suited for small to medium-scale apps; not yet ideal for large-scale or enterprise apps
Extreme composability (you choose which features to use)	No out-of-the-box Redux DevTools

Example of use cases: managing UI-related states like toggles, modals, filters, and tabs where reactive updates are needed but complexity is low.

Choosing the Right Ring and Power

We now have a better understanding of what each store can give us. But we still need to make a choice to understand which one is the right power for us.

Like the Elves wielding their rings wisely, developers must choose the right store for the right situation, as we know that the wrong power in the wrong hands can lead to disastrous consequences.

We must avoid at all costs the temptation of using too much or too little power just because we like one of the stores. Using a Global Store when local state would be better overcomplicates a simple problem. Conversely, sometimes a simple service+subjects/signals is all you need instead of any store at all.

The choice between NgRx stores depends primarily on your project's complexity, team size, and growth expectations. The Global Store excels at enterprise-level applications. The Signal Store offers a simpler alternative for smaller projects. The Component Store provides a balanced approach suitable for medium-sized applications or feature modules.

Consider starting with the simplest solution that meets your needs and scaling up as your application grows.

One Store to Bind All State

But what if you want more power, more control, and you cannot choose between the three rings? Well, you also have the choice to combine them to balance their respective flaws and strengths.

For example, you can use the Global Store for managing global state across the application, employ the Component Store for encapsulating state within specific features, and integrate the Signal Store where reactive and functional updates are most beneficial.

These stores were deliberately made to work well together. The complexity lies not in the implementation but in ensuring your team agrees on conventions and enforces them during reviews. Otherwise, wrongful mixes could lead to painful refactors.

Having said that, I made a little task management dashboard on Stackblitz,
to have a visual reference on how the code works.

This is just a simple app to show how you can intertwine all of the aforementioned stores. Of course using all three is a bit too much, especially for this kind of small project, but this is obviously just an example to show how they can easily work together if the need arises. Usually I would suggest using only two of them together: one for managing global properties and one for managing component properties.
This dashboard has:

A global quest assigner (managed by the Global Store)
A status card specifically for each member (managed by the Component Store)
A reactive search input (managed by the Signal Store)

The Fifth Age: The Age of NgRx State Management

With the information we acquired we now know that these three stores bring order to the Middle Earth of state management, but only if used wisely. No one store rules them all — each has its own purpose.

Additionally, we now know that you can combine what they can do, to be even more powerful. But it is up to you to avoid the temptation of abusing their power.

Now go into the world and use your power wisely, as the fate of Angular state management now rests in your hands.

Public speaking is like eating chillies

Daniela Bonvini — Mon, 01 Jul 2024 09:00:00 +0000

Introduction

This past year, after some soul searching and a lot of nudging from some of the people around me, I finally took the big step and started giving public talks at tech conferences. I started small, first at a local meetup group, then in front of my coworkers via video call, and finally in person in front of real people.

In my clearly clickbait title, I compared this experience to eating chili peppers, which is one of the things I both love and fear most when I accidentally drop way too many chili flakes into a dish I just cooked.
Why a culinary example? Well, for one thing, I like to cook, and for another, I'm Italian, so I guess it's written somewhere in our constitution that it's my civic duty to speak in food metaphors.

I think it's an apt comparison: that first moment when you take that first bite of food, knowing full well that you've put way too much seasoning on it, but you eat it anyway. And after the initial pain of too much spice, you realize that all in all, the dish now has more flavor and more oomph. But more than that, you're secretly proud of yourself for overcoming the fear of the initial discomfort.
Then there is the second time, when you do it again with another dish, where you have once again miscalculated the ingredients. Which is somehow made worse because you already know the initial pain, but at the same time you know the amazing amount of flavor and spiciness that would follow.

Well, this applies perfectly to public speaking, at least for me.

The first bite

At my first local meetup talk, I was so scared that I almost ran away, pretending to be sick. But then I persevered and delivered the talk I had prepared, and in the end I felt proud, both because it went well, but mostly because I did it by pushing through the fear of failure.
Then came another occasion of public speaking and, as in my culinary example from earlier, I was, if possible, even more frightened than before. But I persevered, and once again, overcoming the stage fright, came the satisfaction, both in myself and in what I had done.

I won't sugarcoat it, that initial "pain" never goes away. The majority of public speakers I have talked to say that they always get nervous, regardless of their years of experience. But they go through with it, knowing that the final morsel will be totally worth the initial suffering.

There must be a reason why it is a popular trope that in order to grow you have to get out of your comfort zone.

And believe me, I know it's easier said than done; I'm extremely socially awkward, to the point where I'm afraid to even make phone calls to people or places I don't know, but trying to get over that initial discomfort with public speaking has really helped me get a little more comfortable around new people. I'm still not a party animal, but I'm starting to understand that the more you project a feeling of being relaxed to the outside world, the more your mind is tricked into thinking you're really relaxed.

Lately I have been feeling a little bolder in my everyday life and people around me have been telling me that it shows that I feel more confident and that I am speaking a lot more without being prompted. Another speaker at a conference even said that I was an extrovert and seemed perfectly at ease on stage. Me. Can you believe that?
I spent most of my teenage years being told I needed to talk more, smile more, get out more, so it feels incredible to be told the opposite.

In addition to the increased self-esteem, being a speaker at these kinds of events is a great way to meet other incredibly talented people who you'll most likely see at other conferences later on, thus reducing the subsequent anxiety of not knowing anyone. It's also incredibly good for networking: I've had the opportunity to talk face-to-face with people I would never have had the chance to talk to otherwise, and to ask for advice on various topics, and I've always been treated with the utmost kindness.

The aftertaste

What saddens me is that I see the most fear of speaking at these conferences coming from junior developers, especially female ones. They are convinced that they are not good enough to be at these events because most of the speakers are already well-known or super skilled.

What they never think about is that precisely because they are a part of the tech world that is rarely represented at conferences, the reason to be that person is to become an inspiration to others in a similar position. So those other people can think, "hey, look at that, it's not impossible, I could do that too".

In my personal experience, I would never have started on this path if I hadn't been part of a company that encourages participation in these events, and if I hadn't had some friends and colleagues who have achieved great things just through sheer dedication, doing things that I didn't think were possible for "normal" people (aka not senior developers or not already famous). Or even just for having people with the confidence in me that I lacked at that moment, but needed to embark on this adventure.

I hope that these words will give some of you reading the same kind of support that I have received.
That if you are teetering on the edge of trying, but not finding the courage to send out a call for papers, that my words may inspire you to take the first step on the other side of public speaking.

Conclusion

With my silly cooking example, I want to send a message to all the people who are curious about public speaking but don't think they are extroverted enough, good enough, knowledgeable enough, whatever enough to deserve to do it, to at least try it once. And if after the initial discomfort you can feel the rewarding spiciness that comes afterward, then trust me, you are hooked for life.

And if not, that's okay too, at least you tried, and now you'll certainly have a better understanding of yourself, and you can still be proud that you at least tried, and peacefully know that it wasn't for you, without any regrets.

So go on, take that first spicy bite and get out of your comfort zone.

How (not) to contribute to open source

Daniela Bonvini — Thu, 25 Jan 2024 09:00:00 +0000

Introduction

The idea of contributing to open source projects is often presented as an easy task that anyone can do. However, in reality, it can be a very challenging journey. Despite hearing countless times that contributing to open source is simple, it wasn't until I tried it myself that I realized this was not the case. In this text, I will share my own experience with open source contribution to provide an honest and informative account of what it truly entails.

Act 1: The grand illusion

In the beginning, I started to ask my colleagues for tips on where to start, and they pretty unanimously said to search for issues with for beginners or help wanted tags, maybe in some of the projects I was already using at work. Well, I thought, that's easy. I got a short list of the libraries I was using and/or I was interested in and started digging into their GitHub repositories. I combed dozens of open issues, but either they had no good first issue tag, or the more accessible things got snatched lightning fast.

So I went back to those who had suggested this route and asked for advice again, and this time they told me that I probably couldn't look in the famous libraries, where the competition was too fierce; I had to find my hidden gem in smaller projects.

I restarted my search, feeling slightly disgruntled. While it's nice to offer help, it's even better if that help is given to a prestigious library that you can boast about to other developers. It's natural to want to showcase our accomplishments, especially to those who understand our work. My parents only see value in my ability to fix their phones, so let me have this one thing.

I then perused less-known libraries, confident that I would be lucky this time. But I wasn't.
All I could find were libraries with complicated tasks, even the ones marked for beginners, in which the tag was very much misplaced, as in you had to know the codebase exceptionally well to fix even the minor stuff.
So OF COURSE I rolled up my sleeves, drew upon my inner strength, and found the perfect fix, after which everybody hailed me as the best contributor in the world.

Yes, no, of course not, otherwise we wouldn't be here. I quit. Just like that.

Act 2: Reality check

Let's jump a few months ahead, and the OS itch returned to me. I have a friend who makes videos about OS. He was doing one on Hacktoberfest ¹, saying that there were no physical prizes to discourage issue-taking spammers this year. This was my long-awaited chance, I was certain!

So I went to the Hacktoberfest site and combed the starting section. There, I found a link to a site that collected issues suited for first-timers, grouped by project. If they were included in the most famous site for the most famous OS event of the year, they certainly must be what I was looking for, right?

At first, I tried filtering by language, trying JavaScript, and looking at some of the open issues. Even worse than with my previous attempt months before, I couldn't even find the issues this time: they were snatched so fast that the site wasn't always updated on time, so it listed things already being worked upon or even fixed and merged.
So I narrowed my search and went where only the bravest engineers dare to go: CSS fixes.
But even doing so, I was again faced with the problem of finding only not-really-for-beginners-beginners-tagged issues. So, once more, I gave up.

Third time's the charm, and now I was fixated on having to make at least one OS contribution, so after Hacktoberfest was over, I tried another of the many tips I had been given previously: fix the documentation and find typos or bugs even before an issue is opened.

This was pure coincidence; I was researching Angular's Signals, and I knew that the .mutate() function was taken out of the APIs. (For context, this was just a couple of days from the announcement).
I checked the documentation and, lo and behold, it was still there. I thought this was my chance for glory: a small, not-yet-mainstream documentation fix in a famous project. So I rushed over to the Angular GitHub, and I'm sure you've guessed it: It was already fixed and just waiting to be merged in. And it was snatched just before I checked, so double the annoyance.

Act 3: The Hidden Gem

That was the last straw; cumulatively, I had spent more time looking for something to do than actually doing it. But I really wanted to contribute!
So a few more months went by, until one day I met an Italian open source maintainer and long-time speaker, Giorgio Boa, who by the way was a guest on our podcast Continuous Delivery, and asked him for advice, saying that I wanted to be part of the OS world. He said he was working on a small library of Qwik components and could help me if I wanted. I gladly accepted, and we found an issue that seemed pretty straightforward.
A few days after our conversation, I followed the little README guide to install everything required, and...nothing worked. So, after a few bad words, a lot of doubt about my skills as an engineer, and self pep talks to overcome my shyness about asking for help, I contacted Giorgio again. Even with his help, at first we had some trouble figuring out what was going wrong, but in the end I finally had a working setup.

Eventually, I finally had time to start working on it. It seemed easy; Boa had already given me some tips on how to get started, so I got half the work done in a short time. But then the problems started. After going in circles for about a day, I finally gave in. I did the scariest thing of all: I once again asked for help, admitting that I had no idea what was going wrong. We tried to look at it together, but we couldn't find the problem right away. So I committed the part that I did that worked, and the next day Giorgio fixed the other half and merged my very first PR into the Qwik Storefront.

So, in the end, I finally got what I wanted: a published contribution in a good library, but I couldn't stop wondering if it was all worth it.
I was proud of it, of course, even though I needed some help. But I wanted more out of my work.
In the beginning I felt like a fraud for not contributing to OS, but in the end even contributing, or trying to contribute, made me feel like a fraud for not knowing enough and being more of a burden to a senior contributor than an additional help.

Looking back at it now, I think my biggest mistake was trying to do it for the hype, trying to conform to what everybody else around me said I should be doing and not because I really believed in what I was doing and why.
It doesn't really matter what anyone else says or does, because at the end of the day it's your time that's being spent solving these issues, and that time has to mean something to you if it's being taken away from other parts of your life.

I haven't resolved any other issues since then, and for now that's ok for me. I want to resolve an issue all by myself next time, but I want to be sure to do it for the right reasons this time, to avoid any unnecessary stress.
Knowing that this time, if I do go back and contribute, it won't be for the "glory" or the FOMO (Fear Of Missing Out), but for the kindness I've been shown, and which I hope to one day give back to a fellow developer in need.

Conclusion: The Truth Unveiled

So am I saying you shouldn't contribute to OS? Well, of course not. But I am stressing the importance of doing it because you really want to, or because you think the project you are working with will benefit from your contribution, not because everyone else is doing it and telling you how important it is, or because you really want a free T-shirt. As we've seen, helping in OS is not a walk in the park, so you must engage in it knowing what you're really getting into to avoid unnecessary frustration.

If you enter this world fully aware of what you're up against, you'll find it easier to accept the difficulties that come with trying to start contributing to open source. It will also give you the mental strength to accept failure when the problem you thought was beginner-friendly turns out to be much more treacherous than you thought.
What will be different is your reaction in front of this problem, as you will now know that there's no shame in not being able to close a beginner-tagged issue or even in asking somebody more skilled than you for help. Even though you'd have to ask two, three, or a hundred times. Just know that it is ok to fail and to need support and it doesn't make you any less of a developer.

Post Scriptum

This post offers my personal viewpoint on contributing to open source software, with the awareness that alternative methods of contribution, such as identifying and reporting bugs or translating documentation into other languages, exist but may be less widely known to those who are new to open source communities. Rather than purporting to present the definitive truth, the aim of this post is to provide a different angle on the difficulties that beginners may encounter when trying to make their mark in this world of contribution. The text conveys a thought-provoking perspective while upholding the utmost respect for individuals who consistently contribute to the open-source world.

EDIT: we also wrote a reply to this post that you can find here

Footnotes

Hacktoberfest is an annual worldwide event held during the month of October. The event encourages open source developers to contribute to repositories for the whole month.
Up until 2022, if 4 of your PRs got merged, you would receive a free t-shirt and sometimes other swag, which created utter chaos, with loads of fake or useless pull requests being spammed all over the GitHub universe. ↩

Angular Signals: what's all the fuss about?

Daniela Bonvini — Tue, 12 Sep 2023 09:33:29 +0000

Introduction

In the last couple of months the word signals has been said a lot in the Angular communities. Everybody already seems to either love them madly or reject them passionately.

But for those of us who are late to the hype train: what are they? And what can they do or not do?

Worry no more with FOMO as by the end of this article you will have a more comprehensive idea of where signals come from, how they work, and more importantly how they fit into the RxJS observables world.

Genesis

Let's start with the basics: why were they created? One may think that it was just a matter of "let's add a new feature to the framework", but it's not that simple. And it's not even a matter of copying what other frameworks are doing, as signals are not a new concept, they have been around for a while, and they are used in other libraries like Preact or frameworks like SolidJS. Indeed, SolidJS author himself says signals have been around "since the dawn of declarative JavaScript Frameworks".

This is not a case of "monkey see, monkey do", but rather a case of "let's see what we can do better".
The reasoning behind these changes can be well represented by this quote by the tech lead of the Angular team, Alex Rickabaugh:

The nature of web applications is always evolving, the performance requirements evolve, the web platform itself is evolving. So Angular needs to be stable, but not stagnant”. And so signals were born.

As a matter of fact, for the last decade, Angular's team listened to the users' most requested features to improve the developer experience. Amongst other things, some reoccurring requests concerned the necessity to simplify the usage of Angular, requiring less boilerplate code, augmented performances, more reactivity, and finer control over the components.

(Following this link you will find the PR that answered these requests, introducing signals for the first time.)

Change detection

To gain a better understanding of these requests, we must first digress a little bit, explaining a fundamental concept of Angular: change detection.

At the time of writing the framework uses a library called zone.js to control the various changes of state inside the application.

Zone.js tracks all the browser's events and every time it sees that something has changed, it starts a change detection cycle, in which it checks the components tree of the app to see if something has been modified, updating the views that need to be updated. On the one hand, this behavior is extremely useful because it automatically manages these checks, on the other hand, it underperforms because it constantly checks all of the components, sometimes even when there is no need to update anything.

An alternative strategy can be to use zone.js with OnPush in every component. This makes it so that the component that uses it is not checked during a change detection cycle unless explicitly marked with the markForCheck() function.

This behavior may seem similar to the one before, but the main difference is that markForCheck() doesn't automatically trigger the change detection for its component, but it just marks it to be checked on the next change detection cycle scheduled by zone.js .

The downside to this strategy is that it marks not just the component that raised the markForCheck() flag, but also its parent nodes. So we have fewer components checked than before, but there is still some, let's say over-checking spillage.

With signals, however, change detection is much more precise, indicating only the component, or components, that have undergone some changes.

But what is a signal?

A signal can be seen as a box around a value, and it can alert interested consumers when its value changes.

It can contain every kind of value, from primitive ones to more complex data structures. The value of a signal is always read using a getter function, which is what allows Angular to track when it has been used.

Side note: as a signal contains a value, it must always be initialized, or by default, it will be equal to undefined, which is not ideal.

A signal can be of one of two categories:

Writable, which contains a value that can be directly edited
Computed, in which the value is derived from other signals; in this case, we can't directly modify the computed value but this type has the added plus that it has a lazy approach. This means that its value will be re-evaluated not when the signals it checks are updated, but when a consumer tries to read the derived computed value, which makes it useful to do complex operations like array filtering.

Signals VS observables

By now, the more careful reader would probably start to think "By this explanation, signals seem to be a copy of RxJS observables, as they seem to do the same thing, so are we reinventing the wheel here ?".

To answer this question we need to open another small parenthesis before continuing, to get a clearer context for the ones among us who don't know what observables are.

What is an observable?

An observable is a collection of objects which can be observed in time, they are part of alibrary called RxJS which is often used in tandem with the Angular framework to manage asynchronous events. Unlike a normal array it does not keep memory of the elements, it just emits them.

To get a silly visual aid: we can imagine an observable as a fast food employee manning the drive-through window: it just knows that it has to deliver bags of objects to consumers as time passes, in an uninterrupted line of customers that go by during the day.

As much as they can work with synchronous data, observables shine in working with asynchronous events (clicking on keyboard keys, mouse clicks, HTTP calls responses) or notifications (a completed or failed process). But they are not perfect, as observables require a manual subscription, and of course a manual un-subscription. Moreover, the data is not readily available but has to be extracted from the emitted values stream first.
On the other hand, signals don't need a manual subscription, or more precisely, they have an implicit quasi-subscription automatically managed when a consumer starts listening to a signal's value.
In addition, a signal can be called and read directly, immediately obtaining the value it encapsulates.
These may seem like minor differences, but for simpler actions signals require much less code and, more importantly, less RxJS experience, which can be extremely powerful but also really difficult for new (and even not-so-new) devs.

Are we going to use only signals?

So, the one-million-dollar question is: are signals better than observables?
Well, it depends.

If you need to observe (no pun intended) values that change with time, without knowing when they do change, so asynchronously, you will be better off using observables. Instead, if time isn't something you need to keep in the equation, you will need only signals, which are simpler to use.
Realistically, in the future, we will most likely use signals for most use cases, and only in some particular circumstances we will need all the power of observables.

Having reflected upon these differences, you can see how titles that claim that the end of RxJS in favor of signals is imminent are just click-bait. It's just a matter of knowing when to use the right tool for the right job.
More so, the RxJS team, seeing the big picture, has already implemented two functions that allow the interoperability between signals and observables:
toObservable()and toSignal(), allowing the management of complex data flux or asynchronous data without having to give up the usage of signals.
I want to highlight this point, as I think it's one of the key concepts of Angular and its libraries: to always allow retro compatibility, letting new and old functionalities live side-by-side without the risk of breaking anything, which is not to be taken for granted. So let's keep feuds to important matters, like if you can add heavy cream to a carbonara sauce (pro tip: never).

Practical examples

Here are some practical examples before and after the usage of signals. They were made by Deborah Kurata, an amazing tech content creator. At this GitHub link you will find the GitHub repository in which you can find her complete project.
These examples are based upon a shopping app, in which we can add items to a cart, and then we can see the total price of the items in the cart. On the left we have the observables version, on the right the signals one. (Note: here I will call the signals version "after" and the observables one "before" for simplicity's sake. Also, the code is simplified for the sake of brevity, but the full code is available in the GitHub repo. Last but not least, instead of Observable observables, here are used Subject observables; an RxJS Subject is a special type of Observable that allows values to be multicasted to many Observers, so for simplicity's sake I will refer to them just as observables).

Let's start with something simple: the differences in the HTML and TS files of the cart-total component. The differences are not huge, but they are there. Especially in the HTML file, in the before version, we have to use the async pipe to subscribe to the observable, while in the after version we can just call the signal directly; this can make a difference in streamlining the code if we have to use other pipes, as in the case of | number.

cart-total.component.html before

<div
  class="card border-secondary"
  *ngIf="(cartItems$ | async)?.length; else noItems"
>
  <div class="card-header text-secondary fw-bold">
    <div class="row">
      <div class="col-md-12">Cart Total</div>
    </div>
  </div>

  <div class="card-body">
    <div class="row">
      <div class="col-md-4">Subtotal:</div>
      <div class="col-md-4" style="text-align:right">
        {{subTotal$ | async | number:'1.2-2'}}
      </div>
    </div>
    <div class="row">
      <div class="col-md-4">Delivery:</div>
      <div
        class="col-md-4"
        style="text-align:right"
        *ngIf="deliveryFee$ | async as deliveryFee"
      >
        {{deliveryFee | number:'1.2-2'}}
      </div>
      <div
        class="col-md-4"
        style="text-align:right;color:red"
        *ngIf="!(deliveryFee$ | async)"
      >
        Free
      </div>
    </div>

    <div class="row">
      <div class="col-md-4">Estimated Tax:</div>
      <div class="col-md-4" style="text-align:right">
        {{tax$ | async | number:'1.2-2'}}
      </div>
    </div>

    <div class="row">
      <div class="col-md-4"><b>Total:</b></div>
      <div class="col-md-4" style="text-align:right">
        <b>{{totalPrice$ | async | number:'1.2-2'}}</b>
      </div>
    </div>
  </div>
</div>

cart-total.component.html after

<div class="card border-secondary" *ngIf="cartItems().length; else noItems">
  <div class="card-header text-secondary fw-bold">
    <div class="row">
      <div class="col-md-12">Cart Total</div>
    </div>
  </div>

  <div class="card-body">
    <div class="row">
      <div class="col-md-4">Subtotal:</div>
      <div class="col-md-4" style="text-align:right">
        {{subTotal() | number:'1.2-2'}}
      </div>
    </div>
    <div class="row">
      <div class="col-md-4">Delivery:</div>
      <div class="col-md-4" style="text-align:right" *ngIf="deliveryFee()">
        {{deliveryFee() | number:'1.2-2'}}
      </div>
      <div
        class="col-md-4"
        style="text-align:right;color:red"
        *ngIf="!deliveryFee()"
      >
        Free
      </div>
    </div>

    <div class="row">
      <div class="col-md-4">Estimated Tax:</div>
      <div class="col-md-4" style="text-align:right">
        {{tax() | number:'1.2-2'}}
      </div>
    </div>

    <div class="row">
      <div class="col-md-4"><b>Total:</b></div>
      <div class="col-md-4" style="text-align:right">
        <b>{{totalPrice() | number:'1.2-2'}}</b>
      </div>
    </div>
  </div>
</div>

cart-total.component.ts before

export class CartTotalComponent {
  cartItems$ = this.cartService.cartItems$;

  subTotal$ = this.cartService.subTotal$;

  deliveryFee$ = this.cartService.deliveryFee$;

  tax$ = this.cartService.tax$;

  totalPrice$ = this.cartService.totalPrice$;

  constructor(private cartService: CartService) {}
}

cart-total.component.ts after

export class CartTotalComponent {
  cartService = inject(CartService);

  cartItems = this.cartService.cartItems;

  subTotal = this.cartService.subTotal;

  deliveryFee = this.cartService.deliveryFee;

  tax = this.cartService.tax;

  totalPrice = this.cartService.totalPrice;
}

The most important differences, however, are in the cart service. In the before version, we have to manually subscribe to the observable, and then manually un-subscribe from it, which is not ideal. Especially considering that we will have to do it for all of the observables we use. In the after version, we can just call the signal directly, and it will be automatically managed by Angular.
Another important difference is that in the before version we have to manually manage the initialization of the observables, while in the after version we can just initialize the signals with the value we want them to have.
Also, in the before version, if we need to derive a value from other values, we have to use RxJS functions concatenated by .pipe(), which can make the code difficult to read for someone who doesn't know this library very well, while in the after version we can just use the computed() signal type, resulting in a much easier to understand code. We can also see how in the before version we have to use the next() function to update the value of the observable, specifying an action, while in the after version we can just update the value of the signal directly. Lastly, in the after version we don't need the modifyCart() function, as we can just update the value of the signal directly in the function, making following the flow of data more fluid.

cart.service.ts before

export class CartService {
  // Add item action
  private itemSubject = new Subject<Action<CartItem>>();
  itemAction$ = this.itemSubject.asObservable();

  cartItems$ = this.itemAction$.pipe(
    scan(
      (items, itemAction) => this.modifyCart(items, itemAction),
      [] as CartItem[]
    ),
    shareReplay(1)
  );

  // Total up the extended price for each item
  subTotal$ = this.cartItems$.pipe(
    map((items) =>
      items.reduce(
        (a, b) => a + b.quantity * Number(b.vehicle.cost_in_credits),
        0
      )
    )
  );

  // Delivery is free if spending more than 100,000 credits
  deliveryFee$ = this.subTotal$.pipe(map((t) => (t < 100000 ? 999 : 0)));

  // Tax could be based on shipping address zip code
  tax$ = this.subTotal$.pipe(map((t) => Math.round(t * 10.75) / 100));

  // Total price
  totalPrice$ = combineLatest([
    this.subTotal$,
    this.deliveryFee$,
    this.tax$,
  ]).pipe(map(([st, d, t]) => st + d + t));

  // Add the vehicle to the cart as an Action<CartItem>
  addToCart(vehicle: Vehicle): void {
    this.itemSubject.next({
      item: { vehicle, quantity: 1 },
      action: "add",
    });
  }

  // Remove the item from the cart
  removeFromCart(cartItem: CartItem): void {
    this.itemSubject.next({
      item: { vehicle: cartItem.vehicle, quantity: 0 },
      action: "delete",
    });
  }

  updateInCart(cartItem: CartItem, quantity: number) {
    this.itemSubject.next({
      item: { vehicle: cartItem.vehicle, quantity },
      action: "update",
    });
  }

  // Return the updated array of cart items
  private modifyCart(
    items: CartItem[],
    operation: Action<CartItem>
  ): CartItem[] {
    if (operation.action === "add") {
      // Determine if the item is already in the cart
      const itemInCart = items.find(
        (item) => item.vehicle.name === operation.item.vehicle.name
      );
      if (itemInCart) {
        // If so, update the quantity
        itemInCart.quantity += 1;
        return items.map((item) =>
          item.vehicle.name === itemInCart.vehicle.name ? itemInCart : item
        );
      } else {
        return [...items, operation.item];
      }
    } else if (operation.action === "update") {
      return items.map((item) =>
        item.vehicle.name === operation.item.vehicle.name
          ? operation.item
          : item
      );
    } else if (operation.action === "delete") {
      return items.filter(
        (item) => item.vehicle.name !== operation.item.vehicle.name
      );
    }
    return [...items];
  }
}

cart.service.ts after

export class CartService {
  // Manage state with signals
  cartItems = signal<CartItem[]>([]);

  // Total up the extended price for each item
  subTotal = computed(() =>
    this.cartItems().reduce(
      (a, b) => a + b.quantity * Number(b.vehicle.cost_in_credits),
      0
    )
  );

  // Delivery is free if spending more than 100,000 credits
  deliveryFee = computed(() => (this.subTotal() < 100000 ? 999 : 0));

  // Tax could be based on shipping address zip code
  tax = computed(() => Math.round(this.subTotal() * 10.75) / 100);

  // Total price
  totalPrice = computed(
    () => this.subTotal() + this.deliveryFee() + this.tax()
  );

  // Add the vehicle to the cart
  // If the item is already in the cart, increase the quantity
  addToCart(vehicle: Vehicle): void {
    const index = this.cartItems().findIndex(
      (item) => item.vehicle.name === vehicle.name
    );
    if (index === -1) {
      // Not already in the cart, so add with default quantity of 1
      this.cartItems.mutate((items) => items.push({ vehicle, quantity: 1 }));
    } else {
      // Already in the cart, so increase the quantity by 1
      this.cartItems.mutate(
        (items) =>
          (items[index] = { vehicle, quantity: items[index].quantity + 1 })
      );
    }
  }

  // Remove the item from the cart
  removeFromCart(cartItem: CartItem): void {
    // Update the cart with a new array containing
    // all but the filtered out deleted item
    this.cartItems.update((items) =>
      items.filter((item) => item.vehicle.name !== cartItem.vehicle.name)
    );
  }

  updateInCart(cartItem: CartItem, quantity: number) {
    // Update the cart with a new array containing
    // the updated item and all other original items
    this.cartItems.update((items) =>
      items.map((item) =>
        item.vehicle.name === cartItem.vehicle.name
          ? { vehicle: cartItem.vehicle, quantity }
          : item
      )
    );
  }
}

Conclusion

Now that we can see the big picture we can reflect on the initial users' requests made to the Angular team and it will be clear that they have been heard and answered.

Thanks to signals we will have more simplicity in usage to track values for changes in the apps, especially for those who are beginning to work with the framework, greatly reducing boilerplate code.
They will give the apps more reactivity, giving a boost to performances more than even the zone.js + onPush strategy could, without losing any functionality. They will allow much finer control over single components and the value changes inside them, automatically managing the subscription/un-subscription part.

But, as we have seen, signals will not replace observables completely, they will instead co-exist with them in harmony.

Let's make ~~love~~ code, not war.