Senior Software Engineer. Conference speaker.

This is how I got into conference speaking as a software engineer, and how you can too.

How I became a conference speaker (and how you can too!)


Ever wondered how developers end up speaking at those big tech conferences? Well, I've got a story for you. I'm going to share how I started speaking at international conferences. And I'll throw in some tips so you can follow in my footsteps if you're interested!

## A bit about me

First, let me give you some quick background. I've been a professional web developer for about 7 years now, mostly focusing on JavaScript. I've worked with React a ton, both on the front-end and back-end. My career's been pretty varied:

1. Started at a marketing agency
2. Moved to a startup
3. Worked at a full-service agency
4. Now at a front-end and Node.js focused consultancy called FrontValue

So, how did I end up on stage talking to hundreds of developers? Let's dive in!

## Baby steps: Meetup talks

It all started when I was about to switch to my second job. There were these front-end meetups in Eindhoven, Netherlands, that I sometimes attended. One day, they were looking for speakers for short 10-minute "lightning talks." And I thought, "Why not give it a shot?"

My first talk was about the Svelte framework. They had just released version 3, and not many people knew about it yet. Here's a pro tip: if you're nervous about speaking in front of more experienced devs, pick a topic that's so new, nobody can one-up you! 😅

That first talk went pretty well, and it was actually pretty fun. But then... the pandemic hit.

## The conference speaking challenge

Fast forward a bit. The pandemic was winding down, and I started doing more meetup talks at my new job. Then, when I was interviewing for my current role at FrontValue (a front-end consultancy), something interesting happened.

I asked my now-employer, Martijn, "Is there anything I can do in the first year that would make you go 'Wow, hiring Eddy was such a great decision'?" His response? "You can speak at two conferences."

Challenge accepted! 💪

## Crafting my first conference talk

So, how did I go from agreeing to speak to actually getting on stage? Here's what I did:

1. **Come up with a talk idea**: I started by creating an outline for my first talk.
2. **Submit to conferences**: I looked for conferences with open "Call for Papers" (CFP) and submitted my idea.
3. **Get lucky**: I barely caught the talk submission deadline for Code Europe 2023 in Krakow and Warsaw... and I still got accepted!

Let me tell you, that first conference experience was amazing. Code Europe took great care of their speakers - booked flights, scheduled airport pickups, the works. It really eased my nerves about the whole thing.

![Eddy Vinck speaking at Code Europe 2023](images/blogs/how-i-became-a-conference-speaker/code-europe-2023.jpg)

Within a few months of starting my new job I had already achieved my goal of doing 2 conference talks. A great start! I ended up speaking at 4 conferences during my first year at FrontValue.

## Want to become a conference speaker? Here's how

Alright, so you're thinking, "This sounds cool, but how can I do it?" Don't worry, I've got you covered. Here are some practical tips:

1. **Start with an outline**: You don't need a full presentation to submit a talk. Just a solid outline is often enough.
2. **Think like an attendee**: Ask yourself, "If I were in the audience, what would I want to get out of this talk?" Use those answers to structure your outline.
3. **Submit to multiple conferences**: Many allow you to submit several ideas, which increases your chances of getting accepted.
4. **Don't stress about the slides (yet)**: Most conferences don't require you to have your slides ready when you submit. You'll have time to prepare if you're accepted.

### Creating a talk people want to watch

The first group of people you need to "sell" on your talk idea is the committee which chooses the talks that get accepted for the event. There are a few things you can do to make your talk stand out from other talks during the selection process.

As I mentioned before, the takeaways for the audience should be valuable and obvious. You need to think about the people selecting the talks from potentially hundreds of submissions, and you also have to consider the people attending the event.

Besides providing good takeaways, another thing I did in my talks is providing people with an [open source Astro template](https://www.eddyvinck.com/projects/astro-engineering-blog/) when I was giving my Astro talk. I showcased it in the talk with a live coding demo as well, which when performed correctly can really help drive home the point if you want to showcase how people can use a library or a framework. It's also great for visual learners in the audience.

You should consider the type of event you want to present at, and potentially adjust your talk to make it a better fit for the conference. Right now, I have two very different talks.

One of my talks is about Astro and is more about how and why you would use Astro. Another is about building SaaS (Software as a Service) applications outside of your job.

That last one is more like a case study, but I could adjust it to be more about how I'm using specific technologies for different conferences. I could make it more React.js heavy for a React.js conference, or maybe lean more into the AI side of things for conferences about Artificial Intelligence.

## The ups and downs of conference speaking

Since that first talk, I've spoken at about 7 international conferences in places like Poland, Berlin, Texas, Wisconsin, Estonia, and North Carolina. Pretty cool, right?

If you're doing this alongside your regular job (like me), it can get tiring. The constant travel, airport hassles, and hotel bookings can wear you down. That said, I still love the actual speaking part and meeting new people at these events. It's a lot of fun, and I'm going to keep doing it!

## Is conference speaking right for you?

If you're on the fence, my advice is simple: give it a try! You might discover that you absolutely love it. And who knows? If you really enjoy it, you could even look into jobs like Developer Relations or Developer Advocate roles where this is a big part of the job.

![Eddy Vinck speaking at Digit in Estonia, 2024](images/blogs/how-i-became-a-conference-speaker/digit-2024.png)

## Wrapping up

So there you have it - my journey from nervous meetup speaker to international conference presenter. It's been a wild ride, and I'm excited to see where it goes next. Maybe I'll even speak at a Dutch conference someday! 😄

Remember, everyone starts somewhere. If I can do it, so can you. So why not give it a shot? Who knows, I might see you on stage at the next big tech conference!


Angular 19 Developer Happiness

Developer happiness, aiming for the next level!

Developer happiness in <mark>Angular 19</mark>


## Developer happiness in Angular 19

Angular 19 has just been released and there are many nice features to explore. This time they spent again a lot of effort
improving developers experience and listening carefully to all the wishes coming from the community. 
Get ready for a deep-dive first in the Dev experience improvements. 

## Dev experience improvements

Let's start looking at which features actually help improve the developer experience in Angular 19.

### Standalone

Starting from Angular 19 all components are now by default standalone and you need to explicitly say `standalone: false` to make them part of a module.
When using the Angular CLI the `ng update` command will automatically add or remove the standalone flag based on the current status of the component.
If it's standalone already, remove the flag. If a module component, add the flag with the value false.

### Signals

Starting with looking at the current status of the signals API. We see that many APIs have been promoted to be 
stable, and some new kids on the block.

The following have reached the stable status:
- Input
- Model
- Output
- viewChild(ren)
- contentChild(ren)

### New & Experimental

With APIs reaching stable there is room for new APIs to take the stage, so let's take a look at the new kids.
 
#### LinkedSignal

You can use linkedSignal to create local state just like with Signal. The difference is that this state is linked to a 
computed expression which provides an initial value. You can write new values to linkedSignal just like a regular signal. 
But when the linked computed expression changes, the linkedSignal returns to that computed value. 
More info on linkedSignal at [angular.dev/guide/signals/linked-signal](https://angular.dev/guide/signals/linked-signal)

```ts
@Component({/* ... */})
export class ShippingMethodPicker {
  shippingOptions: Signal<ShippingMethod[]> = getShippingOptions();
  // Select the first shipping option by default.
  selectedOption = signal(this.shippingOptions()[0]);
  
  changeShipping(newOptionIndex: number) {
    this.selectedOption.set(this.shippingOptions()[newOptionIndex]);
  }
}
// Source Angular.dev
```

#### Resource API
The resource function lets you work with asynchronous values, such as data from your server as part of Angular's signal graph. 
When you create a resource you specify a computed expression that returns a request object. This expression produces a new value whenever its signal dependencies change. 
This request object then goes to the specified async loader function, which can use any data client or similar asynchronous API. 
Resources provide you both the result of the request and the resource status as signals, meaning they work seamlessly with the rest of Angular's reactivity system. 
More info on the resource API at [angular.dev/guide/signals/resource](https://angular.dev/guide/signals/resource)

```ts
import {resource, Signal} from '@angular/core';

const userId: Signal<string> = getUserId();
const userResource = resource({
  // Define a reactive request computation.
  // The request value recomputes whenever any read signals change.
  request: () => ({id: userId()}),
  // Define an async loader that retrieves data.
  // The resource calls this function every time the `request` value changes.
  loader: ({request}) => fetchUser(request),
});
// Created a computed based on the result of the resource's loader function.
const firstName = computed(() => userResource.value().firstName);

// Source angular.dev
```

#### Route-level render mode

With Angular 19, the option to decide how the server should handle the rendering of a route is shipped in developer preview. 
By default, Angular will server-side render all the parametrized routes in your app and prerender all routes without parameters.

When defining routes you can choose to use the `ServerRoute` interface provided by the framework and specify how routes should be rendered.

```ts
export const serverRoutes: ServerRoute[] = [
  { path: '/home', mode: RenderMode.Client },
  { path: '/login', mode: RenderMode.Server },
  { path: '/**', mode: RenderMode.Prerender },
];
```

For the above code we will specify how different routes should be rendered. The home path should be rendered only on the client side, 
whereas the login route should always be rendered on the server side. All other routes will be pre-rendered 
More info on route-level render mode at [angular.dev/guide/hybrid-rendering](https://angular.dev/guide/hybrid-rendering)

#### New automatic refactoring tools!

**The signal input migration**: converts inputs using the decorator API to the new signal-based inputs.

```shell
ng g @angular/core:signal-input-migration
```

**The signal queries migration**: swaps queries like viewChild and ContentChild with their signal-based equivalent.

```shell
ng g @angular/core:signal-queries-migration
```

**The output migration**: migrates components to the new function-based Output API.

```shell
ng g @angular/core:output-migration
```

To run them all at once there is this magic script but run with caution! If you have a big project, it might impact code
that you wouldn't expect, making it hard to debug and track the issues. When doing it one-by-one it's easier to track the changes and impact.

```shell
ng generate @angular/core:signals
```

All these features are adopted in the Angular Language Service. This lets you run refactoring actions on your code directly in your favorite IDE.


### Angular Material & CDK updates

In the newest release, the theming system is significantly simplified. Resulting in less code for creating 
custom themes and better to maintain code that’s easier to understand. What used to take hundreds of lines can 
now be accomplished with just one call to `mat.theme`. This new API uses a handful of application-wide CSS variables 
to control the styles of all the Angular Material components. It enables you to change styles at the application 
level by using `mat.theme` override mixin.

```scss
@use '@angular/material' as mat;

html {
  @include mat.theme((
    color: (
      primary: $fv-orange,
    ),
  ));
}
```

When you need even more fine-grained control, you have mixins available for all individual Angular Material components.

```scss
html {
  @include mat.card-overrides((
    elevated-container-color: red,
    elevated-container-shape: 32px,
    title-text-size: 2rem,
  ));
}
```

Maybe you want to create your own theme? A new theme color schematic is available which generates your own color palette.
Also new is this  beginner-friendly theming guide, providing a clear and easy path covering how to theme your 
applications. More info on More info on theming your apps at [material.angular.io](https://material.angular.io/guide/theming)

```shell
ng g @angular/material:color-theme
```

> One small side note: if you want to use all these awesome new features, you need to be on Angular 19 and using Material 3.

Finally, after ages there is this brand new time-picker component, ready to be used.

![Angular Material Time Picker](images/blogs/angular-19/angular-material-time-picker.png)

### Incremental Hydration (developer preview)

Let's start with a small look back on the previous releases before deep-diving into Incremental Hydration:

- **Angular v16 - full-application hydration**: This ensures your server-side-rendered HTML is reused when your application bootstraps on the client side loading all necessary JavaScript.
- **Angular v17 - deferrable view @defer blocks**: Angular native primitive for declaratively defer loading chunks of your application and therefore additional JavaScript making the initial bundle smaller 
- **Angular v18 - Event replay**: Event Replay ensures none of your user’s interactions are lost before the hydration phase finishes

#### Angular v19 - Incremental Hydration

Full application hydration requires your application to be hydrated all at once, which also means that the JavaScript that supports the HTML is also present. 
The Deferrable views reduce some of that JavaScript, but the trade-off is that the rendered placeholder block content is different from the eventual main content. 

#### So why incremental Hydration? 

To render the contents on the server instead of the placeholder would mean we still need to fetch all JavaScript needed to render 
the contents and that negates the entire purpose of defer blocks. Incremental Hydration beats this challenge by rendering the template 
on the server side to look how it should after the defer block is triggered. Then, on the client side, leave that content dehydrated, 
skipping the need to fetch the JavaScript.

#### How does it work?

Defer blocks have a set of triggers, which you’re already probably familiar with — `immediate, idle, timer, interaction, viewport and hover`. 
So in your template you can add `@defer` and add one of these triggers. This trigger specifies when the deferrable view dependencies are fetched. 
Once they’ve been fetched the placeholder content is replaced by the main content. Incremental Hydration builds on this functionality and adds a new set of triggers, 
`Hydrate Triggers`. These are exactly the same as the ones you’re already familiar with, except one new trigger: `never`.

```html
@defer (hydrate on viewport) {
  <large-cmp />
} @placeholder {
  <div>Large component placeholder</div>
}
```

This signals to the server that the main block should be rendered and not the placeholder, resulting in the server fetching the defer block dependencies. 
Specifically, do all of this on the server but not on the client. Angular will leave the block dehydrated until the hydrate trigger fires. 
So it’s loaded eagerly on the server, but it’s deferred on the client. That results in your client-side JavaScript bundle being 
much smaller and faster to bootstrap while also having no temporary placeholder block contents. Finally, when your content hydrates, 
there’s no layout shift or flickering that occurs, just like full-application hydration.

Knowing this, one question pops up: “*what happens if a user wants to interact with the content that’s dehydrated?*”.
Here Event Replay comes into play. Event Replay captures events and queues them up to be replayed later. 
This ensures that all interactions with the dehydrated content are captured, trigger hydration, get replayed when your 
content is ready and none of your user actions are left behind.

We already briefly touched the brand new `never` trigger, lets check this one out a bit more. There may be cases where 
you have content that doesn’t need to be hydrated, like static content from a blog. It ensures that the content inside 
that block never triggers hydration and, because of that, never needs to ship any JavaScript on the initial load. 
This gives you a new, great way to reduce the overhead of the static content in your apps. One small note: during a subsequent
client-side render, a `@defer` block with `hydrate never` would still fetch dependencies, as hydration only applies to 
initial load of server-side rendered content. To start using it, just add `withIncrementalHydration()` to your 
`provideClientHydration()` call and you're all set. More info on incremental hydration at [angular.dev/guide/incremental-hydration](https://angular.dev/guide/incremental-hydration)

### Final thoughts

I'm really looking forward playing around with all these new features and seeing how the automatic schemas will 
transform my app into a full standalone, signal based application in a breeze! Let's hope there will be more awesome new features that
land in the Angular ecosystem in the coming years! 


Accessibility Essentials

Let’s dive into why web accessibility matters with tips to ensure your site works for everyone.

Web Accessibility Essentials

Do you consider web accessibility when building your web and mobile applications? Most developers don't! In this post, we'll dive deeper into web accessibility, why it’s important, and who’s responsible for defining accessibility standards.  

By the end of this article, you’ll know the key principles of accessibility and how to apply them to every project.

### Why Care About Accessibility?

Web accessibility isn't just a tick on a compliance checklist—it's a core pillar of responsible, user-centered design. Here's why it should matter to you:

- **Global Requirement**: Digital accessibility is now required for many websites and apps **worldwide**. [In the Netherlands](https://wcag.nl/kennis/wet-en-regels/), this applies to all government bodies, including national, regional, and local authorities, as well as public institutions and certain partnerships—known collectively as "overheidsorganisaties" (government organizations).

- **Legal Risks**: Ignoring accessibility can cost a business a ton of money! For example, [Target](https://dralegal.org/case/national-federation-of-the-blind-nfb-et-al-v-target-corporation/) faced a **$6 million** lawsuit for not complying with accessibility guidelines. In Europe, fines under the [European Accessibility Act (EAA)](https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=5581&langId=en) can reach **€20,000–€50,000** per infringement, depending on the country and severity.

- **A Large, Overlooked Audience**: Over 1 billion people worldwide live with a disability, many of them with invisible conditions. If your site isn’t accessible, you’re making it harder for a huge group of people to use the web.

- **Inclusive Design Benefits Everyone**: Accessibility isn’t just about how things look—it’s about making sure everyone can use your site, no matter their abilities. Inclusive design helps people with things like dyslexia, epilepsy, color blindness, hearing loss, and more.

- **SEO Boost**: Accessibility practices—like alt text, semantic HTML, clear headings, audio/video transcripts, and keyboard-friendly design—not only support all users but also improve SEO, boosting search visibility and rankings.

### What Defines Accessibility? WCAG and Its Importance

The **Web Content Accessibility Guidelines (WCAG)**, published by the [World Wide Web Consortium (W3C)](https://www.w3.org/), are the global standard for web accessibility. They outline the rules to make websites easier to use for people with disabilities, including sensory, cognitive, and physical challenges.

WCAG is organized into three levels:

- **A** (Minimum): Basic rules that all websites should follow.
- **AA** (Mid-range): More common and balanced rules, often required by law.
- **AAA** (Highest): The best level of accessibility, but hard to do for every site.

**Versioning of WCAG**:
The guidelines have evolved over time, with the following major versions:

- **WCAG 1.0** (1999): The original version, mostly focused on HTML websites.
- **WCAG 2.0** (2008): A major update that applies to all kinds of web content and technologies.
- **WCAG 2.1** (2018): Expanded to better address mobile devices and the needs of people with cognitive or low vision impairments.
- **WCAG 2.2** (2023): The most recent version, which includes improvements for cognitive disabilities and navigation.

For example, in the Netherlands, the websites and apps mentioned above currently need to meet the WCAG 2.1 AA standard.

--

Since the guidelines are always evolving, it’s a good idea to check out the [WCAG guidelines](https://www.w3.org/TR/WCAG21/) yourself. 

The good thing is, they’re all built around four core principles, and once you get those down, you’ll be ahead of the game compared to most people!

### The 4 Core Accessibility Principles (POUR)

![Graphic explaining the POUR acronym](images/blogs/web-accessability/POUR-acronym.png)

WCAG organizes requirements into four principles: **Perceivable**, **Operable**, **Understandable**, and **Robust** (POUR). 

Below is a breakdown of these principles with code examples to illustrate best practices.

#### 1. **Perceivable: Ensure All Content is Usable by Everyone’s Senses**

**Provide Alt-Text**

Use descriptive alt text for all images, especially those conveying important information. Avoid generic labels like “image” or “photo”—alt text should describe the content or function, e.g., “Person in wheelchair using a computer.”

```html

<img src="chart.png" alt="image">


<img src="chart.png" alt="Line chart showing quarterly sales growth from 2019 to 2020">
```

**Responsive Design**

Don’t just design for one screen. Use responsive design techniques to ensure all visual elements adapt to various screen sizes, including zoom and screen readers.

**Color Contrast**

Use [high-contrast color schemes](https://venngage.com/tools/accessible-color-palette-generator), especially for text. Aim for a contrast ratio of at least 4.5:1 for body text to ensure readability, and avoid color-dependent instructions (e.g., “click the green button”).

**Transcripts and Captions**

Provide text alternatives for audio and video content. This benefits not only users with hearing impairments but also those in quiet (or loud) environments who may not be able to use audio.

**Developer Tip**: Use tools like the [**Color Contrast Analyzer**](https://www.tpgi.com/color-contrast-checker/) to test your design’s readability, especially for color-blind users.

#### 2. **Operable: All Features Must be Functional Across Devices and Methods**

**Keyboard Navigation**

Make sure your site works well with just the keyboard. Users should be able to navigate with **Tab** (forward) and **Shift + Tab** (backward), and activate elements with **Enter** or **Space**. 

Use `tabindex` to set a logical focus order, and always show visible focus indicators so users know what they’re on. All essential actions, like submitting forms and navigating, should be easy without a mouse.

```html

<a href="#content" tabindex="1">Skip to Content</a>
<button tabindex="2">Submit</button>
```

**Avoid Flashing Content** 

Any flashing or blinking content should not flash more than three times per second to avoid triggering seizures in users with epilepsy.

**Time-Sensitive Controls** 

If your website includes timed actions (like a countdown), provide users with options to extend or disable the timer.

**Clear Focus Indicators**

Ensure focus states are visible and distinguishable. This is crucial for users who navigate via keyboard.

```css
/* Visible focus indicator */
button:focus {
  outline: 2px solid #0055cc;
  outline-offset: 2px;
}
```

**Developer Tip**: Test your app’s keyboard operability by tabbing through each interactive element. Look for skipped or inaccessible sections.

#### 3. **Understandable: Make Content Clear and Predictable**

**Set Language Attributes**

Properly set the language attribute (`lang`) on your HTML elements. This helps screen readers determine pronunciation and interpretation.
```html
<html lang="en">
  
</html>
```

**Simplify Text**

Avoid jargon and complex sentences. Aim for an 8th-grade reading level to ensure clarity for a broad audience. If you must use specialized terms, define them in a tooltip or glossary.
```html

<p>The <abbr title="Application Programming Interface">API</abbr> is essential for connecting services.</p>
```

**Consistent Navigation**

Keep navigation consistent across all pages. Erratic changes can confuse users who rely on screen readers or keyboard navigation.

**Error Handling**

When form validation errors occur, ensure they are clearly described and labeled. Use ARIA attributes (e.g., `aria-describedby`) to announce errors to screen readers.

```html
<label for="email">Email:</label>
<input type="email" id="email" aria-describedby="error-email">
<span id="error-email" aria-live="assertive" style="color: red;">Please enter a valid email address.</span>
```

  `aria-live` tells assistive technologies that content in a specific area may change dynamically. The values of `aria-live` determine how and when these changes are read aloud to users by screen readers:

  - **`polite`**: Changes are read aloud after the user finishes their current task, so it doesn’t interrupt their experience.
  - **`assertive`**: Changes are read aloud immediately, interrupting the user’s current activity. This is useful for important updates like error messages.

#### 4. **Robust: Ensure Compatibility with Various Devices and Assistive Technologies**

**Semantic HTML**

Use HTML5 semantic elements (`header`, `<nav>`, `<article>`, `<footer>`) instead of relying solely on `<div>` and `<span>` elements. This ensures screen readers can interpret the content correctly.
   

```html

<nav>Navigation here</nav>
<main>Main content here</main>
<footer>Footer content here</footer>
```

**Use ARIA Where Necessary**

While ARIA attributes are powerful, they should be used sparingly and only when native HTML cannot achieve the same functionality. Overuse can actually confuse assistive technologies.

```html

<button aria-label="Close modal">X</button>
```

**Developer Tip**: Use the W3C’s [Markup Validation Service](https://validator.w3.org/) to ensure your HTML is valid.

### Testing Your Website for Accessibility Compliance

Automated testing tools are a great starting point, but manual checks are key to catching things automation might miss. Here's a combo approach:

- **Automated Tools**: Use tools like [Axe](https://www.deque.com/axe/devtools/linter/), [Lighthouse](https://developer.chrome.com/docs/lighthouse/accessibility/scoring), and [WAVE](https://chromewebstore.google.com/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh) to quickly identify accessibility issues.
- **Manual Testing**: Test with screen readers and try navigating just with your keyboard. Put yourself in the users' shoes and experience your app like they would. Here are some examples of screen readers that you could use for testing:
  - **Mac**: VoiceOver (built-in)
  - **Windows**: [NVDA](https://www.nvaccess.org/download/) (free) or [JAWS](https://www.freedomscientific.com/products/software/jaws/) (paid)
  - **Linux**: Orca (built-in for GNOME desktop)

### Our Approach to Accessibility

At FrontValue, we know how important accessibility is for our clients. With many of them needing to meet WCAG standards set by the Dutch government, we’ve built processes to keep projects compliant and inclusive from the start.

```json
{
  "files": [
    "*.html"
  ],
  "rules": {
    "@angular-eslint/template/prefer-control-flow": "error",
    "@angular-eslint/template/alt-text": "error",
    "@angular-eslint/template/elements-content": "error",
    "@angular-eslint/template/no-positive-tabindex": "error",
    "@angular-eslint/template/table-scope": "error",
    "@angular-eslint/template/valid-aria": "error",
    "@angular-eslint/template/click-events-have-key-events": "off",
    "@nx/workspace-gm-click-events-have-key-events": "error",
    "@angular-eslint/template/mouse-events-have-key-events": "error",
    "@angular-eslint/template/no-autofocus": "error",
    "@angular-eslint/template/no-distracting-elements": "error"
  }
}

// Credit to Nicky Haze for sharing his project configuration
```

A big part of that is setting up ESLint rules that help us catch accessibility issues early, so things like alt text, ARIA labels, and table scopes are all in place right in the code.

We’ve even written some custom ESLint rules ourselves to keep our apps extra accessible!

### Final Call to Action

Don't treat accessibility like it's something you can squeeze in at the last minute. Make it a priority, and you'll widen your audience, improve usability, and build a web that works for everyone. So, jump in and start testing accessibility in your next project—no room for excuses!

From Frontend to DevOps

Expanding Your skillset for the Modern Job Market

From Frontend to <mark>DevOps</mark>


When I first started in development, I jumped into back-end work because it was seen as offering better career opportunities. However, I soon transitioned to frontend development, as the magic of seeing my code come to life on the screen captivated me.

While I still very much enjoy front-end development, I've noticed the expectations for front-end engineers go beyond just mastering a framework. With that in mind, I decided to expand my skill set and explore a path toward becoming a DevOps engineer.

### Understanding DevOps

#### What is DevOps
DevOps is about bringing **development (Dev)** and **operations (Ops)** teams together to make building and delivering software faster, smoother, and more secure. Instead of developers writing code and handing it over to operations, DevOps encourages collaboration from start to finish, using automation to streamline everything from testing to deployment.

#### The Role of a DevOps Engineer

From a DevOps engineer’s perspective, it’s not just about writing code, it’s about building and managing the entire infrastructure behind it. You automate the setup, scaling, and maintenance of applications through tools like Infrastructure as Code (IaC), making cloud resources easier to manage and more consistent. With continuous integration and continuous delivery (CI/CD) pipelines, you automate the build, test, and deployment processes, ensuring fast and reliable releases without manual intervention.

As a DevOps engineer you’re building, deploying, and managing the full lifecycle of your applications. You’re in control of the infrastructure, the automation, and the pipelines that make your software scalable, reliable, and efficient.

#### Key Benefits of DevOps

* **Release faster**: Automated pipelines ensure your updates go live quickly, whether it’s code changes or infrastructure updates.
* **Improve quality**: With continuous integration and testing, you catch bugs early, ensuring smoother releases.
* **Scale easily**: Using IaC, you can deploy and scale applications across multiple environments without manual effort.
* **Collaborate better**: By breaking down barriers, developers, IT teams, and security can work together seamlessly, improving the overall process.

### Why DevOps is relevant for Frontend engineers

Understanding DevOps practices can elevate both your work and career as a frontend engineer. In a rapidly evolving tech landscape, where collaboration and efficiency are key, DevOps provides you with a unique edge. Here’s how diving into DevOps can transform your role and enhance your skill set:

* **Enhanced team contribution** \
  Developing DevOps skills makes you a more valuable asset to your team. By understanding the deployment process, you can streamline application releases, reducing errors and saving time and resources. This knowledge also allows you to troubleshoot issues more effectively, leading to quicker resolutions and a better experience for users.

* **Understanding Where Your Code Goes** \
  As a frontend engineer, it's essential to understand what happens to our code after deployment. Knowing whether an app is hosted on a traditional server, running in a serverless environment, or deployed in the cloud can influence design decisions. For instance, when considering cloud hosting, the focus often shifts to optimizing performance and scalability, ensuring the application can handle varying user traffic effectively. In a serverless architecture, it's important to think about how functions execute and interact with other services.

  This understanding allows developers to make informed choices that enhance efficiency and resilience, ultimately leading to a smoother user experience.

* **Better Collaboration with Other Specialists** \
  By understanding DevOps principles, you can work more smoothly with backend engineers, operations teams, and cloud specialists. This teamwork not only leads to more cohesive projects and a smoother workflow but also enhances your impact within the team. 

* **Ensuring Quality and Standards** \
  Being familiar with DevOps gives you insights into the infrastructure behind your code. This helps ensure that your applications not only function well but also meet essential performance and security standards. 

  For example, knowing how to implement automated testing and monitoring can help catch potential issues early, ensuring a smooth user experience. It's not just about writing code; it's about delivering quality products 

* **Boosting Your Employability** \
  In today’s competitive job market, having DevOps knowledge sets you apart. Employers value developers who can navigate both the coding and operational sides of software development. This expanded skill set not only makes you a more attractive candidate but also opens doors to new opportunities.

  *<span style="text-decoration:underline;">“According to the latest statistics the DevOps market is forecast to grow at a growth rate of 19.7% from an estimated $10.4 billion in 2023 to $25.5 billion in 2028.”</span>*

  Source: [https://www.marketsandmarkets.com/Market-Reports/devops-market-824.html](https://www.marketsandmarkets.com/Market-Reports/devops-market-824.html)

### **Courses & Certificates**

Whether you're aiming to transition into a DevOps role or simply enhance your understanding of DevOps as a frontend engineer, there are many learning options available. You can choose to explore cloud concepts or pursue certifications based on your goals. Here, I’ll share my personal learning path.

#### AWS 

I chose to focus on AWS and obtain certifications because it’s the oldest cloud provider out there and still is the current market leader, making it the most widely adopted platform in the industry. AWS offers clear certification paths that will help you transition into a DevOps role or help you gain a better understanding. While certifications alone may not guarantee a job, they provide a structured learning path and clear goals to work towards. Personally, I find value in earning certifications because they test your theoretical knowledge and give you a tangible achievement to showcase.
!["Certification path"](images/blogs/frontend-to-devops/certification-path.png)
*Photo: example certification path for a Cloud DevOps Engineer.
[Click here for all certification paths](https://d1.awsstatic.com/training-and-certification/docs/AWS_certification_paths.pdf)*

#### Certified Cloud Practitioner 

The AWS Certified Cloud Practitioner (CCP) certificate is the entry level certificate of AWS and mostly recommended if you are new to cloud concepts or AWS itself. It validates foundational cloud knowledge and helps as a base for the other certificates. 

Even though some people suggest skipping this certificate and jump straight into more specific certificates, I personally found that the CCP really helps you build a solid foundation on cloud concepts and all that AWS has to offer in terms of services. I am currently at the brink of taking my Developer certificate exam and I went through the entire course significantly faster because you already grasp a lot of the concepts. 

<div style="display: flex; align-items: center;">
  <img src="images/blogs/frontend-to-devops/ccp.png" alt="Certified Cloud Practitioner" style="width: 150px; margin-right: 20px;">
  <p>
    All in all it took me close to 2 months from having no prior cloud knowledge to obtaining the CCP certificate and passing the exam with ease. These are the resources I used to prepare myself:
  </p>
</div>

* **Course**  [Ultimate AWS Certified Cloud Practitioner CLF-C02](https://www.udemy.com/course/aws-certified-cloud-practitioner-new/?couponCode=ST22MT92324B) \
  With Udemy you can often buy courses on discount which can save you quite some money. Stephane does a great job explaining things in a clear manner and is one of the top AWS course sellers for a reason.

  What works great for me is to just go through the entire course, doing the test exams at the end of each section and note which sections I struggle to grasp. I quit taking notes during each lecture because I found it too time consuming. Instead, once I finish the course, I revisit the sections I found difficult and go through them once more and then retake the exam on that specific section. 

* **Practice Exams** [6 Practice Exams | AWS Certified Cloud Practitioner CLF-C02](https://www.udemy.com/course/practice-exams-aws-certified-cloud-practitioner/?couponCode=ST22MT92324B) \
  Once I finished the course and revisited certain sections I bought this set of practice exams. Take your time and read each question carefully as you can often cross out 1 or 2 wrong answers by just understanding the question properly. Once finishing an exam, you can view your score and all the questions explanations, this was particularly helpful.

* **Hands-on** [AWS Cloud Quest](https://aws.amazon.com/training/digital/aws-cloud-quest/) \
  So this one might have caused me to take even longer since it is great fun. Besides following along with the hands-on exercises in the course, one thing I found very valuable is Cloud Quest.

  Cloud Quest is a 3d game to help you build practical AWS Cloud skills and gain hands-on experience to accommodate any certificates. It even allows you to gain certain badges that you can showcase, demonstrating your knowledge.


### Final words

So whether you're looking to transition into a DevOps role or simply up your game as a frontend engineer, diving into cloud concepts can definitely give you an edge.

I hope you enjoyed this article and found it helpful in charting your own path. Whatever your goals may be, remember that expanding your skill set is not just about boosting your career, it’s about staying curious and having fun along the way.



Get ready to get the nitty gritty of our lovely framework

Angular 19 or 18++?


## Angular 19 or 18++?

Most of us are still having fun exploring the features we got with Angular 18, myself included, there is so much code I
want to refactor. As a start I want to ‘signalize’ my app from bottom to the top! And the future is coming faster and
faster! So today, get ready to get into the nitty gritty of our lovely framework, as we familiarise ourselves with
features that will soon become a part of our daily routine thanks to Angular 19.

### Standalone keyword

The ‘Standalone’ keyword will soon be forgotten, This is because from version 19 components are recognized as
standalone by default. Meaning, there is no need to explicitly state that you want a standalone component. Therefore if
we have a look at the following component:

```typescript
@Component({
  imports: [CommonModule],
  selector: 'app-alone-component',
  template: './alone-component.html',
})
export class AloneComponent {
}
```

It is recognized as standalone. Alternatively you can also still make it part of a module as before, simply by setting
the standalone flag to false. Like below

```typescript
@Component({
  standalone: false,
  selector: 'app-modular-component',
  template: './modular-component.html',
})
export class ModularComponent {
}
```

This one of course we have to declare as part of the module in order to access it.
For true believers there is strawberry on top of the cake - We can enforce the usage of only standalone components in
our app with the ‘strictStandalone’ compiler option. After all this will make it easier to use all the perks of
standalone components such as lazy loading and defer loading to name a few.

### More Signals

Signals ecosystem should be updated as well. We know signals have just become a stable feature, but true is that only
the beginning. Many crucial features are still in preview. With the expectation that much of it finally gets to our
table well cooked and ready for prod. Signal ‘inputs’ is something I have been using and enjoy it for its simple syntax.
Just to compare

```typescript
export class SomeComponent {
  @Input({ required: true }) boringName!: string;

  nickname = input.required<string>();
}
```

Nickname is a signal variable, to be precise its type is InputSignal<string>. Therefore, it brings to ‘input’ all the
perks of signals, such as memoization. Another benefit of the signal input feature is that no change of syntax is
required for the parent component. This means we could refactor components with input only, no need to touch the parent
which passes the property.

```html
<some-component
        [boringName]="person.fullName"
        [nickname]="person.superHero">
</some-component>
```

Signal queries would also improve our code life balance when it comes to the element references we use so often.
ViewChild/viewChildren and ContentChild/ContentChildren will also be ‘signalized’ soon

```typescript
export class SomeComponent {
  description = viewChild<ElementRef>('description');
  footer = contentChild(Footer);
  myBlocks = contentChildren<ElementRef>('block');
}
```

### RxJs Interop

Let's not forget that RxJs Interop is in preview in the current version. I think it is important to get something
finalised in the next major update. My hope is that at least ‘toSignal’ and ‘toObservable’ will get the final
improvement needed to solidify this feature . Since starting to use signals application wide we found ourselves in
components where we use observables and signals at the same time. Naturally this leads us to situations when we might
want to mix or combine values. For example, add value of signal to train of few observables. Function toObservable would
help us here, it is straightforward, no need to explain what it does. But I think it's important we understand that such
functions actually create an environment where we could add new features like signals gradually and locally, component
by component. We don’t need to refactor all components around new one full of signals. Backward compatibility.

### Effect function

The Effect function got a lot of buzz around it. Probably a bit too raw when we put our hands on it for the first time.
With Angular 19 there are a couple important changes coming our way as a result of evolution. Initially the effect
function does not allow set signal values and computed signal is the way to go in case one signal is dependent on the
value of another signal. But life is more ‘fun’ than we want it to be, and we discovered many developers want to set
signals in the effect function. This is now possible using the allowSignalWrites flag.

```typescript
export class TestComponent implements OnInit {
  nickname = signal('not a hero');
  fullName = signal('Max');

  constructor() {
    effect(() => {
      if (this.fullName() === 'Clark Kent') {
        this.nickname.set('Superman');
      }
    }, { allowSignalWrites: true });
  }

  ngOnInit() {
    setTimeout(() => {
      this.fullName.set('Clark Kent');
    }, 5000);
  }
}
```

But from now Angular will support signal values setting in effect function out of the box, no need to flag anymore. So
this option goes away:

```typescript
{
  allowSignalWrites: true
}
```

It opens doors for some less than ideal practices, but the framework team doesn't want to stay in the way of developers
in this case. Responsibility goes totally to the developer on this one and I believe most of us will do the right thing
like I do here

```typescript
export class TestComponent implements OnInit {
  fullName = signal('Max');
  nickname = computed(() => {
    return this.fullName() === 'Clark Kent' ? 'Superman' : 'not a hero';
  });

  ngOnInit() {
    setTimeout(() => {
      this.fullName.set('Clark Kent');
    }, 5000);
  }
}
```

In most cases, a computed signal will save the day! And if not, the Angular team promises to provide us with a proper
instrument to build our great applications, reliable, scalable and high performance. Looking forward to it!


Is Angular copying React?

The eternal debate: Angular vs. React. It's like pineapple on a pizza, a discussion that never ends.


The eternal debate: Angular vs. React. It's like pineapple on a pizza, a discussion that never ends. Angular and React are two heavyweights in the JavaScript world. Both are very popular and have evolved a lot over the years. Looking at Angular 18 and React 19 I often hear people asking: *"Is Angular starting to look like React?"*.

Well, spoiler alert: **no**.

![Squint](/images/blogs/is-angular-copying-react/squint.gif)
If you squint hard enough, Angular does feel less "old school" than before. But this doesn't mean they're trying to look like React. Let's break this apart and show their key differences.

## A brief overview of Angular and React
Before diving into comparing the two, let’s quickly recap on both Angular and React:
* **Angular**: Launched by Google in 2010 as AngularJS, Angular is a complete front-end framework for building dynamic web applications. In 2016, Google completely revamped AngularJS and released Angular 2, marking a significant shift toward typescript and modern web development.
* **React**: Released in 2013, React is a JavaScript library designed for building user interfaces. Unlike Angular, React focuses on just the view layer of an application, leaving the developer to choose additional tools for routing, state management, and so on.

## The Fundamentals: Angular vs. React
### Architecture
Angular is a **complete framework**. It gives you (nearly) everything: routing, HTTP client, forms, services, dependency injection (DI), and even more, all included into the core framework. You don't need to go hunting for third-party libraries to get started.

React, on the other hand, is "just" a **library**. It's all about the components. Want routing? Go grab react-router. Need state management? Here comes redux. React's philosophy is to stay lean and let the ecosystem fill the gaps.

**TL;DR**: Angular is a framework, React is a library. Angular is like building with pre-made blueprints. React is like constructing something from scratch. And that’s a huge difference.

### Templating: Angular Templates vs. JSX
Angular uses a **HTML-first syntax**, where the templates are traditional HTML combined with Angular's **control flow syntax**. Angular's HTML syntax focuses on separating template (HTML) from logic (TypeScript).

#### Example of an Angular component and template
```typescript
// my-component.component.ts
import { Component } from '@angular/core';

@Component({
    selector: 'app-my-component',
    templateUrl: './my-component.component.html'
})
export class MyComponent {
    showTitle = true;
    username = 'Nicky Haze';
}
```

```html
// my-component.component.html
@if (showTitle) {
<h1>Welcome, {{ username }}!</h1>
}
```

React goes for a more integrated approach with **JSX (JavaScript XML)**, which can seem a bit unconventional at first. JSX lets you write HTML-like code directly inside your JavaScript. Instead of separating logic and templates into different files or blocks, **JSX merges those two**. While it looks similar to HTML, it's fundamentally JavaScript underneath the hood. The end result is a tightly coupled combination of both rendering and logic within the same code block.

#### Example of React JSX
```jsx
import React from 'react';

const showTitle = true;
const username = 'Nicky Haze';

const MyComponent = () => {
    return (
        <>
            {showTitle && <h1>Welcome, {username}!</h1>}
        </>
    );
};
export default MyComponent;
```

### Data binding: Two-Way vs. One-Way
Angular and React are different when looking at their data binding mechanisms.

Angular makes it possible to use both **one-way** and **two-way data binding**, with two-way data binding especially in form templates. This allows changes in the model or user interface to automatically update each other. The two-way binding syntax, `[()]`, combines property binding `[]` and event binding `()`. It's informally called "banana-in-a-box".

React uses **one-way data binding**. Props go down, actions come up. It's strict, predictable and easy to debug.

**Example**:

#### Example of Angular's one-way and two-way data binding
```html
// two-way data binding
<input [(ngModel)]="name">

// one-way data binding
<input [value]="name" (change)="setName($event)">
```

#### Example of React's one-way data binding
```jsx
<input value={name} onChange={(e) => setName(e.target.value)} />
```

### Rendering: Virtual DOM vs. Real DOM Manipulation
React uses virtual DOM. This means it calculates what needs to change in the UI before touching the actual DOM. It's efficient and fast, but you end up with a "React reality" that's abstracted from the real DOM.

Angular interacts directly with the real DOM. This approach can be less efficient compared to React's virtual DOM, but then uses a more accurate representation of the application's state. To prevent performance issues Angular came up with various optimization techniques, such as **change detection strategies** and lazy loading.

### Let's talk about Signals… Wait, this looks like React, right?
Signals is Angular's new way to handle asynchronous data and their change detection. This feature was first introduced in Angular 16 as a developer preview, and its final version was released in Angular 17.

#### Example of Angular Signals
```typescript
// counter.component.ts
import { Component, signal } from '@angular/core';

@Component({
    selector: 'app-counter',
    templateUrl: './counter.component.html'
})
export class CounterComponent {
    count = signal(0);

    increment() {
        this.count.set(this.count() + 1);
    }

    decrement() {
        this.count.set(this.count() - 1);
    }
}
```
```html
// counter.component.html
<div>
    <p>The count is: {{ count }}</p>
    <button (click)="increment()">+</button>
    <button (click)="decrement()">-</button>
</div>
```

One of the most groundbreaking features in React is **hooks**, introduced in React 16.8. React uses hooks as a way to manage local state and side effects in functional components. It's all about functions and closures (classic React).

#### Example of React hooks
```jsx
import { useState } from "react";

const Counter = (props) => {
    const [count, setCount] = useState(0);

    function increment() {
        setCount(count + 1);
    }

    function decrement() {
        setCount((prevCount) => prevCount - 1);
    }

    return (
        <div>
            <p>The count is: {count}</p>
            <button onClick={increment}>+</button>
            <button onClick={decrement}>-</button>
        </div>
    );
};

export default CounterComponent;
```

Signals might seem quite similar to React's hooks (especially useState and useEffect). Signals allow Angular components to react to data changes, kind of like what React components do with state. But here's the thing: **it's not the same!**

* Angular Signals enable **automatic reactivity and targeted updates**, simplifying state management with minimal re-renders.
* React Hooks are **component-based** and are tied to the component lifecycle. They offer flexibility, but need careful optimization to prevent unnecessary re-renders.


### Dependency Injection: One of Angular's biggest strengths
Let's face it: Angular's **dependency injection** is one of its biggest strengths. In Angular, services can be injected everywhere, from components to modules, with clear lifecycle management.

React does not come with a built-in dependency injection system. Instead, developers often use patterns like Context API, hooks, or other external libraries.


## Conclusion: Angular is Angular, React is React
Let's put this debate to rest. Angular 18 and React 19 may look similar at a glance if you've only checked the docs or a Medium article, but under the hood, they are fundamentally different.

* Angular is a complete framework. It's built for larger-scale applications that thrive on structure, services, and comprehensive tooling.
* React is a flexible, component-driven library that excels at being lightweight and adaptable, leaving you to select and piece together the additional tools you need.

Can you love both? Absolutely! I do. But Angular will never be React, and React will never be Angular, and that's perfectly fine. Because why would you want two identical tools in your toolbox? Keep Angular for when you need to build something from scratch with an integrated solution and keep React for when you want to build something quick and modular.

_In the end, saying Angular is copying React is like saying that Dutch football club Feyenoord is copying football club Ajax because they both have a huge amount of fans and both wear red and white outfits._
![Ajax Feyenoord](/images/blogs/is-angular-copying-react/ajax-feyenoord.png)

So let's not say Angular is starting to look like React, because that's just **nonsense**.


Getter to computed signal

The secrets of Angular, new computed signals versus old getters

Old getters to new computed signals


## Old getters to new computed signals

I distinctly remember when I met my first getter in an Angular application. At that time it looked to me like pure
magic.
Functions return the result of some calculations whenever changes are applied to values - magic right? It could be based
on input changes or by the act of assigning a new value to a variable, either way, the getter is triggered,
recalculation happens and the returned value of the getter is as good as new. Happiness levels of us developers are at
an all-time high at this moment, it seems to be all we want, automatic recalculations.

I was happy for a while... until the moment when I was not. One nice day I got knocked with the reality check of how
getters work under the hood.

!["Why do getters get triggered"](images/blogs/getter-to-computed-signal/getters-why.webp)

### Getters how?

Getters trigger recalculations not based on specific variable changes,
but on many other changes happening around in the digital world of your application.
Because of this, you will see that most of the time getters are called because of unrelated changes. It could be
triggered by scrolling, for example. I have a real world application example of a simple 300 lines component where one
getter is triggered around 260 times when the component is visible on the page. This is something that really could
negatively impact the performance of your application. Of course it also depends on the complexity of the specific
component and the page where it is used. I was no longer happy with the getter solution, so I asked myself if I was able
to do anything to improve this.

### Change detection strategies 

Some people recommend using `onPush` change detection, but this defeats the purpose since now we need to handle change in
the component manually. And we want the exact opposite, automatic value updates. 
In case you are okay with this, `onPush` still does not change the fact that getters could be triggered by an unrelated change, when manually marking our
component for check.

### Computed signals

This is where I looked into computed signals, we know that computed signals are called specifically based on a change of
a signal that it depends on. So maybe, it is our saviour.

Let's check a simple example:

```typescript
export class AngularGetterComponent {
  // Getter data
  dataSet1: number[] = [1];
  dataSet2: number[] = [2];

  get accDataByGetter(): number[] {
    console.log('getter');
    return [...this.dataSet1, ...this.dataSet2];
  }

  updatePropDataSet(num: number) {
    this.dataSet2.push(num + 1);
  }

  // Signal data
  dataSet3 = signal<number[]>([3]);
  dataSet4 = signal<number[]>([4]);

  accDataBySignal = computed<number[]>(() => {
    console.log('signal');
    return [...this.dataSet3(), ...this.dataSet4()];
  });


  updateSignalDataSet(num: number) {
    this.dataSet4.update((prev) => [...prev, num]);
  }
}
```

It is very basic, just one component which logs every time when we trigger the getter or computed signal, and both
values are displayed in html.

```html

<section>
    <span>Getter list:</span>
    @for(getItem of accDataByGetter; track $index) {
        <button type="button"
                (click)="updatePropDataSet(getItem)">
            {{ getItem }}
        </button>
    }
</section>
<section>
    <span>Computed list:</span>
    @for(sigItem of accDataBySignal(); track $index) {
        <button type="button"
                (click)="updateSignalDataSet(sigItem)">
            {{ sigItem }}
        </button>
    }
</section>
```
> Live example can be found here: [Getter - signal example](https://stackblitz.com/edit/stackblitz-starters-ssrptu?file=src%2Fgetter-to-signal.ts)

First thing we could notice in the console is that during initiation of the component the getter is called a couple of times whereas the
computed signal does only trigger once.

When we update a signal, which is tracked by `computed`, we see that the computed signal does trigger once,
but our unrelated getter is triggered again a few times. We don’t want the getter to do anything when we change the signal.

When trying to update values of data properties used for getters, we see that the getter is called many times again.
But most importantly, the computed signal in this case does nothing! The computed signal eliminates unnecessary
calculations, finally everything goes the way it should, magic.

### Conclusion
Even if there is an earthquake happening, the computed signal does not care about it, it sits and waits until its buddy
signal changes. I’d recommend we check our components for usage of getter/setter to be sure it does not do extra
unexpected work. It's a real major advantage of signals we could already have today, so don’t wait!



TypeScript 5.5 feature overview

A look at some of the new exciting features in TypeScript 5.5

TypeScript 5.5 Release - For The Community!


## TypeScript 5.5 Release: For The Community!

The much anticipated TypeScript 5.5 release is upon us! Despite it being a minor version update, this is one of the largest Typescript releases we’ve had in a while. There is quite an extensive list of changes (link to official docs below) In this blog we'll be highlighting a few exiting features.

## What's New in TypeScript 5.5

TypeScript 5.5 introduces several exciting features and improvements:

* **Inferred Type Predicates**
* **Control Flow Narrowing for Constant Indexed Accesses**
* **The JSDoc @import Tag**
* **Regular Expression Syntax Checking**
* **Support for New ECMAScript Set Methods**

### **Inferred Type Predicates**

Previous versions of Typescript's control flow analysis worked quite well, however, often enough you’d get errors if your type was deeply nested, not due to your code incorrect but rather a limitation of the control flow analysis. What do I mean by this? Let’s throw some football in the mix to clear things up:

```typescript
// not every country will have a star footballer to play
function getStarPlayers(countries: string[]) {
  // players: (Player | undefined)[]
  const players = countries
    .map(country => starPlayers.get(country))
    .filter(player => player !== undefined);

  for (const player of players) {
    player.play(); // This will now work! Whereas prior to Typescript 5.5 we would get a `possibly undefined` error despite us filtering out undefined just 2 lines above 
  }
}
```
Typescript infers a type predicate for the filter function, this results in `Array.prototype.filter` being aware of the nested type thus being more precise and not throwing an unexpected type error.

### **Type Import in JSDoc**

#### What is JSDoc?
JSDoc is the standardized way of documenting your code within JavaScript (JS). Typescript (TS) then extends JSDoc helping developers benefit from the type system for both TS and JS files.
#### What does this mean?
With latest release, you can now import types from other files or modules directly within JSDoc comments. This feature would be especially useful for JavaScript projects using TypeScript for type checking. It also enables reusability of type definitions. While this is currently possible it was quite cumbersome. It has been simplified in TypeScript 5.5 and now supports a new `@import` comment tag that has the same syntax as ECMAScript imports.


```typescript
// before Typescript 5.5 
/**
 * @param {import("./some-module").SomeType} myValue
 */
function doSomething(myValue) {
}

// Typescript 5.5 >
/** @import { SomeType } from "some-module" */
/**
 * @param {SomeType} myValue
 */
function doSomething(myValue) {
}
```

### **Support for New ECMAScript Set Methods**

TypeScript 5.5 adds support for new `Set` methods proposed for JavaScript, including union, intersection, and symmetric difference.
New Set Methods

The new ECMAScript `Set` methods are:
* union
* intersection
* difference
* symmetricDifference


```typescript

const setA = new Set([1, 2, 3]);
const setB = new Set([3, 4, 5]);

// new set methods
const union = new Set([...setA, ...setB]); // {1, 2, 3, 4, 5} - joins
const intersection = new Set([...setA].filter(x => setB.has(x))); // {3}
const symmetricDifference = new Set([...setA, ...setB].filter(x => !setA.has(x) || !setB.has(x))); // {1, 2, 4, 5}
```
The change is beneficial in-terms of aligning TS with the new JS features to ensure continued compatibility. And of course, We also have the benefit of not needing to rewrite commonly used set methods :)


### **Regular Expression Syntax Checking**

You don't really need it until you NEED it. TypeScript 5.5 will compile regular expressions, catching syntax errors earlier on in development as well as ensuring that the regex is compatibility with the target ECMAScript version.
#### Why do we need it?
Having the ability to validate regex during compile time will save devs plenty of time debugging. Despite there being other tools out there that can validate our regular expressions, the built-in validation now means we are no longer dependent on those tools.

```typescript
// Validates regex as well as compatibility based on ECMAScript target version
const regex = /(?<=\d{4})-(?=\d{4})/; 

// TypeScript error: Unterminated character class in regular expression
const anotherInvalidRegex = /[a-zA-Z0-9+/;
```

## Migrating to TypeScript 5.5 - should you? 👀

Yes, yes, yes! As mentioned, this is one of the bigger Typescript releases we've had. The new features further align JavaScript and Typescript as well as truly making the developer experience much smoother.

#### A couple of things to consider when migrating:
1. [ ] Changes to Type Inference and Control Flow Analysis
  * TypeScript 5.5 introduces more precise type inference and control flow analysis. This is largely dependent on how you've coded but its is a consideration to make
3. [ ] Stricter rules surrounding Type-Only Imports/Exports
4. [ ] Use Migration Tools like `ts-migrate` can help automate some of the more straightforward changes required.

TypeScript 5.5 is a significant step forward, offering powerful new features and improvements. Whether you're a seasoned TypeScript user or just getting started, this release has something for everyone. Upgrade today and take advantage of all that TypeScript 5.5 has to offer.

## Additional Resources

- [Official TypeScript 5.5 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html)
- [Infer type predicates from function bodies using control flow analysis - PR](https://github.com/microsoft/TypeScript/pull/57465)
- [Inferring a type predicate](https://effectivetypescript.com/2024/04/16/inferring-a-type-predicate/)



Zoning in Angular 18

The new reactivity system for at least the next 10 years of Angular.

A New Way of Zoning <mark>Angular 18</mark>


Last week (May, 22nd) the Angular team released Angular 18. 
The most important change is the stabilizing new reactivity system for at least the next 10 years of Angular.

So lets take a step back and look at the previous year of releases:

#### Angular 16 - May 3, 2023
- 3 new reactive primitives, they will be the heart of the new reactivity model
   - Signal → Writable signals provide an API for updating their values directly
   - Computed → Computed signal are read-only signals that derive their value from other signals
   - Effect → An effect is an operation that runs whenever one or more signal values change

#### Angular 17 - November 8, 2023
- Signal and Computed became stable APIs

#### Angular 18 - May 22, 2024
- Hybrid change detection (turned on by default for new v18 apps)
- Experimental API to fully disable zonejs, powered by the reactive APIs! 
  - note: not all APIs work (yet) with this e.g. forms
- SSR dev tool hydration
- Angular Material 3 
  - Components support hydration
  - Theming API
- SSR Event Replay → Events will be captured and replayed at the right time once the app is hydrated → Powered by JsAction
- Typescript 5.4 support

As you can see the Angular team has put great effort into making the new zoneless APIs more stable and future ready.
So how does Angular knows when to run the next digest cycle? The funny thing is that's when you communicate state changes to Angular. 
For example by setting a signal that’s used in a template. The framework will schedule change detection automatically, without the need of zonejs.

I hear you think but what about major existing applications that consist of thousands of components that are not yet using signals, right? 
For these applications the goal of the Angular team was to make it possible to run zoneless as well without needing to migrate everything to signals. 
And of course, don't forget the rich ecosystem of existing Angular libraries that need to be zoneless-compatible without having to make major changes as well.

Well they made it via the hybrid change detection that will stitch zonejs and zoneless seamlessly together!

Lets deep dive a little bit into the new signal based APIs

### Signal input API:

The new way to pass data to child components is via the input API. It's signal based and whenever the input value changes, it will run change detection if needed.
You can also make an input required, which means that the input value must be set before the component is created.

```typescript
import { Component, input } from '@angular/core';

@Component({
  selector: 'fv-app',
  template: `
    <h1>Hello, {{ name() }}</h1>
    <h2>The current registered users are: {{ totalUsers() }}</h2>
  `,
})
export class TimelineGroupComponent {
  name = input<string>();
  totalUsers = input.required<number>(0);
}
```

### Model input API

The model input API is the new way of two-way binding in Angular. 
It will not only update the inner state of the component it will also notify the parent if it's listening for updates.

```html
<fv-custom-checkbox 
        [(checked)]="isChecked" 
        (checkedChanged)="runSomeUpdate($event)">
</fv-custom-checkbox>
```
```typescript
import { Component, model } from '@angular/core';

@Component({
  selector: 'fv-custom-checkbox',
  template: `
    <div class="fv-custom-checkbox">
      <input
        type="checkbox"
        id="custom-checkbox"
        (click)="toggle()"
        [value]="checked()"
      />
      <label for="custom-checkbox">Checkbox with model!</label>
    </div>
  `,
})
export class CustomCheckboxComponent {
  protected checked = model(false);

  toggle() {
    this.checked.set(!this.checked());
  }
}
```

### Signal query API

A new way to type-safe interact in a reactive way with content children and view children in templates. This new approach exposes query results as signals, which mean that query results can be composed with other signals using computed or effect and drive change detection. This new signal based query system offers other benefits, like more predictable timing, simpler API, improved type safety, more accurate type inference, and lazier updates.

```typescript
import { Component, effect, viewChildren } from '@angular/core';

@Component({
  selector: 'fv-app',
  template: `
    @for (todo of todos; track todo.id) {
      <todo [item]="todo" />
    }
  `,
})
export class App {
  children = viewChildren(Todo);

  constructor() {
    effect(() => {
      console.log(this.children().length);
    });
  }
}
```

### Small updates: ng-content

Since v18 You can now give a default value to ng-content. This allows you to have placeholder text for empty list or other components with no current content.

## Coming up

- Fully support zoneless apps
- Extend the signal support for example on forms and the router
- Full signal components
- SSR rendering mode selection for routes (eg serverside, client side or build side)


Hackathon 2024

The team building and learning experience of the FrontValue Hackathon 2024.

A Journey of Learning & Fun at our <mark>Hackathon 2024</mark>


In the spring of 2024, FrontValue went on a Hackathon to south Limburg. We were there to learn about all kinds of aspects of our daily job and how to get even better at what we love doing.
The most important values of FrontValue are quality, knowledge (sharing) and fun. A Hackathon is the best way to combine these values.
We’ve rented a big house in the south of Limburg where we are surrounded by wonderful nature and a luxurious interior.
!["Venue"](images/blogs/hackathon-2024/hackathon-venue.jpg)

## The beginning

It all started with the idea of having a fun time together but with the main goal of learning new things. I’ve sat with a colleague to think of learning objectives.
What do we really want to learn during these days, that we can directly use in our daily job.

The list:

- Experience a complete setup of an enterprise application
- Exposure to new technologies you’re not using day to day
- Software processes like scrum to manage priorities and have some structure.
- Communication between teams to align features and requirements
- Grow as a team

## First day

### Evening

On the first evening we gave the teams a short briefing on the assignment. The core concept is an application on top of the [AirLabs API](https://airlabs.co/) and create a dashboard to show flight schedules,
a map to show current flights and (still a secret at this point) a delayed flights overview.
This application should be fully automated in terms of testing, deploying, publishing and upgrading.

For these requirements we’ve started with a Nx Monorepo.
In there we have two applications, one React and one Angular, and one library that contained shared components which are build on top of Lit elements.
With only this small scaffolded project the team was divided into two smaller teams. A funny fact to notice was that some colleagues choose for their safe place in the tech they know, others directly choose the opposite and want to learn all secrets.
With the base requirements the teams started eagerly on their designing phase and what needed to be built. Tasks where distributed over teams and they (thought 😅) they had a good plan to start and make the project a success.
!["Evening hacking"](images/blogs/hackathon-2024/hackathon-evening.jpg)

## Second day

### Morning

The morning after we didn’t start coding (well most of us) and took off to first do a team-building event to get rid of the I’s and become real teams.
The event was sheep herding, and we saw both teams growing every minute they spent with controlling the sheep (or was it the other way around?).
This event gave me some insights into how people work together and how to quickly gain trust in each other. You need the people around you to control the sheep and guide them in the right direction.
This is basically comparable to the product backlog where you as a team need to make sure stories are handled in the correct order with the result we expect.
The same as sheep, stories escape, explode (not literally with sheep🐑) while working on them, don’t meet your expectations, etc.
!["Sheep herding"](images/blogs/hackathon-2024/hackathon-sheeps.jpg)

### Afternoon

After returning to our villa, the real hacking and cracking started and teams took deep dives into the new apis, monorepos, architecture and quickly started to book some results.
What the teams underestimated was the time needed to get a production ready product instead of a manually deployed MVP.
Within teams, you saw the eager need for DevOps growing because we need infrastructure to deploy, test and integrate all the pieces.
As a developer of one of the teams I did see the need increasing, but I wanted the teams to find out themselves.
One team started on the DevOps side, but the other team wasn’t aware. After a while, this resulted in a mismatch of what both teams thought they needed.
And of course right at that time: DEMO time 🎉. As you might already see coming, the demo was a mix of “it works on my machine”, “I can show this small part, but it’s purely technical” and “this worked about 5min ago, why not now 🤬🤯”.

### Evening

After a long day of coding we stopped for some nicely prepared Turkish dinner and celebrated Eid al-Fitr together with some of our colleagues who did the fasting.
This dinner was interesting for two reasons. The first reason was the bonding that started during the day and the trust in each other which really, resulted in a great team feeling.
Secondly, after some time, we still are developers who are solving some hard stuff, the technical talk started. Because both teams came teams together at diner, some interesting discussions started and the teams saw that they lacked communication during the day.
It turned out that both teams were fixing the same issues and tackling the same challenges. For them this was the point where two teams didn’t really exist anymore.
Both teams started to work fluently together and building things only once. Cross team expertise was bundled and right after dinner (till very late), the productivity started to really take off.
!["Team dinner"](images/blogs/hackathon-2024/hackathon-dinner.jpg)

## Third day

### Afternoon

At noon on the second day, the next demo was planned. Compared to the first demo, this one was better organized and while there wasn’t a production environment running yet, there was way more to show.
From the organization side of the hackathon we decided that besides the two applications currently being built, the Product Owner wants a third application integrated.
This application should show the delayed flights, but it needs to be written with Vue. Quickly a new task force (as I like to call them) was pulled together, and they started.

After the demo, I started to notice something. People and teams became a little overconfident in the great successes they’ve created so far together.
So while having lunch behind the laptops (that’s how developers lunch apparently), people started to become silos again. Focus on the result, focus on the deadline of 5 pm. “We can do this” was the team spirit, but the work started to turn into islands again.
After a while I started to ask how the integration part of all the apps was coming along. Some people pointed at one of our colleagues, “he is working on it”.
Apparently, he was working on it, but also was stuck for some time.

How could this happen after the great vibes and team feeling from the past 36 hours?
Personally, I think that people started to feel the pressure of the deadline coming closer and closer. They lost the helicopter view on all the things that needed to be done, in order to have a fully functional application.
Communication was “dropped” because that takes a lot of time, and we need the time to program. As you can already guess at 5 pm demo time…
Every one of us was trying to convince the Product Owner to postpone the demo for 30 minutes (turning into 60 minutes). We were waiting for the final build to be deployed after about five other PR’s that were merged and deployed 🤞.
!["Team dinner"](images/blogs/hackathon-2024/hackathon-demo.jpg)

## Final result

The final result of the two days of hard work was astounding, considering that many of us didn’t have experience with the technologies being used during the hackathon.
Every individual project what was requested was there. In the app you can search for flights, track flights on a map and see delays shown on the screen.
If you’ve read the previous sentences, you saw the words “individual projects”. They are all deployed from the Monorepo and accessible from the homepage.
However, once entering the applications some of them were not completely working as expected anymore.
This was also an important lesson learned by all of us. Even when you work your ass off to make a deadline, don’t forget to keep communicating about the overlapping subjects!
It will benefit more in the end to have 90% of the features fully functional and working than having 100% of the requirements but only 80% is integrated and working.

Thanks FrontValue for providing this awesome learning experience and the fun we had together!
!["Kubbs game"](images/blogs/hackathon-2024/hackathon-fun.jpg)

Are you also interested in joining our next Hackathon, feel free to [reach out](/contact) and who knows!


Let's take a look at the improvements and new parts of React 19

A first look at <mark>React 19</mark>


The beta release of React 19 has just been released. There are some great quality of life improvements and some new things.

## The quality of life improvements in React 19

There are quite a few improvements to the existing parts of React:

- You no longer need `forwardRef`
- Put document metadata anywhere in your JSX
- Preloading resources to improve performance
- Better error messages

### Goodbye `forwardRef`

A `ref` can now be passed as a prop. This was possible before using a prop name other than `ref` such as `buttonRef`, but now you can access the `ref` as a prop in your component without `forwardRef`:

```jsx
function MyInput({placeholder, ref}) {
  return <input placeholder={placeholder} ref={ref} />
}
```

### Metadata in JSX

React 19 has official support for metadata inside components. Before React 19 you would need a package like [`react-helmet-async`](https://www.npmjs.com/package/react-helmet-async) to achieve this.

With the example below, the meta title and other related items will be updated inside the `<head>` tag of your page.

```jsx
function BlogPost({post}) {
  return (
    <article>
      <h1>{post.title}</h1>
      <title>{post.title}</title>
      <meta name="author" content="Josh" />
      <link rel="author" href="https://twitter.com/joshcstory/" />
      <meta name="keywords" content={post.keywords} />
      <p>
        Eee equals em-see-squared...
      </p>
    </article>
  );
}
```

Stylesheets are supported too:

```jsx
function Component() {
  return (
    <Suspense fallback="loading...">
      <link rel="stylesheet" href="foo" precedence="default" />
      <article class="foo-class bar-class">
        {...}
      </article>
    </Suspense>
  )
}
```

### Better error messages

Errors were previously thrown twice by an Error Boundary, and then logged using `console.error` to show you more information about the error. In React 19, you will see a single error with all the information you need. This is a very welcome change as it declutters your debugging console.

## The new parts of React 19

- Asyncronous functions in transitions
- A new `useActionState` hook
- Form actions in `react-dom` and `useFormStatus`
- A new `useOptimistic` hook
- new `use` API
- Custom element support (web components)

### Asyncronous functions in transitions

Traditionally you could already use `useState` or alternative state management solutions to manage all the various data, loading, and error states in your forms.

React 18 released the [`useTransition` hook](https://react.dev/reference/react/useTransition). This hook lets you update state without blocking the UI. This helps keep the UI updates responsive on slower end-user devices like older phones, and was a useful addition to managing state.

The `useTransition` hook can now start a transition with an `async` function. In the following example, React will manage the state of `isPending` for you, which can save you some boilerplate logic you would previously have to write using `useState`. While your `async` function is running `isPending` will be `true`. After the `async` function succeeds `isPending` will automatically be set to `false`.

```jsx
function UpdateName() {
  const [name, setName] = useState("");
  const [error, setError] = useState(null);
  const [isPending, startTransition] = useTransition();

  const handleSubmit = () => {
    startTransition(async () => {
      const error = await updateName(name);
      if (error) {
        setError(error);
        return;
      } 
      redirect("/path");
    })
  };

  return (
    <div>
      <input value={name} onChange={(event) => setName(event.target.value)} />
      <button onClick={handleSubmit} disabled={isPending}>
        Update
      </button>
      {error && <p>{error}</p>}
    </div>
  );
}
```

### The new `useActionState` hook

Asyncronous transitions are called "actions" by convention in React. A new `useActionState` hook was introduced that helps handle the most common use-cases for actions.

The `useActionState` can handle `error` and `isPending` states. If you've used [TanStack Query](https://tanstack.com/query/latest) or [Redux Toolkit Query](https://redux-toolkit.js.org/rtk-query/overview) before, you could see this as a simpler alternative for when you don't need the additional features from those libraries. Note that these sorts of libraries still provide many additional options that could benefit your user's experience.

```jsx
function ChangeName({ name, setName }) {
  const [error, submitAction, isPending] = useActionState(
    async (previousState, formData) => {
      const error = await updateName(formData.get("name"));
      if (error) {
        return error;
      }
      redirect("/path");
      return null;
    },
    null,
  );

  return (
    <form action={submitAction}>
      <input type="text" name="name" />
      <button type="submit" disabled={isPending}>Update</button>
      {error && <p>{error}</p>}
    </form>
  );
}
```

### Form Actions in `react-dom`

Updates have been made to `react-dom` that make implementing these actions even easier.

You can now pass an `async` function to a form's `action` attribute:

```jsx
<form action={actionFunction}>
```

When the `actionFunction` returns successfully, the form will be reset automatically for uncontrolled components (components where you don't manage the state via `useState` or other state management options).

You can also add the `action` to an `<input>` or a `<button>`.

A new hook `useFormStatus` is now also available, which lets you check the form status in child components in a form:

```jsx
import {useFormStatus} from 'react-dom';

function DesignButton() {
  const {pending} = useFormStatus();
  return <button type="submit" disabled={pending} />
}
```

I've used this hook before in a test application built with Next.js when the hook was still experimental, so it's good to see this hook available without the experimental warning.

Here is a snippet from an [`UploadButton`](https://github.com/EddyVinck/customer-statement-processor/blob/main/src/components/file-upload/upload-button.tsx) component I made which utilizes [server actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations) in Next.js:

```jsx
"use client";

import { experimental_useFormStatus as useFormStatus } from "react-dom";

export function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <button className="bg-slate-600 p-2 px-6 rounded-md" disabled={pending}>
      {pending ? "Submitting..." : "Submit"}
    </button>
  );
}
```

What I like about this, is that it removes the need for a lot of boilerplate code originally required to manage your form state. Passing props or providing a custom React Context is not necessary in a lot of cases now, which is great!

### The new `useOptimistic` hook

There is a new hook that helps with managing optimistic UI. The Remix documentation has a good defintion for optimistic UI if you're unsure what it means:

> **Optimistic UI**: Optimistic UI enhances perceived speed and responsiveness by immediately updating the UI with an expected state before the server's response is received
>
> &mdash; <cite>Remix documentation ([link](https://remix.run/docs/en/main/discussion/pending-ui))</cite>

In the following example, the `useOptimistic` will render the submitted name immediately when the form submits. When the submit action finishes or errors, React will then continue to use the `currentName` again.

```jsx
function ChangeName({currentName, onUpdateName}) {
  const [optimisticName, setOptimisticName] = useOptimistic(currentName);

  const submitAction = async (formData) => {
    const newName = formData.get("name");
    setOptimisticName(newName);
    const updatedName = await updateName(newName);
    onUpdateName(updatedName);
  };

  return (
    <form action={submitAction}>
      <p>Your name is: {optimisticName}</p>
      <p>
        <label>Change Name:</label>
        <input
          type="text"
          name="name"
          disabled={currentName !== optimisticName}
        />
      </p>
    </form>
  );
}
```

### The new multifunctional `use` API

React has introduced a new flexible API with multiple use-cases. It's just called `use`, and according to the official React 19 beta announcement article you can use it to "read resources in render." Practically, it means you can use it for reading promises (which is useful when you're using [`Suspense`](https://react.dev/reference/react/Suspense)) and reading a React Context.

```jsx
import {use} from 'react';
import ThemeContext from './ThemeContext'

function Comments({commentsPromise}) {
  // `use` will suspend until the promise resolves.
  const comments = use(commentsPromise);
  const theme = use(ThemeContext);

  return comments.map(comment => <p style={{color: theme.color}} key={comment.id}>{comment}</p>);
}

function Page({commentsPromise}) {
  // When `use` suspends in Comments,
  // this Suspense boundary will be shown.
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  )
}
```

See the official [`use` documentation](https://react.dev/reference/react/use) page for more information.

### Support for web components in React

Web components (or [Custom Elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements)) are now fully supported in React. Previously there were some issues when using custom elements in React, but now they should behave as you would expect when doing Server Side Rendering or Client Side Rendering.

## Should you upgrade to React 19?

React 19 is in beta right now. The React team recommends waiting until frameworks have implemented it under the hood before you upgrade to React 19 for your application.

This release is mostly to prepare library authors, so that all your favorite React libraries will be ready when React 19 goes out of beta. There are great improvements and features in this new React version, but we will have to wait until our favorite React frameworks have implemented them.

For the full release notes, see the full [React 19 beta release notes on react.dev](https://react.dev/blog/2024/04/25/react-19). If you're curious what changes you need to make when upgrading, be sure to take a look at [the official React 19 upgrade guide](https://react.dev/blog/2024/04/25/react-19-upgrade-guide).


Senior frontend engineer. Loves his work. Loves sharing

Agnostic UI in Nx Monorepo

How to share components across different frameworks from a single code base? How to implement Lit (web components) to React & Angular?

Add an agnostic UI library in <mark>Nx monorepo</mark>, share across the <mark>frameworks</mark>



In my other [article](./setup-monorepo), we created an Nx monorepo and added Angular and React applications that we managed to run together. Now it's time to take another step and create an agnostic UI library.

## Why are we doing this?

We are learning how multiple teams in big enterprises work together. Where multiple structures are in place and teams have to manage all these projects. Although the frameworks betweens may differ, they have something in common. And that's the UI, because the UX should be consistent.
It can't be that in one application the primary button is blue and in another it's green.

![Add UI library to nx](images/blogs/add-ui-library-to-monorepo/add-ui-library-6.png)

To achieve this, you have to share the UI library across the frameworks. And it should be an agnostic UI library, otherwise you can't easily share an Angular component directly with React applications (or vice versa). And don't forget, it should also be developer friendly.
Since we have the Nx monorepo, we can create a library like that.
After we are finished, it will be like this (you can show this graph with the `nx graph` command):

![Add UI library to nx](images/blogs/add-ui-library-to-monorepo/add-ui-library-5.png)

## Choosing the Library

When I did some research I discovered two potentially interesting options for UI libraries. Both looking good:

- [StencilJS](https://StencilJS.com/)
- [Lit](https://lit.dev/)

Both have their pros and cons. Let's dive in.

### StencilJS

Initially, StencilJS seems perfect for our use case. It has automatic generators and wraps around the frameworks. It looks amazing because this way every developer can work with the UI library natively. Unfortunately when I try to implement it into the Nx monorepo I encounter big challenges due the bugs in [nxext/stencil package](https://www.npmjs.com/package/@nxext/stencil). On top of that, it's not really compatible with Angular 17 and React 18. Maybe in the future we can try again.

![Stencil bug](images/blogs/add-ui-library-to-monorepo/add-ui-library-7.gif)

### Lit

From my past experiences, I already knew the Lit and web components. And I know that we can use Lit in our applications when it's compiled to web components. But still, I did my homework and did additional research on Lit.

![Lit](images/blogs/add-ui-library-to-monorepo/add-ui-library-8.png)

#### What is Lit

Initially, Lit is a simple library for building fast, lightweight web components. So when you create a component with Lit, it builds into a web component. Then you can use this web component in Angular, React, Vue applcations and even directly in HTML pages. So it looks perfect for us.

## Installing Lit to the Nx Monorepo

First, we have to install the Nx/JS library (if it's not already installed):

```bash
npm i -D @nx/js
```

We are installing dev dependencies because we will only use it to generate libraries and not use it in the runtime.

Then, create a library in the Nx monorepo (of course you can choose the directory):

```bash
nx generate @nx/js:library --directory=libs/ui
```

For personal preference and I think better management, I want to install my UI library under the libs folder. Now we have a shared library.

Installing Lit:

```bash
npm i lit --save
```

To better understanding we will create a simple LitElement. Just create a .ts file under libs/ul/src/lib/yourcomponentname/yourcomponentname.ts (you can choose the folder structure).
And create a simple button with LitElement:

```typescript
import { LitElement, css, html } from 'lit';
import { customElement, property } from 'lit/decorators.js';


@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
   static override styles = css`
   button {
     background-color: blue;
     color:white;
   }
 `;
   @property()
   name?: string = 'World';


   override render() {
       return html`<button>Hello, ${this.name}!</button>`;
   }
}
```

Now we have to export the component. To do that just write a single line into `ui/src/index.ts`:

```typescript
export * from './lib/components/simple-greeting';
```

## Using LitElement Component in an Angular App

Now the fun part begins. We just created our first component and we need to use it in our applications. Let's start with our Angular application. In order to use web components in Angular applications, you need to add CUSTOM_ELEMENTS_SCHEMA into your component.

```typescript
schemas: [CUSTOM_ELEMENTS_SCHEMA];
```

Now we are importing our library with

```typescript
import 'libs/ui/src/index';
```

After importing we can use our component with:

```html
<simple-greeting name='Earth'></simple-greeting>
```

![Add UI library to angular](images/blogs/add-ui-library-to-monorepo/add-ui-library-1.png)

## Using Lit Element Component in React App

For React applications unfortunately we can't directly use them. So we need to wrap the component using `@lit/react`. First we need to install it:

```bash
npm i @lit/react --save
```

Then we need to update the component:

```typescript
import { createComponent } from '@lit/react';
import * as React from 'react';


// Existing component code...


export const SimpleGreetingComponent = createComponent({
   tagName: 'simple-greeting',
   elementClass: SimpleGreeting,
   react: React
});
```

Now we can use our component in the React application. To do that you need to import it and use it like a React component:

```typescript
import { SimpleGreetingComponent } from "ui/src/index";
<SimpleGreetingComponent name='Earth' />
```

![Add UI library to react](images/blogs/add-ui-library-to-monorepo/add-ui-library-2.png)

### Handling Errors

When I implement my component to the React application I encounter some difficulties. Maybe you will have the same difficulties as well. So here are my solutions:

#### Reflect Metadata error

![Add UI library to react error](images/blogs/add-ui-library-to-monorepo/add-ui-library-3.png)

If you encounter this error, just install the `reflect-metadata` package to you dev dependencies:

```bash
npm i reflect-metadata --save-dev
```

Then import to your web component:

```bash
import "reflect-metadata";
```

#### For property errors

![Add UI library to react error](images/blogs/add-ui-library-to-monorepo/add-ui-library-4.png)

If you have this error, you can change your properties like

```typescript
static override properties = { name: { type: String } }
name = 'World';
```

That will solve the problem.
More details [here](https://lit.dev/docs/components/properties/#avoiding-issues-with-class-fields)

## Conclusion

Now we have two applications using the same UI library from a single code base. We can extend this library and add other components like cards, inputs ect.

!["Adding UI library celebration"](images/blogs/setup-monorepo/setup-monorepo-10.gif)


Setup Monorepo with React & Angular

Running multiple applications together with Nx Monorepo.

How to setup monorepo with <mark>Angular</mark> And <mark>React</mark> running together



As a frontend engineer you must have wondered at least once in your life how big companies can run multiple architectures in a single code repo and how to develop all together, making the teams collaborate from a single codebase. For example some teams can develop applications with React, some with Angular and others with Vue.

Hundreds of developers are trying to merge something into code, thousands of lines of code and files are changing... It should be a hell of a mess. But how can they manage all these things?

Well here is the answer:

## First things first

What is in my mind is to first create Angular and React applications together. First I tried to create a folder and in that folder, I created two folders called angular and react (I'm also confused when I write this). Next I tried to start the applications in their folder. But it creates a mess. And it’s so hard to handle.

For instance every application has a package.json file and node_modules folders. And you know the meme right?

!["Node Modules meme"](images/blogs/setup-monorepo/setup-monorepo-6.png)

So if I want to have a single package.json and node_modules folder and single configuration file etc I have to find a solution.
And here comes to concept of monorepo:

!["Mono Repo"](images/blogs/setup-monorepo/setup-monorepo-7.gif)

## What is monorepo

In a normal multi repo structure, many projects are held in entirely separated, version-controlled repositories. But monorepo is a single version-controlled repository which contains many applications, living together side by side and helping each other to become better applications (Ok, I know this is a little exaggerated).

!["Mono Repo vs Multi Repo"](images/blogs/setup-monorepo/setup-monorepo-8.png)

## Choosing monorepo tool

So now we learned about the existence of monorepo. That's cool but how can we create a monorepo? Is there a tool for it? Or do I need to make it manually?
If you do search for monorepo tools like I did, you'll probably look like this:

!["Mono Repo Tools"](images/blogs/setup-monorepo/setup-monorepo-9.gif)

Because there are many good monorepo tools such as:

* Bazel
* Gradle
* Lage
* Lerna
* moon
* Nx
* Pants
* Rush
* TurboRepo

Well I did my research and decided to choose Nx, because:

* Full support of Javascript and Typescript.
* Fast
* Code Sharing
* Code standards
* Deployments
* Versioning

and many more features. Check out their [website](https://nx.dev/getting-started/why-nx) for the details.

So let's dive in, shall we?

### Creating workspace

Now we will do some magic with Nx CLI. First we have to create a workspace.
We'll create a workspace with Angular. You can also start with React or Vue, it's your choice. I'm familiar with Angular so I'll start with that.

You don't need to install the entire Nx CLI. With the npx feature you can directly run the Nx CLI command with ``npx create-nx-workspace@latest``.

It will ask some questions to set up your workspace. The **most important** thing is selecting integrated monorepo. Because we will add a React application and a UI library later.
Then let the magic happen.

!["Setup MonoRepo for angular"](images/blogs/setup-monorepo/setup-monorepo-1.png)

For the other settings, you can select whatever you prefer. For example you can skip installing e2e tests or you can select esbuild over webpack.

Now we have created our monorepo with an Angular app 🎉. Wanna see your angular app? Just run the ``nx serve angular`` command.

![Run Angular in monorepo](images/blogs/setup-monorepo/setup-monorepo-4.png)

### Before we continue

I have to tell this because it saves a lot of time. Since we are continuing with Nx there is a great extension for your favorite IDE or editor. You can download Nx extensions for VSCode or JetBrains IDE's (like Webstorm and IntelliJ) from the [NX website](https://nx.dev/core-features/integrate-with-editors).

## Adding React Application

Now we have an Angular app. But let's do something fun... Adding a React application into our monorepo. Why? Because we can. And it shows that in real life use, it is possible for different teams within the same company to choose their preferred frontend framework.

To add a React application we need to install the nx/react package. In order to do that just install a normal npm package with ``npm add -D @nx/react``. Note: we are installing for dev only because we don't need it in the runtime. Just for generating a React application.
Then create a React application with the command ``nx g @nx/react:app my-new-app``.

After Nx finishes the setup, we now have a React and an Angular app 🥳.

!["Setup MonoRepo for react"](images/blogs/setup-monorepo/setup-monorepo-2.png)

You can run the React application with ``nx serve react``.

![Setup MonoRepo for React](images/blogs/setup-monorepo/setup-monorepo-5.png)

## Run Angular and React app together

We had a great start. We have an Angular app and a React app in a single monorepo. What if we want to run them together? They are using the same port and also we want to run them with a single command. As I stated before, Nx has great features. You can run all your applications with ``nx run-many --target=serve --all``. Or if you want to select which applications to run just add them as projects ``nx run-many --parallel --target=serve --projects=angular,react``.
But wait. We forgot to change the port. I have changed the React application port by opening the ``project.json`` file in the ``apps/react/`` folder. And under the ``serve/options`` just add ``"port":4201`` (of course you can select your preferred port).

```json
"options": {
   "buildTarget": "react:build",
   "hmr": true,
   "port": 4201
},
```

Now when I run the serve command again we will have both applications up and running.

!["Running both applications celebration"](images/blogs/setup-monorepo/setup-monorepo-10.gif)

In my next [article](./add-ui-library-to-monorepo) we will add a UI library into our monorepo and use it in our applications. So stay tuned!


What We Want To
Share With You