
In today’s post, we’ll explore how to use Angular's `ResizeObserver`, signals, and observables to create SVG elements that respond to container size changes automatically. This setup forms the foundation for responive charts in Highpass, our upcoming Angular-native chart library. Highpass is still in development, but if you want to follow along with our progress, keep checking back here on the LiveLoveApp blog or follow me on X (Twitter) at [@MikeRyanDev](https://twitter.com/MikeRyanDev).

### Step 1: Creating a Basic Angular Component for SVG Wrapping

Our starting point is a minimal Angular component that wraps a single SVG element. By leveraging the dynamic sizing of the host element, we can project its dimensions directly onto the SVG. This approach allows the SVG to scale as its container changes size without manual adjustments.

Here’s what our base component looks like:

```typescript
import { Component, ElementRef, inject, ViewChild } from '@angular/core';

@Component({
  selector: 'responsive-svg',
  template: `<svg #target></svg>`,
})
export class ResponsiveSvgComponent {
  hostElementRef = inject(ElementRef);
  svgElementRef: viewChild<ElementRef<SVGElement>>('target')

  // Other responsive logic will follow
}
```

This is a straightforward setup: the component template contains an SVG element wrapped in a container. We’ll observe the size of this host container element and project that size directly onto the SVG element, making the SVG’s width and height responsive to its container.

### Step 2: Setting Up a Size Observable with `ResizeObserver`

Next, we need to track changes to the component’s size. By injecting `ElementRef`, we can access the host element’s dimensions and monitor them with `ResizeObserver`. Here’s how to set up an observable `chartSize$` that emits the host element’s size whenever it changes:

```typescript
chartSize$ = new Observable<Rectangle>((subscriber) => {
  const el = this.hostElementRef.nativeElement;
  const rect = el.getBoundingClientRect();
  subscriber.next({
    start: [0, 0],
    end: [rect.width, rect.height],
  });

  const resizeObserver = new ResizeObserver(() => {
    const rect = el.getBoundingClientRect();
    subscriber.next({
      start: [0, 0],
      end: [rect.width, rect.height],
    });
  });
  resizeObserver.observe(el);

  return () => {
    resizeObserver.disconnect();
  };
});
```

#### Explanation:

- **Observable with `ResizeObserver`**: This observable watches for size changes in the host element and emits a `Rectangle` whenever the size changes.
- **Cleanup**: We return a `disconnect` function to stop observing when the component is destroyed, preventing memory leaks.

### Step 3: Converting the Observable to a Signal

With the size observable in place, we convert it into a signal using `toSignal`. This lets us access the component’s dimensions reactively throughout the component:

```typescript
rect = toSignal(this.chartSize$, {
  requireSync: true,
});
```

In the constructor of our chartSize$ observable, we syncrhonously emitted the host element's initial rectangle size. That let's us set the `requireSync` flag to `true` in `toSignal(...)`. The advantage of this approach is that, without `requireSync` (or supplying an `initialValue`), the type of our signal would be `Signal<Rectangle | undefined>`. With the synchronous requirement, instead the type is just `Signal<Rectangle>`, letting us avoid `undefined` checks throughout the implementation.

This signal, `rect`, now updates automatically whenever the container changes size, so we can use it in any calculation or layout adjustment in our component.

### Step 4: Applying Dynamic Dimensions to the SVG

With Angular’s `effect`, we set the SVG’s `width` and `height` attributes based on `rect`. Each time `rect` updates, `effect` updates the SVG dimensions automatically.

```typescript
constructor() {
  effect(() => {
    const el = this.svgElementRef()?.nativeElement;
    if (!el) {
      return;
    }

    const [x, y] = this.rect();

    el.setAttribute('width', `${x}`);
    el.setAttribute('height', `${y}`);
    el.setAttribute('viewBox', `0 0 ${x} ${y}`);
  });
}
```

The `effect` observes `rect` and applies its dimensions to the SVG, making it adapt reactively to size changes in the host element.

### Responsive Layouts Using Signals

Now that our SVG scales responsively, we can extend this setup to create responsive layouts. For example, if we define the `xScaleRange` using signals, it can dynamically adjust based on the size of `rect`:

```typescript
xScaleRange = computed(() => {
  const dataRect = this.dataRect();
  return [dataRect.start[0], dataRect.end[0]] as const;
});
```

Whenever `rect` changes, `xScaleRange` recalculates, ensuring the layout adapts to the updated dimensions without manual intervention.

### Why This Pattern Works

1. **Efficient Updates**: `ResizeObserver` triggers updates only when necessary, meaning there’s no unnecessary work happening.
2. **Declarative Adjustments**: Using observables and signals keeps the layout declarative. We don’t need imperative resize logic, which keeps things simple and clear.
3. **Scalable**: This setup works for any SVG component, making it a versatile addition for any responsive visualization needs.

### Future Applications in Highpass

As we continue building Highpass, this approach will form the foundation of its responsive layout capabilities, allowing components to adjust dynamically to different screen sizes and layouts. If you’re interested in more techniques like this for Angular and SVG, check back here on the LiveLoveApp blog or follow me on X (Twitter) at [@MikeRyanDev](https://twitter.com/MikeRyanDev).


Responsive SVGs in Angular with ResizeObserver, Signals, and Observables

2022 Marketing at LiveLoveApp: A Year in Review

## Fresh Start Feelin'

Don't you just love that fresh start feeling of a new year?

I'm that to-do-list, goal-setting enthusiast, and when it comes to work, I'm certainly no different.

The opportunity to reflect, creates, in my opinion, a great catalyst for moving forward with new insight, intention, and actionable steps.

So, let's peek at the past year here at LiveLoveApp in the marketing department, which has been both an exciting and rewarding opportunity to help to establish and build alongside our leadership.

## From Scratch…

Let it be said, when I came on board, the cake was baked. I didn't so much as have to stir the batter, it was beautifully presented to me ready to be iced and decorated, asking where and how it should be placed in the storefront window. The cake already smelled, looked, and tasted delicious before I ever walked into the store.
Brian and Mike, along with the helping hands of SonCreative had an impressive hold on what they wanted LiveLoveApp's brand identity to look like from the start. I cannot personally take credit for our inclusive and beautiful color palette, our friendly Brian the Lion logo, playful yet professional fonts, or our overall tone, which so effortlessly showcases our brand voice of being welcoming and professional while complementing our corporate culture where we aim to be inclusive, sustainable, introspective, respectful, and candid.
With our brand's foundation being so well laid out I was set up for success, and I loved it even before officially joining the team. I knew it was going to be one of those rare opportunities to bring a brand to life in both a tangible and digital sense through storytelling and strategy. A dream for anyone who loves both creative design work and the power of positioning.

## First 30 Days

We got straight to work and created a marketing strategy, or more intensively, an integrated marketing communications plan that was constructed heavily from data-driven market research and how we would plan to position ourselves to ensure we were delivering a cohesive message across multiple channels and reaching our target audience. “What's the competitive advantage? What's our unique value proposition? I don't know what this term is… let me create a tech glossary!”

30 days later, after finding joy in perceptual mapping and SWOT Analysis, we were able to further define, sharpen and strengthen our brand voice through this 100-page internal document, that's right… 100 pages. We continuously refined and finessed as a team, and step-by-step it all came to life.

We outlined everything in this manner knowing our key objectives as a young company would be to build a strong foundation and brand awareness both internally and externally and deliver a consistent experience for our valued customers at every touchpoint, with a strong focus on content marketing.  

## Curate and Create…

We had the ideation, now it was time for execution. Our #1 goal was to create compelling thought leadership content focused primarily on owned and earned media.

I was given quite a bit of room to play and create. I think when you have great leadership who fosters your unique skillset, removes barriers, and regularly communicates it allows you to flourish. Thanks, Mike and Brian!

Compliments aside, we began designing content, gathering assets, and building our archives. In the following 90 days, we developed:

- Social media content, themes, and oversaw content calendars
- An Employee Handbook
- Posting schedules pulled from data analytics
- Brand story scripts and shot lists
- Our first podcasts
- Blogs, blogs, and more blogs 🙌

We really fell in love with our “squiggly” lines.

## Hurdles and Hiccups

For the sake of writing this in chronological order, we won't gloss over our greatest hiccup early on…when you hire a marketing strategist and content creator but then they very suddenly become out of commission within the first 90 days due to a non-work-related injury.

Just as we were gearing up for some exciting off-site productions together, real life got in the way. We had to pause, due to an injury, surgery, and recovery.

Key takeaway? Don't try to go back to the gym and think you're 21 years old again.

How did we cope and carry on? With a lot of grace and positivity, we designed and scheduled 90 days of content ahead of time. This was simply one of those moments where you put your head down, do the work, and keep checking off each to-do on your list without losing focus.

Truer words were never spoken

> “Inch by inch, life's a cinch. Yard by yard, life's mighty hard,” ― John Bytheway.

## Back on Track (no pun intended)

6-8 weeks later we were back on track, but travel opportunities would be limited for some time, so it was on us to get creative while maintaining consistency. With the notable NgConf just around the corner, we began creating promotional items and planning with the creation of:

- Trade show banners, QR codes, and company stickers
- A logo reveal
- Video productions directed remotely
- Upcoming workshop logistics and promotions
- Lead page and lead magnet development
- Refreshed website HERO designs
- Producing our first video in a video tips series to be continued

During all of this, we still managed to sort through the data and analyze what was working and not working and we showcased measurable increases in traffic overall with captivating content being top of mind.

Fortunately, much of our content is educational-centered, and Mike and Brian have continued to deliver! This is where a little trial and error marketing (not always favored) was implemented, and we discovered what works well for us. For instance, we loved our podcasts, but the time commitment may not have been feasible in a business sense, at least at the time. So, it's been important to us to recognize how can we deliver the greatest value to our customers and community.

## Strong and Steady

During the final quarter of this year, we had several exciting speaker events to look forward to, but one that stands out was the opportunity for Mike and Brian to present as the closing keynote speakers at NGRome. This was going to be a great chance to do something a little different, and we delivered. In a collaborative effort, we storyboarded, produced, and edited a video paying homage to Rome's mid-1960s cinematic era of spaghetti westerns by creating our very own colorful duel followed by some epic bloopers. Due to time and schedule constraints, we really had to work together and get a little extra creative. This involved a cell phone and little extra enthusiasm on Mike and Brian's end, extra thank you to our fabulous filmmaker Bonnie for this one! I also really enjoyed getting creative during post-production for this one and we can't forget Roger's help scripting and sharing his dynamic voiceover talents with us.. I think we can all agree that it was a fun memorable project to round out the year.

As we approached the holiday and travel season, it was important to us to maintain the same consistency we had been with content creation while developing new marketing campaigns and marketing channels to reach new leads.

Our data has shown that in addition to our blogs, videos are performing well. As a big video marketing advocate, we decided we would dedicate our attention to product and service videos to finish the year on a high note.

We'd love to invite you to peek at our product services pages to learn more about what LiveLoveApp has to offer and how we can provide you and your team value through our consulting services.

## That's a Wrap: Key Takeaways

Now, for the retrospective. We believe strongly in transparency and helping to build up our community through education, resources, and tools. We're inviting you to see what did and didn't work for us. Maybe it will inspire you or save you just a bit of time on your end.

## Ways in which we Thrived

- Bringing our brand to life on paper - Creating our one-pager was an eye-opening collaborative design effort that keyed in on what we wanted our brand to look like on paper.

- We had a variety of expert skills and talents that complimented one another - Everyone brought unique creative talents to the table and gave it their all, all the time. We always rolled with the punches with enthusiasm and energy which made every product that we created together a joy to be part of.

- Not necessarily taking the easy road - Video productions can be technically complicated, even more so when not everyone is geographically within reach. It would have been easy enough to avoid them altogether and pursue different ways of reaching our audience. However, had we done so we would have missed out on quite a bit of fun and some creative content. Each individual project has been diverse, intentional, and effective. We have showcased a variety of tones within our productions that manage to complement our brand voice overall, and I'm proud of our team for being up for this challenge.

- Creating quality content - I think we can all be proud of each blog, graphic, video, podcast, lead page, and tangible promotional item. We each played our part in the execution of the development, design, and distribution process. Knowing content marketing would be a valued part of our strategy this past year we did an excellent job to produce a cohesive brand voice that was both friendly and professional at every touchpoint.

## Overcoming Obstacles and Opportunities for Growth

- A lengthy hiatus - 🙋🏻‍♀️ raise your hand if you've ever had a totally unexpected event in your life and were grateful for leaders who stood by their company values and word. I hope that if this ever occurs to you, you have the same kindness offered to you. The number one lesson here was patience and perseverance. As a team we overcame, we learned, we took the necessary steps, and we got right back to work without missing a beat.
  Health matters, physical and mental! Cheers to a hopeful healthy 2023 ahead!
- Travel Restrictions – Working remotely absolutely has its benefits, and we pride ourselves on being a remote-first company. Trust me, I love making coffee and sitting down at my home office to get to work avoiding the rush hour traffic, but one fallback in the production world is not being able to hit record whenever we'd like. So, with that small obstacle, we've gotten creative at every turn. From this, we've challenged ourselves and strengthened our skillset. I'll call it a win!
  For example – when you need to film your team in a desert, but due to scheduling conflicts and time constraints it means you get scrappy with a cell phone, we still aimed for an epic on-brand delivery of a finished product, and it was an all-hands-on-deck success.
- No one starts as an expert - Items that weren't heavily mentioned were paid media and the nitty gritty tactics such as building lead magnets, all of which we dabbled in this year and will continue to do so. It's a learning process and one we're being very intentional with.

## 2023

Well, for this one, we invite you to stay tuned, as we continue to strategize and implement new methods and create more content. Thank you for not only being a valued client and member of our community but watching us and cheerleading us as we continue to grow our knowledge, efforts, and team. And as always, we value your opinion so please join in the conversation and let us know what you might like to see from LiveLoveApp in the coming months.




2022 Marketing at LiveLoveApp: A Year in Review


What does the future of web development in 2023 look like?

Great question!
In this article, I'll try to answer what I think are the top 20 questions about the future of web development in 2023.

## What new technologies or frameworks will become popular in 2023?

While it is difficult to predict with certainty as the field of web development is constantly evolving and new tools and approaches are constantly being developed, a few technologies that may see increased adoption in the future include:

- Serverless architectures and functions-as-a-service platforms, which allow developers to build and deploy applications without having to manage infrastructure.
- Low-code or no-code platforms, which enable developers to build applications using visual drag-and-drop interfaces and pre-built components, rather than writing code from scratch.
- Artificial Intelligence (AI) and Machine Learning (ML) tools, which can be used to build intelligent applications that can learn and adapt over time.
- Continued adoption of Application Programming Interfaces (APIs) that enable software engineers to build applications with greater capabilities, including AI and ML.
- Further expansion of tooling to minimize lead time for changes and increase continuous integration and deployment.

## How will the role of web developers change in 2023?

The role of software engineers is likely to continue evolving as new technologies and approaches are developed in 2023.
We may need to learn new skills and technologies in order to keep up with the changing landscape of web development, which, let's be honest, is nothing new.
We may also be required to work more closely with others in our organizations and teams, such as designers and data scientists, in order to build complex, data-driven applications.
Finally, we will need to embrace new technologies such as AI, ML, and blockchain.

## How will the demand for web developers change in 2023?

The demand for software engineers is likely to continue to be strong in 2023, as businesses and organizations of all sizes rely on software, and specifically the web, to reach and engage with their customers and stakeholders.
The increasing complexity and data-driven nature of web applications will drive demand for more specialized software engineers and architects with advanced skills in areas such as data analysis and machine learning.

## How will the tools and technologies used in web development change in 2023?

Web development tools and technologies are constantly evolving, and it is likely that new tools and approaches will emerge in 2023.
Some possible developments in this area include:

- Increased use of artificial intelligence and machine learning tools to automate tasks and improve the efficiency of the development process.
- Greater integration of design and development tools, allowing designers and developers to work more closely together and streamline the development process.
- Continued evolution of web browsers and other client-side technologies, which may lead to new possibilities for building interactive and immersive web applications.

A few browsers and technologies to be on the look out for in 2023 are:

- [Arc from The Browser Company](https://arc.net/)
- [Sizzy browser for web developers](https://sizzy.co/)
- [Nx for a next-gen build system with first-class monorepo tooling](https://nx.dev/)
- [Turborepo is a high performance build system for JavaScript](https://turbo.build/repo)
- [just is a handy way to run project commands](https://just.systems/man/en/)
- [SolidJS is a reactive JS framework for building UI](https://www.solidjs.com/)
- [Qwik JS framework for building resumable and high performance web applications](https://qwik.builder.io/docs/overview/)

## How will the design and UX of web apps change in 2023?

Web design and user experience are also constantly evolving, and it is likely that we will see significant changes in these areas in 2023.
Some possible developments include:

- Increased use of artificial intelligence and machine learning to personalize and optimize the user experience.
- Greater integration of virtual and augmented reality technologies to create more immersive and interactive web experiences.
- Continued evolution of mobile and responsive design, as more and more users access the web on a variety of devices with different screen sizes and resolutions.

## How will the security and privacy of web applications change in 2023?

As the importance of data security and privacy continues to grow, it is likely that we will see increased focus on these issues.
Some possible developments in this area include:

- Greater use of encryption and other security technologies to protect data in transit and at rest.
- Increased adoption of secure coding practices and tools to prevent common vulnerabilities such as injection attacks and cross-site scripting.
- More stringent regulations and compliance requirements, particularly in industries such as healthcare and finance.

## How will the development and deployment process for web applications change in 2023?

The development and deployment process for web applications is likely to continue to evolve as new tools and technologies are developed.
Some possible developments in this area include:

- Increased use of continuous integration and delivery
- Decreased build times through computation cache, both locally and through cloud services
-

## What will be the most popular programming languages for web development in 2023?

It's difficult to predict exactly which programming languages will be the most popular in 2023, as it depends on a variety of factors such as the needs of businesses and organizations, the capabilities of new technologies, and the preferences of developers.
However, it is likely that languages that are widely used and have strong communities of developers and resources, such as JavaScript, Python, and Java, will continue to be popular in 2023.

## How will the role of web developers change in 2023?

Web developers will likely continue to play a crucial role in building and maintaining web applications.
However, the specific tasks and responsibilities of web developers may change as new technologies and methodologies are developed and become widely adopted.
For example, the use of artificial intelligence and machine learning in web development may become more common, which could require web developers to have a strong understanding of these technologies.

## How will the use of mobile devices impact web development in 2023?

The use of mobile devices to access the internet has already had a significant impact on web development, and this trend is likely to continue in 2023.
As more people use smartphones and tablets to access the web, it will become increasingly important for web developers to design and build web applications that are responsive and optimized for mobile devices.
This will require using responsive design techniques and leveraging technologies such as Progressive Web Apps (PWAs) to provide a seamless user experience on mobile devices.

## Will the use of traditional web browsers decline in 2023?

While it is possible that the use of traditional web browsers may decline as more people access the web through other means, such as mobile apps, virtual and augmented reality experiences, and voice assistants, I believe that web browsers will continue to be the most popular way to access the internet and that they will continue to evolve and adapt to new technologies and user needs.
We are already starting to see trends where new browsers and innovations are entering the marketplace that is currently dominated by Google's Chrome browser.
While we don't know the adoption rate and success of these new browsers, it is an exciting time as web developers to be a part of the next major shift in browser technologies.

## How will the use of AI and ML impact web development in 2023?

The use of artificial intelligence and machine learning in web development is likely to increase in 2023, as these technologies can help to automate tasks, improve user experiences, and provide personalized content and recommendations.
Software engineers building web applications will likely need to become familiar with these technologies and learn how to integrate them into their projects and organizations.

## How will the use of virtual and augmented reality impact web development in 2023?

The use of virtual and augmented reality in web development is likely to increase in 2023, as these technologies offer new ways for users to interact with and experience websites and web applications.
We may need to learn how to design and build immersive experiences using these technologies, and may also need to consider the technical requirements and limitations of different VR and AR devices.

## How will the use of blockchain technology impact web development in 2023?

Blockchain technology has the potential to revolutionize many aspects of the web, including security, identity, and data management.
Software engineers who are familiar with blockchain technology may be in high demand in 2023 (and beyond) as more organizations adopt this technology and build decentralized applications (dApps).

## How will the use of voice assistants impact web development in 2023?

The use of voice assistants, such as Amazon's Alexa and Google Assistant, is likely to increase in 2023 as more people use these devices to access the internet and perform tasks.
Software engineers may need to consider the unique capabilities and limitations of voice assistants and learn how to design and build web applications that are optimized for voice interactions.

## How will the use of the internet of things (IoT) impact web development in 2023?

The use of the internet of things (IoT) is likely to have a significant impact on web development in 2023 and beyond.
We may be responsible for building user interfaces and applications that allow users to interact with and manage their connected devices.
Overall, the use of IoT is likely to lead to the development of new and innovative web applications and services, as well as new challenges and opportunities for web developers.

## What is Web3?

Web3, also known as the decentralized web, refers to the use of blockchain technology and decentralized protocols to build a new generation of applications and services on the internet. It is intended to provide a more secure, transparent, and decentralized alternative to traditional centralized web services.
Web3 technologies, such as Ethereum and other smart contract platforms, enable the development of decentralized applications (DApps) that can run on a distributed network of computers rather than on a single server or group of servers controlled by a central authority.
These DApps can be used to create decentralized versions of traditional web services, such as social media platforms, online marketplaces, and even entire economies.

Web3 has the potential to revolutionize the way the internet works by providing a more secure and transparent alternative to traditional centralized web services. It has already spawned a number of innovative applications and is expected to continue to grow and evolve in the coming years.

## Will Web3 kill web2?

Definitely not.
While web3 technologies have the potential to disrupt and revolutionize certain aspects of the internet, it is more likely that they will coexist with traditional centralized web technologies rather than replacing them entirely.

## Should I learn web3 technologies in 2023?

There is a growing interest in web3 technologies and their potential to provide a more secure, transparent, and decentralized alternative to traditional centralized web services.
However, it is still in the early stages of development and adoption, and it will likely take some time before it becomes widely used.
As web3 technologies continue to mature and gain mainstream adoption, it is likely that they will increasingly be used alongside traditional web technologies rather than replacing them.

Learning more about contract platforms like Ethereum and other blockchain-based platforms, as well as tools and frameworks for building DApps and DAOs will be beneficial in 2023.
To get started, I would suggest looking at [web3.js](https://web3js.org/).

## Is React (aka fill in your favorite JS framework of 2022) dead in 2023?

No, React.js is not dying and not going anywhere.
In fact, React is the most widely-used JavaScript library for building user interfaces (UIs) and is one of the most popular tools for front-end web development.

React is widely used by a variety of companies and organizations, including Facebook, Netflix, Airbnb, and Asana, and it is an important tool in the toolkits of many web developers.
It is not dead (or dying), and it is likely to continue to be a popular and widely-used tool for building SPAs in the future.

## Where is LiveLoveApp investing in the 2023?

LiveLoveApp is investing in both helping you solve the challenges of today while also staying ahead-of-the-curve and investing in new technologies that are going to be shaping the future of the internet in 2023 and beyond.



20 Questions on The Future of Web Development in 2023


In this article we'll explore and answer the most relevant questions on the 2022 Micro Frontend architecture pattern.

## What is Micro Frontend Architecture?

Micro Frontend (MFE) architecture enables independent deployment of features of an application by vertically slicing the application among multiple teams.
Traditionally, teams building a Single Page Application (SPA) would be divided between the frontend, the backend, and quality assurance.
Further, large applications may require multiple frontend teams working on a single code base that are divided by feature or role.
Often, the result is overhead between these multiple teams building the SPA.

## What challenges do MFEs solve?

Building applications at scale require organizational overhead, specifically:

- Organizational management
- Inter-team communication channels
- Knowledge sharing
- Documentation
- Conflict resolution
- Build time
- Dependency and dependency version management

All of these can lead to increased costs and reduced feature development velocity, and therefore, reduced innovation in a competitive market.
It should be noted that these challenges are _not_ the only factor in an organization's development velocity.

Micro Frontends seek to address these challenges by reducing the friction and cost of each overhead component as listed above.

## What challenges do MFEs introduce?

While an MFE architecture seeks to improve the development velocity of building applications at scale, the architecture introduces another set of challenges that must not be ignored.

These include:

- Micro Frontend Anarchy
- Organizational complexity
- Version mismatch
- Redundancy
- Bundle and code bloat

Let's briefly discuss each of these.

## What is Micro Frontend Anarchy?

MFE Anarchy is the result of using multiple frontend (JS) and styling (CSS) frameworks in a single SPA.
While using multiple frameworks is _technically_ possible, this leads to large bundle sizes, reduces mobility of team members, requires increased documentation, and increases technical challenges.
It is highly recommended to determine a set of chosen technologies when using a Micro Frontend architecture.
This ensures not only reduced technical challenges, but this also increases mobility and reduces onboarding and hiring costs.

## Does complexity increase?

Yes, managing the complexity of a MFE is not only a technical challenge, but also an organizational challenge.
Organizations and leadership must address planning, designing, building, deploying, and maintaining multiple applications and teams that are often distributed.
An MFE often requires additional data and state management orchestration services and layers that must be maintained.
Further, determining the team responsible for a regression or a performance impact is a new set of challenges introduced by MFE architecture.

## Can I have version mismatches?

Yes, using an MFE architecture, you may have each independently built and deployed application with unique and separate dependencies and dependency versions.
This may lead to incompatibility and unforeseen runtime exceptions and regressions.

## What about redundancy?

While using Micro Frontend architecture _can_ increase the development velocity of team, it often does introduce redundancy.
Redundancy is observed across the teams that face similar challenges, need to learn similar toolsets, and solve similar technical problems.
Further, if a regression exists in multiple micro frontends, each team must resolve the issue and deploy a hotfix independently.

## Does an MFE result in bundle and code bloat?

Overall, it is common to have redundant code between independent applications leading to code bloat.
The result is larger KBs of JavaScript code being shipped to the client for executing the application.
This is part of the cost of using Micro Frontend architecture that should not be ignored.
However, most applications using MFE architecture do not require minimal time-to-interactivity and bundle size, and therefor, this tradeoff is acceptable.

Using module federation we can reduce the resulting bundle and code bloat of an application built using MFE architecture.
Module federation enables independent builds to access another container's exposed modules.

Using module federation is a core principle to implementing Micro Frontend architecture in order to share code between applications; either that of a shared external library or that of a local library.

## What is an application shell (or host)?

The application shell, or sometimes referred to as the _host_ or _container_ application, is the initial application code that is served to the client that will compose the separate micro frontend applications, or often referred to as _remotes_.
This host application is responsible for bootstrapping the application, routing, sharing configurations, and managing state among the micro frontends.

## How do I route between apps?

Routing is slightly more complex when using Micro Frontend architecture.

First, there are routing within an independently deployed micro frontend.
In most instances, these are handled internally and are treated the same as routing within a SPA.

Second, there are routes that cross from one micro frontend application to another.
You may see this referred to as a "hard" link.
In this case, the application shell is responsible for managing the current route, the browser history, and rendering the appropriate components/applications within the browser.
One [solution for Micro Frontend routing is the single-spa library](https://single-spa.js.org/).

## How does inter-app communication work?

Inter-app communication should be limited as much as possible when using Micro Frontend architecture as this violates the goal of independently deployable applications.
However, it may be required to use a shared module to expose methods for sharing state and communicating between the micro frontend applications.

## Should MFEs share a backend?

It is ideal to use Microservices architecture along with Micro Frontend architecture.
In that case, each microservice is independently deployed and is often managed by the same team that builds the micro frontend.
Further, Microservice architecture requires that each individual microservice has its own data persistence layer.

## What about global state management?

Global state should be minimal, and therefore, using a library such as Redux is often unnecessary.
We recommend exposing a shared [Observable stream](https://rxjs.dev/guide/observable) for sharing state.

## What about local development?

Ideally, a developer on Team A should not have to build and execute the micro frontend application from Team B.
The goal of MFE architecture is to isolate knowledge and code between teams.
When using MFE architecture within a monorepo is may be helpful to disable code execution of other applications during local development.
When building integration tests it will be necessary for a developer to build and execute multiple micro frontends within the context of the host application.

## How do I test my MFE architecture?

Unit and end-to-end testing is the responsibility of each individual micro frontend application.
With that said, in order to avoid regressions and incompatibilities between the applications, we recommend building a suite of integration tests.

## How do I use design systems with MFE?

A MFE architecture can lead to disparate design choices and frameworks.
Design systems work to avoid these issues through unified design language and tokens that are consumed by all applications.

Building your own design system is a large undertaking.
We recommend looking first at existing solutions and libraries.
Next, we recommend using CSS variables and [lit-html](https://lit.dev/docs/libraries/standalone-templates/) for building shared web components that can be used across applications.

## What is Single-SPA?

[Single-spa](https://single-spa.js.org/) is a framework that solves many of the **technical** challenges of using Micro Frontend architecture, including defining shared modules and routing.

## MFE with Monorepos?

Both Micro Frontend architecture and monorepositories seek to solve both technical and organizational challenges, albeit, is sometimes drastically distinct ways.
A monorepo can increase code sharing and reuse, provide mobility and insight into applications throughout the organization, decrease build times, and eliminate dependency version incompatibilities.
Monorepo tooling also provides insight into the dependency graph of multiple applications as well as distributed computation cache and task execution.

## Should I use Micro Frontend Architecture?

The decision to use Micro Frontend architecture is _both_ a technical decision and an organizational decision.
As we have learned, using the MFE architecture is not without its own challenges and costs.

Finally, it is important to note that unwinding MFE architecture after a failed attempt can also be difficult and expensive.
As such, venture into the world of MFE architecture with an understanding of the tradeoffs, benefits, costs, and potentially, the challenge of unwinding the decision.

## How do I get started with a MFE?

There are many paths for getting started with Micro Frontend architecture.

I would recommend the following books:

- [Micro Frontends in Action by Michael Geers](https://www.manning.com/books/micro-frontends-in-action)
- [Building Micro-Frontends by Luca Messalira](https://www.buildingmicrofrontends.com/)

## Can you help me?

Absolutely!
LiveLoveApp has a track record of assisting organizations with designing and developing their Micro Frontend architecture.



20 Questions on Micro Frontend Architecture


LiveLoveApp was proud to represent [AG Grid](https://ag-grid.com/) at the [React Advanced Conference](https://reactadvanced.com/) in London!

We taught React developers how to get started with AG Grid in React.
We covered:

- Installing AG Grid with React
- Column Definition: Row Data, Row Sorting, Default Column Definition, and Filtering.
- Cell Rendering: Value Getter, Value Formatter, Cell Renderer Function, and Cell Renderer Component.
- Cell Editing: Provided Cell Editors, and Cell Editor Component.
- Persisting
- Styling AG Grid: Cell Styling, Row Styling, and Themes.

## Watch the Recording

You can watch the full recording of the workshop for free.
If you have any questions about AG Grid, let us know, and we'd be happy to help!

<div style="padding:75% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/772375402?h=95b27451fe&amp;badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture" allowfullscreen style="position:absolute;top:0;left:0;width:100%;height:100%;" title="react-advanced-ag-grid.mp4"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>



Implement AG Grid with Confidence

AG Grid in React


In this article you'll learn:

- What are flaky tests?
- How to identify tests that are flaky.
- How to reduce the flakiness of your tests.
- How to use SIFERS

## What Are Flaky Tests?

Flaky tests are defined as those tests that exhibit the following:

- Will fail less than 100% of the time
- With no changes to the configuration
- With no changes to the code under test

Flaky tests are, well, just part of life.
While we intend to write automated tests for our applications that are concise, fast, and accurately reflect the stability of the system under test, flaky tests arise.

<aside>
📣A study at Google revealed that 1 in 7 tests are flaky.
</aside>

You can [read more about flaky tests at Google and how they work to mitigate this issue](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html).

## Identify Flaky Tests

There are 4 primary sources of flaky tests:

1. Concurrency
2. Non-deterministic code under test
3. Third-party code
4. Infrastructure

Concurrency is a result of the parallelization of executing tests, most commonly in your CI/CD pipeline.
While executing tests in parallel decreases the time to execute the test suite, it is the most common source of flaky tests.
The reason for this is that the run order is not guaranteed with running tests in parallel.

Non-deterministic code under test can further cause flaky tests.
This means that when executing the code under test, given the same input, the code results in different outputs.
The most common cause of this is poor state management.
Another common cause of non-deterministic code is inconsistent server/backend state.

Let's look at an example of two tests.

```typescript
describe('List Books Page', () => {
  let book: BookModel;

  beforeEach(() => {
    book = {
      id: uuid.v4(),
      name: 'The Lord of the Rings',
      earnings: '100',
      description:
        'The Lord of the Rings is an epic high fantasy novel written by English author and scholar J. R. R. Tolkien.',
    };
    BooksApi.createBook(book);
    AuthApi.login('Admin', 'password');
  });

  afterEach(() => {
    BooksApi.deleteAllBooks();
  });

  it('should show a list all of the books', () => {
    cy.visit('/');
    cy.wait(1000);

    cy.getByTestId(`book-${book.id}`).should('contain', book.name);
  });
});

describe('Delete Book Page', () => {
  let book: BookModel;

  beforeEach(() => {
    book = {
      id: uuid.v4(),
      name: 'The Lord of the Rings',
      earnings: '100',
      description:
        'The Lord of the Rings is an epic high fantasy novel written by English author and scholar J. R. R. Tolkien.',
    };
    BooksApi.createBook(book);
    AuthApi.login('Admin', 'password');
  });

  afterEach(() => {
    BooksApi.deleteAllBooks();
  });

  it('should delete a book', () => {
    cy.visit(`/book/${book.id}`);
    cy.getByTestId(`book-${book.id}`).find('[data-test-id="bookDeleteButton"]').click();
    cy.wait(1000);

    cy.visit('/');
    cy.wait('@getBooks');
    cy.getByTestId(`book-${book.id}`).should('not.exist');
  });
});
```

Let's quickly review the code above:

- In the first test, we are asserting that the books page shows the list of books in our API.
- Ideally, we want to use our _real_ API to assert that our application is without regressions from end (client) to end (server).
- In the first test, we assert that the list of books displays as we expect.
- In the second test, we assert that a book is successfully deleted.
- In both tests, we are using the `beforeEach()` and `afterEach()` lifecycle methods to create a test book, login, and then remove all books in the API.

For those of us that use Cypress a lot, this test code should look _pretty_ familiar.

## Identify Flaky Cypress Tests

First, we highly recommend using the [Flaky Tests Management suite as part of the Cypress Dashboard](https://docs.cypress.io/guides/dashboard/flaky-test-management).
This tool in incredibly valuable to identify and isolate tests that are flaky.

Second, running tests in parallel can enable us to easily identify tests that are flaky:

```bash
cypress run --record --parallel
```

Third, we want to identify parts of our tests that setup and tear down the state of the application.
This code is most prone to causing flake.

Fourth, we want to look for timing issues in our tests.
The most common culprit is using `cy.wait()` with a specified number of milliseconds.

Finally, well, 🤷, you probably know the tests in your test suite that are already flaky because they occasionally fail you likely just force push or merge and hope for the best.

## SIFERS

Before we refactor our tests to reduce the flakiness let's learn about SIFERS.
SIFERS is an acronym for:

- Simple
- Injectable
- Functions
- Explicitly
- Returning
- State

SIFERS is a replacement for the Cypress test hooks:

- `beforeAll` and `beforeEach`
- `afterAll` and `afterEach`

Rather, our tests will contain a single `setup()` function that is responsible for explicitly returning the state of our system under test.
The `setup()` function is invoked within each test.

## Resolving Flaky Tests

Let's refactor our tests above to reduce the flakiness.

```typescript
function setup(options: { throwErrorWhenLoadingBooks?: boolean } = {}) {
  const book = {
    id: uuid.v4(),
    name: 'The Lord of the Rings',
    earnings: '100',
    description:
      'The Lord of the Rings is an epic high fantasy novel written by English author and scholar J. R. R. Tolkien.',
  };

  BooksApi.deleteAllBooks();
  BooksApi.createBook(book);

  if (options.throwErrorWhenLoadingBooks) {
    cy.intercept('GET', 'http://localhost:3000/books', {
      statusCode: 500,
      body: {
        error: 'Internal Server Error',
      },
    }).as('getBooks');
  } else {
    cy.intercept('GET', 'http://localhost:3000/books').as('getBooks');
  }

  cy.intercept('POST', 'http://localhost:3000/books').as('createBook');
  cy.intercept('PATCH', 'http://localhost:3000/books/*').as('updateBook');
  cy.intercept('DELETE', 'http://localhost:3000/books/*').as('deleteBook');

  AuthApi.login('Admin', 'password');

  return {
    book,
    teardown: () => {}
  };
}

describe('List Books Page', () => {
  it('should show a list all of the books', () => {
    const { book } = setup();

    cy.visit('/');
    cy.wait('@getBooks');

    BookListComponent.getBook(book.id).should('contain', book.name);
  });
});

describe('Delete Book Page', () => {
  it('should delete a book', () => {
    const { book } = setup();

    BookListComponent.clickDeleteButtonOnBook(book.id);
    cy.wait('@deleteBook');

    BooksApi.getBooks()
      .its('body')
      .should((books) => {
        const bookExists = books.some((b) => b.id === book.id);
        expect(bookExists).to.be.false;
      });
  });
});
```

Let's review our refactored tests:

- First, we defined a new `setup()` function that will perform all of the necessary setup.
- The `setup()` function returns an object containing the newly created `book`, as well as a (placeholder) `teardown()` function.
- We refactored the test to _not_ use the `afterEach()` lifecycle method. It's a best practice to avoid using this method, and, rather, explicitly clean up the state before each test. As such, we're removing all books in the API when invoking the `setup()` function.
- We removed all instances of `cy.wait(ms)` that we had hard-coded previously. Now, we're referencing aliases that we can use to explicitly wait for our API.
- We refactored the assertion for deleting a book to _not_ rely on the UI. Rather, we'll go directly to the API to assert that the book was indeed removed.

## Page Objects and Component Fixtures

Here at LiveLoveApp, we're also fans of using page objects and component fixtures for our Cypress tests.

In the previous example, you likely noticed that we referenced the `BookListComponent` harness.
Let's look at the code:

```typescript
export const getBook = (bookId: string) => cy.getByTestId(`book-${bookId}`);
export const getEditBookButton = (bookId: string) =>
  getBook(bookId).find('[data-test-id="bookEditButton"]');
export const getDeleteBookButton = (bookId: string) =>
  getBook(bookId).find('[data-test-id="bookDeleteButton"]');

export const clickEditButtonOnBook = (bookId: string) => {
  getEditBookButton(bookId).click();
};
export const clickDeleteButtonOnBook = (bookId: string) => {
  getDeleteBookButton(bookId).click();
};
```

The component harness above enables us to isolate interactions with the DOM into a single module.
We can then use this module and the exported functions to query the DOM as necessary.

## Key Takeaways

Flaky tests are part of life.
Yeah, I know that sounds like something your grandmother said to you.

To reduce the flakiness of your Cypress tests we recommend:

1. First, identify those tests that are flaky. Using the Cypress Dashboard makes this simple.
2. Second, identify parts of your tests that introduce flakiness through poor state management and timing issues.
3. Third, refactor your tests to use SIFERS.
4. Fourth, consider using component harnesses to isolate DOM interaction.


Learn Cypress in One Day

How to Reduce Flaky Cypress Tests


In this article you'll learn:

- How to sync data from NgRx Component Store into an Angular `FormControl` instance.
- How to sync data from an Angular `FormControl` instance into NgRx Component Store.
- Perhaps a bit about AG Grid.

## Demo App

<iframe class="stackblitz" src="https://stackblitz.com/edit/sync-component-store-form-control?embed=1&file=src/app/grid.component.ts&hideExplorer=1&view=editor"></iframe>

## The `GridComponent`

In this example, we'll use NgRx Component Store for managing the state of the `GridComponent`, a component that uses AG Grid to display a bunch of data.
We'll pretend that we have a bunch of Tesla Model S Plaid vehicles for sale (at random prices, because that's how you would optimally sell expensive cars).

Note:

- The component includes a `page` input that is an instance of a `FormControl`.
- We want to set the value of the `page` form control from the value of the `page` property that is stored in the Component Store, our source of truth.
- When a user changes the form control value, we want to set the `page` property value in the component store.

Here is the example `GridComponent`.

```typescript
@Component({
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [
    // omitted for brevity
  ],
  providers: [GridStore],
  template: `
    <div class="controls">
      <mat-form-field>
        <mat-label>Page</mat-label>
        <input matInput [formControl]="page" />
      </mat-form-field>
    </div>
    <ag-grid-angular
      class="ag-theme-material"
      (gridReady)="onGridReady($event)"
      [columnDefs]="columnDefs"
      [defaultColDef]="defaultColDef"
      [pagination]="true"
      [paginationPageSize]="100"
      [rowData]="rowData | async"
      [suppressPaginationPanel]="true"
    ></ag-grid-angular>
  `
})
export class GridComponent implements OnInit {
  columnDefs = [
    {
      headerName: 'Model',
      field: 'name',
      cellRenderer: NameCellRenderer,
      cellRendererParams: {
        click: ({ data }) => window.alert(`You clicked: ${data.name}`),
        document: this.document,
        isAbbreviated: () => true,
      } as NameCellRendererParams<RowData>,
    },
    { headerName: 'Price', field: 'price' },
    {
      headerName: 'Tax',
      valueGetter: multiplierValueGetter<RowData>('price', 'taxRate'),
      valueFormatter: decimalValueFormatter<RowData>(2),
    },
  ] as ColDef<RowData>[];

  defaultColDef = {
    sortable: true,
    filter: true,
  } as ColDef;

  page = new FormControl(0);

  rowData: Observable<RowData[]> = of(
    Array(9_000)
      .fill({})
      .map(() => ({
        id: uuid(),
        name: 'Model S Plaid',
        price: Math.round(Math.random() * (150_000 - 100_000) + 100_000),
        taxRate: 0.06,
      }))
  );

  constructor(
    @Inject(DOCUMENT) private readonly document: Document,
    private readonly gridStore: GridStore
  ) {}

  ngOnInit(): void {
    this.gridStore.syncPage(this.page);
  }

  onGridReady({ api }: GridReadyEvent) {
    this.gridStore.api = api;
  }
}
```

Let's review the code above:

- First, we are using an Angular standalone component (version 14+).
- Next, in the template we bind the input element to the `page` form control: `[formControl]="page"`.
- The component also includes the `<ag-grid-angular>` component for AG Grid.
- Next, we wire up the necessary `columnDefs`, `defaultColDef`, and `rowData` that is necessary for AG Grid.
- Note that the `page` property in our class is a new `FormControl` instance with the initial value set to `0`.
- Finally, note that we invoke the `syncPage()` method in the `ngOnInit()` lifecycle method providing a reference to the `page` FormControl instance.

## Component Store

With the `GridComponent` defined, the next step is to create a new `GridComponentStore`.

```typescript
interface GridState {
  page: number;
}

const initialState = {
  page: 1,
} as GridState;

@Injectable()
class GridStore extends ComponentStore<GridState> {
  /** The current pagination page. */
  page$ = this.select((s) => s.page);

  /** The AG Grid API. */
  api?: GridApi;

  /** Apply the pagination page to the AG Grid Grid instance. */
  private readonly applyPaginationPage = this.effect(
    (page: Observable<number>) => {
      return page.pipe(
        tapResponse(
          (page: number) => {
            if (this.api) {
              this.api.paginationGoToPage(page - 1);
            }
          },
          (error) => {
            console.error('Error applying pagination page', error);
          }
        )
      );
    }
  );

  /** Sync values between component state page prop and form control. */
  readonly syncPage = this.effect((formControl$: Observable<FormControl>) => {
    return formControl$.pipe(
      switchMap((formControl) => {
        const syncValuesFromControl$ = formControl.valueChanges.pipe(
          tapResponse(
            (value) => {
              this.setPage(value);
            },
            (error) => {
              console.error('Error syncing page', error);
            }
          )
        );

        const syncValuesToControl$ = this.page$.pipe(
          tap((page) => {
            formControl.setValue(page, { emitEvent: false });
          })
        );

        return merge(syncValuesFromControl$, syncValuesToControl$);
      })
    );
  });

  constructor() {
    super(initialState);
    this.applyPaginationPage(this.page$);
  }

  setPage(page: number): void {
    this.setState((state) => ({
      ...state,
      page,
    }));
  }
}
```

Let's review the code above:

- First, we declare the `GridState` interface and the `initialState` object that implements the interface.
- Our `GridComponentStore` extends the `ComponentStore` class, providing the `GridState` generic to inform the shape of our component store state.
- The `applyPaginationPage()` effect will apply the current `page` state property value to the AG Grid instance using the Grid API's `paginationGoToPage()` method.
- `syncPage` effect does the heavy lifting of synchronizing the component store state with the `FormControl` in the UI.
- The `syncPage()` effect is invoked with the `FormControl` instance.
- Next, the `syncPage()` effect uses the `tapResponse()` operator (from NgRx) invoke the `setPage()` method in the component store when the `valueChanges()` Observable emits the value from the form control.
- Also within the `tapResponse()` operator, the effect invokes the `setValue()` method on the `FormControl` instance to set the value of the form control when the `page` property value is updated in the component store.
- In the `constructor()` function we invoke the `applyPaginationPage()` effect.
- Finally, in the `setPage()` method we update the `page` property in the component store state.

## Conclusion

Synchronizing state from NgRx Component Store with Angular's forms API enables us to leverage component store for managing the (potentially complex) state of a component.
One approach is to use a side-effect that is provided with the `FormControl` instance.
You could also use a similar approach with Angular's `FormGroup` class.


Develop Angular Apps with Confidence

Component Store and FormControl Sync


For the past 15 years, I've spent much of my professional life building software.
A few years after graduating with an undergraduate degree in computer information systems I was the lead developer at a technology and business skills training company.

At the time, I thought I was more than deserving to lead the greenfield development of a new customer relationship management application that would drive much of the technology within the company, everything from managing clients, vendors, and trainers, to the scheduling of in-person and online training classes, and more.
The application would be, and perhaps still is, instrumental to the company.

Also at the time, I thought that consultants were all like the Bobs in Office Space - the folks in white shirts and ties whose sole purpose for their existence is to reduce costs by firing employees.
As Peter said to the consultants (Bob and Bob), "good luck with your layoffs, I hope the firings go really well."

Thankfully, I was encouraged to engage with a software consultant, [Pete Freitag from Foundeo](https://twitter.com/pfreitag), to assist with designing the software architecture and engineering of the application.
To this day, I'm grateful for working alongside and with Pete.
He was nothing like the Bobs.

## What is software consulting?

At worst, software consulting is like a marriage counselor.
We're hired as a third party with no bias for conflict resolution.
It can be ugly - I know.
I once arrived at a new client's office to be ushered into the coffee break room to be told about the conflict, how I was there to take one side, and to convince the grumpy old dude that the team needed to move into a new direction.

At best, software consulting is like a guide (think Yoda from Star Wars or Sophia Petrillo in Golden Girls) in the story of a hero.
We're hired because the hero has been called to action and needs someone to help lead them to success.

#
## What does a consultant do?

Many software consultants are simply staff augmentation that are brought on as short-term contractors to fill hiring gaps.
If you are looking for this service, there are dozens of firms that are large multi-national corporations that will put bodies in seats.

I believe that software consultants should:

- Understand the strategic goals and vision of the organization.
- Align stakeholders to build software solutions that serve to accomplish short-term goals while never losing sight of the organization's long-term vision.
- Be on the lookout for important decisions and potential issues that arise during the development process.
- Collaborate with the software architects, engineers, product owners, and all stakeholders.
- Communicate technical decisions to product and business owners in a manner that is clear, concise, and understandable.
- Mentors team members in order to improve their skills while encouraging them to tackle complex problems.
- Like a guide, a software consultant is there to assist and get into the nitty gritty when the going gets tough.

## Who needs a software consultant?

So, who needs a software consultant?

A hero who has been called to action and who recognizes their own limitations and need for an expert.

So, if you're looking to hire a software consultant then find an expert guide who will lead you and your team to success.


Who needs a software consultant


There is a tremendous gap in my experiences of being an application developer using TypeScript and being a library developer using TypeScript. As an application developer, I expect the libraries I consume to have strongly typed interfaces that work in natural ways with my TypeScript codebase. I rarely have to reach for complex type strategies, and instead, I heavily rely on type inference throughout my projects. Conversely, as a library maintainer, I’m regularly solving challenging type problems in the libraries I help maintain. I want to provide my library consumers with ergonomic APIs that fully rely on the dynamism of JavaScript while also providing type definitions that match the runtime constraints of my dynamic APIs.

The libraries I help maintain are all in the Angular ecosystem, where TypeScript is an absolute requirement. One of the libraries I have made significant contributions to is a Redux implementation for Angular called [NgRx Store](https://ngrx.io/). As a Redux implementation, it relies on users defining actions with a unique, string-based action type:

```tsx
interface Action<T extends string> {
	type: T;
}
```

Given that NgRx Store is a Redux implementation, it would be of no surprise to developers familiar with Redux or Vuex that NgRx Store users often complain about boilerplate or the amount of code required to successfully implement the Redux pattern. Throughout the years, we’ve leveraged new, advanced TypeScript features to continue to compress the amount of code required to write type-safe Redux implementations using NgRx.

We recently released a brand new version of NgRx, [NgRx Store v13.2](https://dev.to/ngrx/ngrx-action-group-creator-1deh), that introduces a new function for defining groups of actions:

```tsx
const AuthApiActions = createActionGroup({
	source: 'Auth API',
	events: {
    'Login Success': props<{ user: UserModel }>(),
		'Login Failure': props<{ error: AuthError }>(),
	},
});
```

The goal of `createActionGroup` is to reduce the amount of code required to write a group of actions with complete type safety. The above would be equivalent to doing something like this:

```tsx
interface LoginSuccessAction {
	type: '[Auth API] Login Success',
	user: UserModel;
}

interface LoginFailureAction {
	type: '[Auth API] Login Failure',
	error: AuthError;
}

export const AuthApiActions = {
	loginSuccess(user: UserModel): LoginSuccessAction {
		return {
			type: '[Auth API] Login Success',
			user,
		}
	},
	loginFailure(error: AuthError): LoginFailureAction {
		return {
			type: '[Auth API] Login Failure'
			error,
		}
	},
};
```

As you can see, the code reductions from leveraging `createActionGroup` are substantial. Let’s dive into the underlying TypeScript features that power `createActionGroup`:

```tsx
const AuthApiActions = createActionGroup({
	source: 'Auth API',
	events: {
    'Login Success': props<{ user: UserModel }>(),
		'Login Failure': props<{ error: AuthError }>(),
	},
});
```

The type of `AuthApiActions` becomes an object containing methods for instantiating actions for each of the configured events:

```tsx
this.store.dispatch(AuthApiActions.loginFailure({ error }));
```

What excites me the most about this new API is that it is **100% type-safe**. How do we get from `‘Login Success’` to `loginSuccess` on the function names though? TypeScript’s type literal type manipulation!

## Going from ‘Event Name’ to eventName with TypeScript

NgRx Store’s codebase contains a utility type alias that converts `'Event Name'` to `eventName`:

```tsx
export type ActionName<EventName extends string> = Uncapitalize<
  RemoveSpaces<Titlecase<Lowercase<Trim<EventName>>>>
>;
```

`ActionName` is doing all of the heavy lifting to convert event names at the type level by:

1. Starting with a string literal type (`EventName extends string`)
2. Trimming it
3. Making it lowercase
4. Titlecasing each segment of the string
5. Removing the spaces between words
6. Lowercasing the first letter

There is a lot going on here, so let’s break it down step-by-step!

### 1. String Literal Types

My experience with advanced types in TypeScript is that advanced types are extremely relevant when writing libraries and not as relevant in application code. One core concept of advanced typing in TypeScript that library authors often take heavy advantage of is string literal types. If you haven’t encountered them before, a string literal type is a string type but narrowed down to a specific string.

This will be a little easier to explain with examples. Let’s say we have a function that takes the name of a kind of bread and prints it to the console:

```tsx
function bakeBread(kindOfBread: string) {
  console.log(`🥖 Baking: ${kindOfBread}`);
}
```

There’s a problem with this function. I can pass this function any string and TypeScript won’t care:

```tsx
bakeBread('Pie');
```

String literal types let us specify a concrete subtype of string to enforce correctness. For example, if we wanted to limit the type of `kindOfBread` to `"Wheat"` we could do this:

```tsx
function bakeBread(kindOfBread: 'Wheat') {
	console.log(`🥖 Baking: ${kindOfBread}`;
}
```

Now if we try to pass in a string that is not a kind of bread we get a type error:

```tsx
bakeBread('Cake');
```

This produces the error:

```
Argument of type '"Cake"' is not assignable to parameter of type '"Wheat"'.(2345)
```

Obviously, there are more types of cake than just `"Wheat"` though. By creating a union type of string literals, we can constrain the type of `kindOfBread` to be the kinds of bread that our program is aware of:

```tsx
type KindsOfBread =
	| 'Wheat'
	| 'White'
	| 'Rye'
	| 'Pumperknickel'
	| 'Sourdough'
	| 'Banana';

function bakeBread(kindOfBread: KindsOfBread) {
	console.log(`🥖 Baking: ${kindOfBread}`;
}
```

Now we can call `bakeBread` with a variety of valid bread types without error:

```tsx
bakeBread('Rye');
bakeBread('Sourdough');
bakeBread('Banana');
```

And if we try to pass in a kind of bread that our program is not aware of we get a type error:

```tsx
bakeBread('Pound Cake');
```

This results in:

```
Argument of type '"Pound Cake"' is not assignable to parameter of type 'KindsOfBread'.(2345)
```

### 2. Trimming String Literal Types

NgRx’s `ActionName` operates on string literal types. From here, it starts applying advanced typing on string literal types to coerce a string literal type of `"Event Name"` into `"eventName"`.

The first step is to trim the string literal types, or, in other words, remove any surrounding whitespace. That way, if the developer passes in a string like `"   Event Name"` we don’t produce a function whose name is   `eventName`.

To strip the whitespace around a string literal type, we are going to have to use **conditional types**. A conditional type is a type that checks if a condition is true or not at the *type level* and can conditionally return a different type as a result of the condition.

Let’s take a look at example code!

```tsx
interface SliceOfBread {
	toast(): void;
}

interface SliceOfCake {
	frost(): void;
}

interface Bread {
	slice(): SliceOfBread;
}

interface Cake {
	slice(): SliceOfCake;
}
```

In this example, our program has interfaces for `Cake` and `Bread` both of which have a `slice()` method for producing `SliceOfCake` and `SliceOfBread` respectively.

Now let’s write a function called `slice` that takes an object of type `Cake` or `Bread` and returns the right result:

```tsx
function slice(cakeOrBread: Cake | Bread): ??? {
	return cakeOrBread.slice();
}
```

What type should we use for the return type of this function? Naively, we could use `SliceOfCake | SliceOfBread`:

```tsx
function slice(cakeOrBread: Cake | Bread): SliceOfCake | SliceOfBread {
	return cakeOrBread.slice();
}
```

This would require the consumer of `slice` to inspect the return type to know if it got back a slice of cake or a slice of bread. For example, if we tried to toast a slice of bread we get back when passing in pumperknickel:

```tsx
slice(pumperknickel).toast();
```

We get an error back from the TypeScript compiler:

```
Property 'toast' does not exist on type 'SliceOfCake | SliceOfBread'.
  Property 'toast' does not exist on type 'SliceOfCake'.(2339)
```

We could use function overloads to write `slice` in a way that works correctly:

```tsx
function slice(cake: Cake): SliceOfCake;
function slice(bread: Bread): SliceOfBread;
function slice(cakeOrBread: Cake | Bread): SliceOfCake | SliceOfBread {
	return cakeOrBread.slice();
}
```

This removes the type errors and all of the types are inferred correctly. However, we can shorten this by leveraging *conditional types*. Let’s write a type alias that takes in a type `T` and converts it into a `SliceOfCake` if `T` is `Cake` or `never` if `T` is not `Cake`:

```tsx
type Slice<T> = T extends Cake ? SliceOfCake : never;
```

As you can see, conditional types borrow their syntax from ternary expressions in JavaScipt. Now if we pass in `Cake` (or any subtype of `Cake`) to `Slice` we get back `SliceOfCake`:

```tsx
type Result = Slice<Cake> // Returns "SliceOfCake"
```

We can nest conditional expressions to make `Slice` aware of both `Bread` and `Cake`:

```tsx
type Slice<V> = V extends Cake
	? SliceOfCake
  : V extends Bread
		? SliceOfBread
		: never;
```

Now if we pass in `Bread` or `Cake` to `Slice` get back `SliceOfBread` or `SliceOfCake`, respectively:

```tsx
type Result1 = Slice<Bread> // "SliceOfBread"
type Result2 = Slice<Cake> // "SliceOfCake"
type Result3 = Slice<Cereal> // "never"
```

We can use conditional types in combination with string literal types to start producing functions with powerful type inference.

Let’s take our `KindsOfBread` type from earlier and compliment it with a `KindsOfCake` type to rewrite `Slice`, only this time `Slice` will take in a string literal type and produce either `SliceOfBread` if we pass in a kind of bread or `SliceOfCake` if we pass in a kind of cake:

```tsx
type KindsOfBread =
	| 'Wheat'
	| 'White'
	| 'Rye'
	| 'Pumperknickel'
	| 'Sourdough'
	| 'Banana';

type KindsOfCake =
	| 'Vanilla'
	| 'Chocolate'
	| 'Strawberry'
	| 'Pound'
	| 'Coffee';

type Slice<T> = T extends KindsOfBread
	? SliceOfBread
	: T extends KindsOfCake
		? SliceOfCake
		: never;
```

Let’s see what we get back now:

```tsx
type Result1 = Slice<'Banana'> // "SliceOfBread"
type Result2 = Slice<'Vanilla'> // "SliceOfCake"
type Result3 = Slice<'Tuna'> // "never"
```

This works great, but there’s still an *aesthetic* problem with the code. No one writes out “Vanilla” or “Banana” and expects you to know they are talking about cakes and breads. Aesthetically, this code would be more pleasing if we wrote it out like this:

```tsx
type Result1 = Slice<'Banana Bread'>;
type Result2 = Slice<'Vanilla Cake'>;
type Result3 = Slice<'Tuna Fish'>;
```

How can we extract the first part of the string literal types (the *kind*) to figure out what we are returning? In TypeScript, expressions passed to conditional types can use inference to *infer* new types.

To take advantage of this, let’s write out a type for the categories of foods our application supports:

```tsx
type Foods = 'Bread' | 'Cake' | 'Fish';
```

Now let’s write a type that extracts the *kind* modifier from a type literal like `"Tuna Fish"`:

```tsx
type ExtractKind<V> = V extends `${infer Kind} ${Foods}`
	? Kind
	: never;
```

What’s this doing? We are testing if the type parameter `V` is a string literal type in the format of `${Kind} ${Foods}`. For example, if we pass in `"Tuna Fish"` we will get back `"Tuna"` as the inferred type `Kind`. If we pass in just `"Tuna"` we will get back `never` since the string literal type `"Tuna"` is not in the format of `"Tuna Fish"`. Using this, we can now improve the aesthetics of `Slice`:

```tsx
type Slice<T, V = ExtractKind<T>> = V extends KindsOfBread
	? SliceOfBread
	: V extends KindsOfCake
		? SliceOfCake
		: never;

type Result1 = Slice<'Banana Bread'> // "SliceOfBread"
type Result2 = Slice<'Vanilla Cake'> // "SliceOfCake"
type Result3 = Slice<'Tuna Fish'> // "never"
```

NgRx’s `ActionName` needs to trim string literal types before doing any further conversion. It’s trimming strings by applying the exact same string inference trick that our `ExtractKind` utility is using by recursively inferring the string surrounded by whitespace:

```tsx
type Trim<T extends string> = T extends ` ${infer R}`
	? Trim<R>
	: T extends `${infer R} `
		? Trim<R>
		: T;
```

If you pass in `"  Banana Cake   "` to `Trim` you get back `"Banana Cake"`. Powerful TypeScript magic!

### 3. Lowercasing String Literal Types

With our bread sliced and our strings trimmed, we are ready to move on to the next bit of TypeScript behind `ActionName`: lowercasing string literal types!

How could we get from `"Banana Bread"` to `"banana bread"`? We could write out a very long and complex conditional type that maps each uppercase character into a lowercase character. Thankfully, however, TypeScript gives us a `Lowercase` utility type out-of-the-box. 🙂

```tsx
type Result = Lowercase<"Banana Bread"> // "banana bread"
```

Lowercasing? Easy! TypeScript ships with four utility types for manipulating string literal types:

- `Lowercase<"Banana Bread">` to produce `"banana bread"`
- `Uppercase<"Banana Bread">` to produce `"BANANA BREAD"`
- `Capitalize<"banana">` to produce `"Banana"`
- `Uncapitalize<"BANANA">` to produce `"bANANA"`

### 4. Titlecasing String Literal Types

TypeScript ships with utility types to lowercase, uppercase, capitalize, and uncapitalize string literal types. It does not include string literal types to do more advanced string manipulation.

For NgRx, we ultimately want to convert a string of words describing an event into a camelCased function name. To get there, we need to first convert the words into title case. In other words, go from `"banana bread"` to `"Banana Bread"`.

Before we build a titlecasing type utility, we need to explore *template literal types*. A template literal type is a supercharged string literal type that uses string interpolation syntax to create new string literal types. In our program, we have a `KindsOfBread` type that is a union of all of the kinds of breads our program is aware of. We could expand this into a type that includes the word `"Bread"` by using a template literal type:

```tsx
type Bread = `${KindsOfBread} Bread`;
```

This would be the same as writing:

```tsx
type Bread =
	| "Wheat Bread"
	| "White Bread"
	| "Rye Bread"
	| "Pumperknickel Bread"
	| "Sourdough Bread"
	| "Banana Bread";
```

Using template literal types, we can strengthen the clarity of our `Slice` type:

```tsx
type Bread = `${KindsOfBread} Bread`;
type Cake = `${KindsOfCake} Cake`;

type Slice<T extends Bread | Cake, V = ExtractKind<T>> = V extends KindsOfBread
	? SliceOfBread
	? V extends KindsOfCake
		? SliceOfCake
		: never;
```

Our types continue to infer correctly:

```tsx
type Result1 = Slice<'Banana Bread'> // SliceOfBread
type Result2 = Slice<'Coffee Cake'> // SliceOfCake
```

And now if we try to pass in a food item that is not bread or cake we get a better error:

```
Type '"Tuna Fish"' does not satisfy the constraint '"Wheat Bread" | "White Bread" | "Rye Bread" | "Pumperknickel Bread" | "Sourdough Bread" | "Banana Bread" | "Vanilla Cake" | "Chocolate Cake" | "Strawberry Cake" | "Pound Cake" | "Coffee Cake"'.
```

Template literal types let us *expand* unions of string literal types into new unions of string literals. We can build a titlecasing type utility using TypeScript’s built-in string literal type utilities, conditional types, and template literal types:

```tsx
type Titlecase<T extends string> = T extends `${infer First} ${infer Rest}`
	? `${Capitalize<First>} ${Titlecase<Rest>}`
	: Capitalize<T>;
```

Our `Titlecase` utility is doing the following:

1. Splitting up a string like `"banana nut bread"` into two types, `First` which is `"banana"` and `Rest` which is `"nut bread"`
2. It passes `First` to `Capitalize` and `Rest` to `Titlecase` for recursive processing
3. Once it gets to the very last word in the string literal type (in this case `"bread"`) it passes it to `Capitalize`

Now we can convert any string literal type into a titlecased string literal type:

```tsx
type Result = Titlecase<"banana nut bread"> // "Banana Nut Bread"
```

### 5. Removing Spaces Between Words

We can convert a string literal type that uses mixed casing with padded whitespace into a trimmed, titlecased string using the builtin `Lowercase` and our handwritten `Trim` and `Titlecase` type aliases:

```tsx
type R = Titlecase<Lowercase<Trim<"  banana NUT bread ">>> // "Banana Nut Bread"
```

We are still trying to get this to be in the form of `"bananaNutBread"` meaning we have to strip the spaces between words. Thankfully, we don’t need to learn any new tricks. We have everything we need with conditional types and template literal types:

```tsx
type RemoveSpaces<T extends string> = T extends `${infer First} ${infer Rest}`
	? `${First}${RemoveSpaces<Rest>}`
	: T;
```

This is very similar to `Titlecase`, only this time we are not doing any additional string manipulation. All this type utility does is take a string literal type in the form of `"Banana Nut Bread"` and convert it into `"BananaNutBread"`.

### 6. Lowercasing the First Letter

We are *so close* now to having the ability to go from `"  banana NUT bread "` to `"bananaNutBread"`. All we are missing is a way to uncapitalize the first letter. And if you recall, TypeScript ships with a type utility to do just that! Now we can write out our full `ActionName` utility using the built-in `Lowercase` and `Uncapitalize` in combination with our `Trim`, `Titlecase`, and `RemoveSpaces` type utilities:

```tsx
type ActionName<T extends string> =
	Uncapitalize<RemoveSpace<Titlecase<Lowercase<Trim<T>>>>>
```

🥳🎉🥖

## Conclusion

NgRx’s `createActionGroup` relies on advanced TypeScript typing to convert the names of events into strongly-typed function names. It is able to cast from `"Event Name"` to `"eventName"` through a combination of string literal types, conditional types, and template literal types. I want to give a huge shout out to [Marko Stanimirović](https://dev.to/markostanimirovic) for turning this concept into a fully functioning and well tested NgRx feature. Check out the full source code if you want to see the rest of the type magic going on under-the-hood of `createActionGroup`.


Implement NgRx with Confidence

Overcoming TypeScript Type Challenges for Library Authors


Simple Injectable Functions Explicitly Returning State (SIFERS) is a testing strategy that seeks to improve the developer experience for writing automated tests that are easier to write, maintain, and less flaky.

In this article, you'll learn:

- What are SIFERS
- How to unit test using SIFERS
- Why use SIFERS

# What is SIFERS?

SIFERS is an acronym for:

- Simple
- Injectable
- Functions
- Explicitly
- Returning
- State

SIFERS is a replacement for the Jasmine-like API hooks:

- `beforeAll` and `beforeEach`
- `afterAll` and `afterEach`

Rather, our tests will contain a single `setup()` function that is responsible for explicitly returning the state of our system under test.
The `setup()` function is invoked within each test.

Here is an example of a test using SIFERS.

```tsx
interface SetupOptions {
  throwErrorWhenLoading?: boolean
}

function setup(options: SetupOptions) {
  const book = {
    id: uuid.v4(),
    name: 'The Lord of the Rings',
    earnings: '100',
    description:
      'The Lord of the Rings is an epic high fantasy novel written by English author and scholar J. R. R. Tolkien.',
  };

  BooksApi.deleteAllBooks();
  BooksApi.createBook(book);

  AuthApi.login(process.env.REACT_API_USERNAME, process.env.REACT_API_PASSWORD);

  return { book };
}

test('should work', () => {
  // arrange
  const { book } = setup();

  // act

  //assert
});
```

Let's review this first example of a test using SIFERS.

- First, we may need some options to configure the state of our system under test. As such, we have defined a `SetupOptions` interface.
- The `setup()` function is a single (and simple) function that predictably creates and returns the state.
- First, we create a new `book` that our tests will use. We'll explicitly return this as part of the state object.
- Next, we use the API to delete all of the books and then create the single `book` that we defined.
- Next, we authenticate to the API.
- Finally, we return the state object.

# Demo

Check out a fully working demo.
You can even [run the tests using the Jest test runner on codesandbox](https://codesandbox.io/s/sifers-unit-testing-react-2nkth8?file=/src/__tests__/UserList.spec.tsx).

<iframe class="codesandbox" src="https://codesandbox.io/embed/sifers-unit-testing-react-2nkth8?fontsize=14&hidenavigation=1&module=%2Fsrc%2F__tests__%2FUserList.spec.tsx&theme=dark&view=editor"
sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"></iframe>

# The `UserList` Component

Before we dive into writing our tests using SIFERS, let's look at the `UserList` component that we are testing.

```tsx
type Props = {
  onToggleUser: (user: User) => void;
  selectedUserIds: number[];
  users: User[];
};

export default function UserList({
  onToggleUser,
  selectedUserIds,
  users,
}: Props) {
  return (
    <Box sx={{ width: '100%', maxWidth: 360, bgcolor: 'background.paper' }}>
      <List data-testid="user-list">
        {users.map((user) => (
          <ListItem
            key={user.id}
            secondaryAction={
              <Checkbox
                edge="end"
                onChange={() => {
                  onToggleUser(user);
                }}
                checked={selectedUserIds.indexOf(user.id) > -1}
              />
            }
            data-testid={`user-${user.id}`}
            disablePadding
          >
            <ListItemAvatar>
              <Avatar src={user.avatar} />
            </ListItemAvatar>
            <ListItemText primary={user.first_name} />
          </ListItem>
        ))}
      </List>
    </Box>
  );
}
```

The `UserList` component is responsible for:

- Rendering a list of users
- Setting the checkbox state of selected users
- Invoking a provided callback function when a user selection is toggled

# How to unit test with SIFERS

Let's create a SIFERS for testing the `UserList` component above.

```tsx
interface SetupOptions {
  onToggleUser?: (user: User) => void;
}

function setup(options?: SetupOptions) {
  const users = [
    {
      id: 1,
      first_name: 'Brian',
      last_name: 'Love',
      email: 'brian@liveloveapp.com',
      avatar: '',
    },
    {
      id: 2,
      first_name: 'Mike',
      last_name: 'Ryan',
      email: 'mike@liveloveapp.com',
      avatar: '',
    },
  ] as User[];
  const selectedUserIds = [users[0].id];

  render(
    <UserList
      onToggleUser={options?.onToggleUser ?? jest.fn()}
      selectedUserIds={selectedUserIds}
      users={users}
    />,
  );

  return {
    selectedUserIds,
    users,
  };
}
```

Let's review our `setup()` function:

- We declare a new `setup()` function at the top of our spec file.
- The `setup()` function optionally excepts a `SetupOptions` object. This enables our SIFERS to conditionally prepare the state or configure the system under test.
- We define an array of mock `users`
- We define an array of mock `selectedUserIds`
- Render the `UserList` component
- Return the state object.

Our `setup()` function:

- Performs the necessary setup for our tests
- Renders the `UserList` component
- Returns the state of our system.

Further, it may be necessary to return a `teardown()` function as a property in order to perform any required cleanup after each test.

## First Test

Now, let's look at our first test.

```tsx
test('should display a list of users', () => {
  // arrange
  const { users } = setup();
  const list = screen.getByTestId('user-list');

  // assert
  expect(list.children).toHaveLength(users.length);
  users.forEach((user) => {
    expect(screen.getByText(user.first_name)).toBeTruthy();
  });
});
```

Let's review the test above:

- First, we arrange the test by invoking the `setup()` function that explicitly returns the state, or in this case, the list of `users`. We then get the `List` element using the `data-testid` attribute.
- Then, we assert that the list of users matches the length of the `users` provided and that each user is displayed as we expect.

## Second Test

Next, let's look at a test that asserts that the `UserList` component selects the initially selected users.

```tsx
test('should select the initially selected users', () => {
  // arrange
  const { selectedUserIds } = setup();

  // assert
  selectedUserIds.forEach((id) => {
    const el = screen.getByTestId(`user-${id}`);
    const checkbox = getByRole(el, 'checkbox');
    expect(checkbox.getAttribute('checked')).toBe('');
  });
});
```

Let's review the test above:

- First, we arrange the test by invoking the `setup()` function that explicitly returns the state. In this case, we're only interested in the initial state of the selected users.
- Then, we assert that each user's checkbox is checked as we expect.

## Third Test

Finally, let's look at the final test that asserts that the `UserList` component should select a user.

```tsx
test('should select a user', () => {
  // arrange
  const onToggleUser = jest.fn();
  const { users } = setup({ onToggleUser });
  const el = screen.getByTestId(`user-${users[0].id}`);
  const checkbox = getByRole(el, 'checkbox');

  // act
  fireEvent.click(checkbox);

  // assert
  expect(onToggleUser).toHaveBeenCalled();
});
```

Let's review the test above:

- First, we arrange the test by creating a new mock function and assigning it to the `onToggleUser` constant. We then invoke the `setup()` function that explicitly returns the state providing the `SetupOptions` parameter with the mock function. We can now get the checkbox for the first user in the list.
- Next, we act upon the system by firing the click event on the `checkbox`.
- Then, we assert that the `onToggleUser` mock function has been called.

# Why use SIFERS?

At this point, you may be wondering, "but, why use SIFERS?"
In my experience, SIFERS provides 3 distinct advantages:

1. A clear expectation of the state of the system under each test.
2. Reduced clutter in `beforeEach` and `afterEach` functions.
3. Reduced opportunity for flaky tests due to stale state.

Next, we'll learn how to migrate an existing Jest test to use SIFERS.
In the process, we'll also identify each of these advantages.

# Migrating to SIFERS

First, let's look at an example of a test *without* using SIFERS.

```tsx
describe('Login Page Component', () => {
  const server = setupServer(
	  rest.get('/login', (req, res, ctx) => {
	    return res(ctx.json({
	      id: 123,
	      firstName: 'Brian',
	      lastName: 'Love'
	    }));
	  }),
	);

	beforeAll(() => server.listen());
	afterEach(() => server.resetHandlers());
	afterAll(() => server.close());

	test('should compile', () => {
	  const { asFragment } = render(<UserPage />);

	  expect(asFragment()).toMatchSnapshot();
	});

  test('should display an error', async () => {
	  server.use(
      rest.get('/greeting', (req, res, ctx) => {
        return res(ctx.status(500))
      }),
    );

	  render(<UserPage />);

		await waitFor(() => {
      expect(
        screen.queryByRole('error', {name: 'Uh oh. We ran into an error. Try again.'})
      ).toBeInTheDocument();
    });
  });
});
```

Now, let's look at an example of refactoring the test *to use SIFERS*:

```tsx
interface SetupOptions {
  throwErrorWhenLoadingUser?: boolean;
}

function setup(options: SetupOptions) {
  const server = setupServer(
	  rest.get('/login', (req, res, ctx) => {
      if (options?.throwErrorWhenLoadingUser) {
        return res(ctx.status(500));
      } else {
		    return res(ctx.json({
		      id: 123,
		      firstName: 'Brian',
		      lastName: 'Love'
		    }));
      }
	  }),
	);
  server.listen();

  const result = render(<UserPage />);

  return {
    asFragment: result.asFragment;
    teardown: async () => {
      server.close();
      return Promise.resolve();
    }
  };
}

test('should compile', () => {
  const { asFragment, teardown } = setup();

  expect(asFragment()).toMatchSnapshot();

  return teardown();
});

test('should display an error', async () => {
  const { teardown } = setup({ throwErrorWhenLoadingUser: true });

	await waitFor(() => {
    expect(
      screen.queryByRole('error', {name: 'Uh oh. We ran into an error. Try again.'})
    ).toBeInTheDocument();
  });

  return teardown();
});
```

Let's review the migrated test.

- First, we have a clear expectation of the state given that each test explicitly invokes the `setup()` function that returns the state. We also provide a `teardown()` callback function that is used to explicitly
- Second, we have reduced the clutter of having multiple lifecycle hooks in our test. We have a single, easy-to-read, and grok, `setup()` function.
- Third, we have reduced the flake of our tests. In the case of the “server error” test, we instruct our SIFERS to throw an error loading the user. If we compare this to the previous test, we had to override the behavior of our mock server and rely on resetting the handlers between each test.

# Conclusion

Here at LiveLoveApp, we are proponents of using SIFERS for writing unit tests, integration tests, and end-to-end tests.
Here are some suggestions:

- If you are experiencing flaky tests, consider refactoring to use SIFERS
- As a team and organization, consider using SIFERS for crafting future tests


Implement React with Confidence

Testing React Apps using SIFERS


Angular version 14 is a feature-packed release that brings new APIs, functionality, and a developer experience.
This includes one of the most requested feature improvements in Angular: typed forms.

In this article, you'll learn:

- How to migrate to the new strongly-typed forms API in Angular version 14
- Typed a `FormControl`
- Typed a `FormGroup`
- Typed a `FormArray`
- New `FormRecord`
- Mixing typed and untyped controls
- Non-nullable controls

Let's dive in!

## Typed Forms API FTW 🎉

If you have been using Angular's forms API, whether template-based or reactive forms, you likely have noticed that prior to Angular 14 much of the API surface had a *lot* of `any` types.

Angular (version 2, not AngularJS) was released in September of 2016 (after Flash died but before build tools took the world by storm). Not long after the release, developers started to note that the API was both not type-safe (or null-safe).
In fact, [the most upvoted and commented on issue](https://github.com/angular/angular/issues/13721) in the GitHub repository was created December of 2016 to report this problem.

Angular 14 introduces reactive form APIs that are both type-safe and null-safe. This is a big win for using reactive forms in Angular.
Unfortunately, the template-driven forms API is currently not strongly typed.

## Migrating to Angular 14

To get started, you need to update your project to use Angular 14 to take advantage of the new APIs.

```bash
ng update @angular/cli @angular/core
```

Once your project is updated, you'll not that instance of `FormControl` and `FormGroup` have been migrated to the untyped classes:

- `FormControl` is migrated to `UntypedFormControl`
- `FormGroup` is migrated to `UntypedFormGroup`

## Typed `FormControl`

In Angular 14, the `FormControl` class now has a TypeScript generic type of `TValue` whose default type assignment is `any`. What does this mean?

Prior to Angular 14, when accessing properties such as `value` the type was `any`, and when using the method `setValue`, it would accept `any` argument value.

Here are just a few of the class members that have been updated to use the `TValue` generic type:

- `setValue(value: TValue)`
- `patchValue(value: TValue)`
- `reset(formState: TValue)`
- `getRawValue(): TValue`
- `value: TValue`

This is a big win for preventing runtime exceptions and regressions due to type errors!

It's important to note that the `TValue` generic type is inferred by TypeScript when newing-up a new `FormControl` instance, so it's not necessary to specify the generic type.
Let's look at an example.

```tsx
const control = new FormControl('Mike');
```

Note, we did not specify the `TValue` generic type above.
Rather, the type is inferred by the `value` argument specified to constructor function when creating a new instance of the `FormControl` class.

## Typed `FormGroup`

The purpose of Angular's `FormGroup` is to group form controls logically in order to track their state (value, validity, etc.) together.
Angular 14 also introduces updated typings for the `FormGroup` API.

Let's look at an example.

```tsx
interface SignUpForm {
  name: string;
  email: string;
  subscribe?: string;
}

const signUpFormGroup = new FormGroup<SignUpForm>({
  name: new FormControl(''),
  email: new FormControl('')
});
```

Let's quickly review the code above:

- First, we define a new `SignUpForm` interface.
- The interface is *only necessary if we have optional form controls*. In this example, the `subscribe` control can be dynamically added and removed from the group.
- Next, we create a new `FormGroup` instance, and since we have an optional control, we specify the generic type to the `SignUpForm` interface.
- The `name` control's value is typed: `string | null`
- The `email` control's value is typed: `string | null`
- The `subscribe` control value is typed: `string | null | undefined`
- The `signUpFormGroup` value is typed: `Partial<{ name: string | null; email: string | null; subscribe: string | null | undefined }>`

You may have noticed that the control values can be `null` or, if optional, `undefined`.
This is because Angular's form APIs allow for null values.
For example, if we invoke the `reset()` method on a control, the value is not set to the original/seed value, rather, it is set to `null`.
We'll show how to override this behavior below.

It should also be noted that the `TValue` for each control is also inferred as we previously learned.

## Typed `FormArray`

Currently, TypeScript arrays are homogeneous.
This means that TypeScript expects that every item in an array is of the same type (including `any`).
For the sake of clarity, this is not to be confused with tuples which can have unambiguous types.

With that said, typed `FormArray` instances require that all controls are homogeneously typed.
If a `FormArray` requires heterogeneous types then the use of the `UntypedFormArray` is recommended.

In this example we'll create a new `FormArray` with an initial control.

```tsx
lineItems = new FormArray([
  new FormControl('')
]);
```

Because we have defined the `FormArray` to include a control whose `TValue` is a `string`, the type of the array is inferred as: `FormArray<AbstractControl<string, string>>`.
The compiler now expects that each item in the array is a control whose `TValue` is a `string`.

If we attempt to add a new control to the array whose `TValue` is *not* a string, the compiler will throw an exception indicating:

```tsx
lineItems.push(new FormControl(0));
```

The compiler exception indicates that there is an error.

```
Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.
```

This is a good thing! 😌

Ok, but what if our array of controls is initially empty?
In that case, we can specify the generic type of the controls:

```tsx
lineItems = new FormArray<AbstractControl<string>>([]);
```

In the example above, we use the `AbstractControl` type and specify the `TValue` to be of type `string` as we expect every control's value to be a `string`.

## New `FormRecord`

As we learned previously the `FormGroup` in Angular 14+ supports specifying a group of controls whose `TValue` types are known when creating the group, even when creating optional controls within the group.
However, what about a group of controls whose `TValue` is not known when creating the group.
To meet this use case, Angular 14 ships with a new `FormRecord` class.

Let's look at an example.

```tsx
formGroup = new FormRecord<AbstractControl<string>>({});
```

Now that we have created the group of controls using the `FormRecord` class, we can start to add (and/or remove) controls from the group.

```tsx
formGroup.addControl('street', new FormControl(''));
```

This code works as expected.
A new control is added to the group that meets the type definition.
However, what happens if we attempt to add a new control whose `TValue` is a `number`?

```tsx
this.formGroup.addControl('no', new FormControl(0));
```

Again, the compiler throws an exception indicating that we cannot add this control to the group due to the type constraints.

```
Argument of type 'FormControl<number>' is not assignable to parameter of type 'AbstractControl<string, string>'.
Types of property 'value' are incompatible.
Type 'number' is not assignable to type 'string'.
```

The `UntypedFormGroup` class supports the user requirements in the event that we need a group of controls whose values are heterogeneous.

## Mixed Types

We can declare mixed types of controls when working with a group of controls of heterogeneous types as long as we declare the controls when creating the group.
Further, we can use the `UntypedFormControl` class to declare a control whose `TValue` type is `any` (under the hood, this is a type whose generic type is preset to `any`).

Let's look at an example.

```tsx
export class AppComponent implements OnInit  {
  formGroup = new FormGroup({
    street: new FormControl(''),
    no: new FormControl(0),
    postalCode: new UntypedFormControl()
  });

  ngOnInit(): void {
    const street = this.formGroup.value.street;
    const no = this.formGroup.get('no').value;
    this.formGroup.get('postalCode').setValue(12345);
    this.formGroup.get('postalCode').setValue('ABC123');
  }
}
```

This all works as we expect.
We have a few controls, each with their own `TValue`, including the untyped control whose `TValue` is `any`.

## Non-nullable Controls

If you recall from earlier, we mentioned that resetting a form control state will set the value to `null`, not the initial/seed value as we might expect.
With non-nullable form controls, we can explicitly instruct the compiler that the value is reset to the initial value when invoking the `reset()` method.

Let's look at an example

```tsx
export class AppComponent implements OnInit {
  formGroup = new FormGroup({
    street: new FormControl('', { nonNullable: true })
  });

  ngOnInit(): void {
    this.formGroup.get('street').reset();
    const street = this.formGroup.value.street;
    console.log(street); // empty string, NOT null
  }
}
```

## Key Takeaways

There are a few key takeaways when using Angular 14's updated forms API:

- The `FormControl`, `FormGroup`, and `FormArray` signatures have been updated to support TypeScript generics.
- The `TValue` type is inferred where possible.
- `FormGroup` supports enumerated, homogeneous, and optional controls.
- `FormRecord` supports non-enumerated (dynamic) and homogenous controls.
- `UntypedFormControl` is a non strongly-typed `FormControl`. Or, in other words, the `TValue` type is preset to `any`.
- `UntypedFormGroup` is a non strongly-typed `FormGroup`.
- `FormArray` supports homogeneously typed controls.
- `UntypedFormArray` is a non strongly-typed `FormArray`.
- The `nonNullable` supports resetting a control state to the initial/seed value.
- Through strict types and template type checking, we can avoid runtime exceptions and reduce regressions.


Typed Forms in Angular


Reactive Extensions for JavaScript, or RxJS, is a library that has a twofold purpose.
It creates an `Observable` primitive that is either synchronous or asynchronous, and it includes a rich library of functions that can be used to create observables, transform, filter, join, and multicast observables, provides error handling, and more.
If that sounds like a lot - it is.
While RxJS is commonly used in Angular projects due to the fact that it is a peer dependency, it can be overlooked by software engineers building applications using React - or other frontend JavaScript frameworks for that matter.

Let me be clear - you do not *need* to use RxJS with React.
Promises, the `useEffect()` hook, and libraries such as Axios provide much of what a typical React application requires for asynchronicity and fetching data.
What RxJS with React *does* provide is the ability to write pure functions for event streams, effectively handle errors within a stream of data, and easily fetch data using the native Fetch and WebSocket APIs.

## Using `fromFetch()`

One advantage to using RxJS is the provided `fromFetch()` function that uses the native Fetch API with a cancellable `AbortController` signal.

Let's look at how you might use Axios for cancellation:

```tsx
import { get } from "axios";
import { Button } from "@mui/material";
import { useCallback, useEffect, useState } from "react";

export default function App() {
  const [user, setUser] = useState(null);
  const controller = new AbortController();

  useEffect(() => {
    const id = 2;
    get(`https://reqres.in/api/users/${id}`, {
      signal: controller.signal
    }).then((response) => {
      try {
        setUser(response.data.data);
      } catch (e) {
        console.error(`Error fetching user`);
      }
    });
  }, []);

  const handleOnCancel = useCallback(() => {
    controller.abort();
  }, []);

  return <Button onClick={handleOnCancel}>Cancel</Button>;
}
```

Let's quickly review the code above:

- First, we create a new instance of the `AbortController` class.
- Then, as a side effect, we use Axios' `get()` method to fetch a user from the API, providing the `AbortController`'s signal.
- Finally, in the `handleOnCancel()` callback function we invoke the `abort()` method on the `AbortController` instance to cancel the fetch request.

When using RxJS's `fromFetch()` function it is not necessary to wire up an `AbortController` signal.
Rather, we can cancel the fetch request by emitting either an error or completion notification.

```tsx
import { Button } from "@mui/material";
import { useCallback, useEffect, useState } from "react";
import { Subject } from "rxjs";
import { fromFetch } from "rxjs/fetch";
import { concatMap, takeUntil, tap } from "rxjs/operators";

export default function App() {
  const [user, setUser] = useState(null);
  const cancel$ = new Subject();

  useEffect(() => {
    const id = 2;
    const subscription = fromFetch(`https://reqres.in/api/users/${id}`)
      .pipe(
        tap((response) => {
          if (!response.ok) {
            throw new Error(response.statusText);
          }
        }),
        concatMap((response) => response.json()),
        tap(user => setUser(user)),
        takeUntil(cancel$)
      )
      .subscribe();
    return () => subscription.unsubscribe();
  }, []);

  const handleOnCancel = useCallback(() => {
    cancel$.next();
  }, []);

  return <Button onClick={handleOnCancel}>Cancel</Button>;
}
```

Let's review the code above:

- First, we use the `fromFetch()` function from RxJS to use the native Fetch API to request a user. This function returns an Observable, that when subscribed to, will initiate the request.
- Within the `pipe()` method, we first check if the response failed, and if so, we emit an error notification of the response's `statusText`.
- Next, using the `concatMap()` operator, we merge the next notification that is emitted from the Observable created internally from the Promise returned from the `.json()` method.
- Next, we use the `takeUntil()` operator to notify the outer Observable to complete, and abort the request if necessary, when the `cancel$` subject emits a next notification.
- Finally, within the `handleOnCancel()` callback function we invoke the `next()` notification on the `cancel$` Subject.

The key takeaways are:

- RxJS provides functions for interfacing with the native Fetch and WebSocket APIs using asynchronous Observables.
- The `fromFetch()` operator uses the `AbortController` internally and cancels the request if the Observable either completes or an error notification is emitted.

## How do I handle subscriptions?

It's best to clean up any subscriptions in our application when using RxJS.
While there are a few different approaches to ensuring an Observable that is subscribed to is completed (or unsubscribed from), one method is to invoke the `.unsubscribe()` method on the `Subscription` instance that is returned from the `subscribe()` function.
The teardown function returned from the `useEffect()` hook is our opportunity to perform any cleanup from the side effect.

## De-bouncing an input stream

In this example, we will manage a `search$` Observable stream that is denounced before we invoke the `onSearch()` callback function that is prop to the component.
While we could simply invoke the `onSearch()` callback function on each change to the input value, we want to avoid excessive network requests and repaints in the browser.

```tsx
import CancelIcon from "@mui/icons-material/Cancel";
import SearchIcon from "@mui/icons-material/Search";
import { IconButton } from "@mui/material";
import { useEffect, useMemo, useState } from "react";
import { BehaviorSubject } from "rxjs";
import { debounceTime, tap } from "rxjs/operators";

export default function Search(props) {
  const { onSearch } = props;
  const [search, setSearch] = useState("");
  const search$ = useMemo(() => new BehaviorSubject(""), []);

  useEffect(() => {
    search$.next(search);
  }, [search]);

  useEffect(() => {
    const subscription = search$
      .pipe(debounceTime(1000), tap(onSearch))
      .subscribe();
    return () => subscription.unsubscribe();
  }, []);

  return (
    <div>
      <input
        type="text"
        placeholder="Search"
        onChange={(event) => setSearch(event.target.value)}
        value={search}
      />
      {search$.value && (
        <IconButton onClick={() => setSearch("")}>
          <CancelIcon />
        </IconButton>
      )}
      {!search$.value && <SearchIcon />}
    </div>
  );
}
```

Let's review the code above:

- We have defined a `search$` BehaviorSubject with an initial seed value of an empty string.
- When the `search` state changes the `next()` method is invoked on the `search$` subject with the current value.
- We subscribe to the `search$` Observable stream and use the `debounceTime()` operator to debounce the value changes of the search `HTMLInputElement`. Within the `useEffect()` hook we return the teardown callback function that will invoke the `unsubscribe()` method.

This implementation highlights the use of RxJS to manage a stream of data within our application from the `onChange` event that is caused by the user interacting with a search input.

## The `useRxEffect()` Hook

Finally, I'd like to share a simple hook that LiveLoveApp uses for our React applications that depend on RxJS.
This hook makes it easy to not worry about subscriptions.

Let's take a look.

```tsx
import { useEffect } from 'react';
import { Observable } from 'rxjs';

export function useRxEffect(factory: () => Observable<any>, deps: any[]) {
  useEffect(() => {
    const subscription = factory().subscribe();
    return () => subscription.unsubscribe();
  }, deps);
}
```

The `useRxEffect()` hooks is intentionally similar to the `useEffect()` hook provided by React.
The hook expects the `factory` function to return an `Observable` that is unsubscribed when the effect teardown callback function is invoked.

Here is a snippet of using the `useRxEffect()` hook based on the previous code:

```tsx
import CancelIcon from "@mui/icons-material/Cancel";
import SearchIcon from "@mui/icons-material/Search";
import { IconButton } from "@mui/material";
import { useEffect, useMemo, useState } from "react";
import { BehaviorSubject } from "rxjs";
import { debounceTime, tap } from "rxjs/operators";

export default function Search(props) {
  const { onSearch } = props;
  const [search, setSearch] = useState("");
  const search$ = useMemo(() => new BehaviorSubject(""), []);

  useEffect(() => {
    search$.next(search);
  }, [search]);

  useRxEffect(() => {
    return search$.pipe(debounceTime(1000), tap(onSearch));
  }, []);

  return (
    <div>
      <input
        type="text"
        placeholder="Search"
        onChange={(event) => setSearch(event.target.value)}
        value={search}
      />
      {search$.value && (
        <IconButton onClick={() => setSearch("")}>
          <CancelIcon />
        </IconButton>
      )}
      {!search$.value && <SearchIcon />}
    </div>
  );
}
```

In the example code above, note that we have replaced the `useEffect()` hook with our custom `useRxEffect()` hook to manage the subscribing and unsubscribing from the `search$` Observable.

## Key Takeaways

If you're considering using RxJS in an existing or new React application, here are some key takeaways based on our experience:

1. RxJS is not necessary to build robust React application.
2. RxJS provides a functional programming implementation for building React applications with event streams, asynchronous data, and more.
3. RxJS implements the Observable primitive that is compatible to Promises (but without async/await).
4. RxJS has a rich library of functions for creating Observables, data transformation and multicasting, handling errors, and more.
5. You can think of RxJS as lodash for events.


React Hooks with RxJS and Axios


Here at LiveLoveApp, we're big fans of AG Grid - the best JavaScript grid in the world.
Why?
For two primary reasons: performance and extensibility.
Many of our clients use AG Grid to meet customer requirements for displaying tabular data.

In this article you'll learn:

- The AG Grid cell rendering pipeline
- How to leverage the new TypeScript generics provided by the AG Grid API (released in version 28)
- How to create a type-safe value getter to retrieve the value for a cell
- How to create a type-safe value formatted to format the value of a cell
- How to create a type-safe and performant cell renderer

## AG Grid Cell Rendering Pipeline

Without any customization and in the simplest form, each cell in AG Grid is rendered as a string based on the `field` specified in the provided row data.
However, often times an AG Grid implementation is not this simple.
This is where we can leverage [the pipeline for rendering cells](https://ag-grid.com/angular-data-grid/cell-content/):

1. `valueGetter()`
2. `valueFormatter()`
3. `cellRenderer()`

## Demo or it didn't happen

Here is a demo using React:

<iframe class="stackblitz" src="https://stackblitz.com/edit/ag-grid-cell-rendering-pipeline-react?embed=1&file=Grid.tsx&view=editor"></iframe>

And, here is a demo using Angular:

<iframe class="stackblitz" src="https://stackblitz.com/edit/ag-grid-cell-rendering-pipeline-angular?embed=1&file=src/app/grid.component.ts&view=editor"></iframe>

## Using the `valueGetter()` callback function

First, we can use a `valueGetter()` to fetch and/or mutate data in a cell using a provided callback function.
Let's take a quick look at an example.

In this example, the requirement is to create a value getter that is type-safe and uses the data provided to AG Grid to conditionally multiply a value within our data set.

```tsx
export const multiplierValueGetter =
  <T extends Record<TKey, number>,
    TKey extends string | number | symbol = string>(
    value: keyof T,
    multiplier: keyof T
  ) =>
    (params: ValueGetterParams<T>): number => {
      if (params.data === undefined) {
        return 0;
      }
      return Math.round(params.data[value] * params.data[multiplier] * 100) / 100;
    };
```

Let's review the code above:

- First, we declare the `multiplierValueGetter()` higher-order function. Using a higher-order function enables us to define the generic type `T` that extends a `Record` whose values are of type `number`. The higher-order function will return the value getter function that will be invoked by AG Grid with provided `ValueGetterParams<T>`.
- The `multiplierValueGetter()` has two required parameters, first, the `value` property, and second, the `multiplier` property, both of which are keys of the data provided to the grid that is of type `T`.
- Because we are using AG Grid v28 (or greater) we can specify the generic type of `T` for the `ValueGetterParams`. Prior to version 28, this generic type was not available, and as a result the type definition for the `data` property was `any`.
- Within the value getter function, if `data` is `undefined`, which can be the case when using infinite row model or row grouping in AG Grid, we return `0`.
- Finally, we can round the value after multiplying.

Here is an example implementation of our `multiplierValueGetter()` higher-order function.

```tsx
interface RowData {
  value: number;
  multiplier: number;
}

type Props = {
  rowData: RowData[]
}

export default function Grid ({ rowData }: Props) {
  const colDefs = [
    {
      colId: 'value',
      headerName: 'Value',
      field: 'value'
    },
    {
      colId: 'multiplied',
      headerName: 'Multiplied',
      valueGetter: multiplierValueGetter<RowData>('value', 'multiplier')
    }
  ] as ColDef<RowData>[];

  return (
    <AgGridReact
      className="ag-theme-material"
      columnDefs={colDefs}
      rowData={rowData}
    />
  );
}
```

## Using the `valueFormatter()` callback function

After the cell value is known, the optional `valueFormatter()` callback function enables us to format the value.
Let's look at an example of using the `valueFormatter()` callback function.

In this example, the requirement is to declare a reusable `decimalValueFormatter()` higher-order function that is type-safe and formats the specified data property to a specified length.

```tsx
export const decimalValueFormatter =
  <TData, TValue>(digits = 0) =>
    (params: ValueFormatterParams<TData, TValue>): string => {
      const formatter = new Intl.NumberFormat('en-US', {
        minimumFractionDigits: digits,
        maximumFractionDigits: digits,
      });
      if (params.value === undefined) {
        return formatter.format(0);
      }
      return formatter.format(Number(params.value));
  };
```

Let's review the code above:

- We have declared a `decimalValueFormatter()` higher-order function. This enables the implementation of this value formatter to specify two generic types: `TData` and `TValue`. The generic of `TData` represents the type for the `data` parameter, and the generic of `TValue` represents the type for the `value` parameter. Our higher-order function has an optional `digits` parameter that specifies the min and maximum number of digits for the decimal formatting. The higher-order function returns a function that is the value getter that is invoked by AG Grid with the `ValueGetterParams<TData, TValue>` object.
- In this value formatter, we are using the `Intl.NumberFormat` class to create a new formatter instance, specifying the minimum and maximum number of fraction digits.
- If the `data` is undefined, which can be the case when using infinite row model or row grouping in AG Grid, then we simply return 0.
- Otherwise, we return the formatted value.

Here is an example implementation of our `decimalValueFormatter()` higher-order function.

```tsx
interface RowData {
  value: number;
  multiplier: number;
}

type Props = {
  rowData: RowData[]
}

export default function DashboardGrid ({ rowData }: Props) {
  const colDefs = [
    {
      colId: 'value',
      headerName: 'Value',
      field: 'value'
    },
    {
      colId: 'multiplied',
      headerName: 'Multiplied',
      valueGetter: multiplierValueGetter<RowData>('value', 'multiplier'),
      valueFormatter: decimalValueFormatter<RowData, Pick<RowData, 'taxRate'>>(2)
    }
  ] as ColDef<RowData>[];

  return (
    <AgGridReact
      className="ag-theme-material"
      colDefs={colDefs}
      rowData={rowData}
    />
  );
}
```

## Using the `cellRenderer()` callback function

After the value for a cell is determined, and we have optionally formatted the value, we can use a cell renderer to have full control of how a cell is rendered in AG Grid.
By default, all values are rendered as a string.
In order to render a cell other than a string, we can use a custom cell renderer.

It's important to note that we should only use a cell renderer when necessary.
By default, the `textContent` of the cell HTML element is set to the (optionally formatted) value.
When we are using a cell renderer we are adding additional elements, event listeners, etc. to the DOM, all of which must be rendered for each cell in the grid.

Finally, we recommend that all cell renderers *strictly use* vanilla JS.
This will improve the paint performance of your application when scrolling the grid.
Why is that?
If you use a framework (e.g. React, Angular, or Vue) then as a result each time the cell needs to be rendered, AG Grid must switch the context to a React (or Angular or Vue) application context in order to render the resulting HTML to the DOM. This can be *very* expensive and is often not necessary.

<aside>
📣 Only use a cell renderer when necessary, limit the elements and event listeners to a minimum, and always use vanilla JS.
</aside>

To configure a cell renderer we can provide AG Grid with:

- A string that references a registered framework component
- A class that implements the `ICellRendererComp` interface
- A function that is invoked with the `ICellRendererParams` object

Let's look at an example. In this example, the user requirement is to display a column with a name that is optionally abbreviated, and, when a user clicks on the name, we want to open a dialog (which will not be the responsibility of AG Grid, but we need to notify the consumer that the user has clicked on the name).

First, let's define a new interface that describes the contract between the implementation and the cell renderer for the data that is expected.

```tsx
export interface NameCellRendererData {
  id: string;
  name: string;
}
```

Next, let's define another interface for the click event that will notify the implementation that the user has clicked on the name.

```tsx
export interface NameCellRendererClickEvent<T, E = Event> {
  event: E;
  data: T;
}
```

The `NameCellRendererClickEvent` describes the event handler object that will be provided to a `click` parameter that is implemented when using the cell renderer.
The interface has two generics:

1. First, we define a generic of `T` that will be provided for the row data.
2. Second, we have a generic of `E` that has a default assignment to the global `Event` interface. In the cell renderer we can set a type that is narrower.

Now, let's define another interface for the parameters that will be provided to the cell renderer.

```tsx
export interface NameCellRendererParams<T> {
  click: (event: NameCellRendererClickEvent<T>) => void;
  document: Document;
  isAbbreviated?: (params: ValueGetterParams<T>) => boolean;
}
```

A few things to note:

- First, we have declared the generic type of `T` in order to maintain type checking of the `params` object that is invoked for the `isAbbreviated` function.
- The `click` parameter will be a callback function that is invoked by the cell renderer. The callback function is invoked with an `event` parameter that is the `NameCellRendererClickEvent` interface.
- The `isAbbreviated` parameter is another callback function that enables the implementing grid to determine if a specific cell value should be abbreviated. We'll use the `ValueGetterParams` interface provided by AG Grid to keep our API ergonomic (in that we expect the developer to be aware of this existing interface, so it makes sense to use it).

Having described the API, let's look at the code for the cell renderer.

```tsx
type Params<T> = NameCellRendererParams<T> & ICellRendererParams<T, string>;

/**
 * AG Grid cell renderer for a user name.
 */
export class NameCellRenderer<T extends NameCellRendererData>
  implements ICellRendererComp<T>
{
  /** AG Grid API. */
  private api: GridApi | null = null;

  /** The button element. */
  private btnEl: HTMLButtonElement | null = null;

  /** Provided callback function that is invoked when the button is clicked. */
  private click:
    | ((event: NameCellRendererClickEvent<T, MouseEvent>) => void)
    | null = null;

  /** The column definition. */
  private colDef: ColDef;

  /** The AG Grid column. */
  private column: Column | null = null;

  /** AG Grid Column API. */
  private columnApi: ColumnApi;

  /** AG Grid context. */
  private context: any;

  /** The provided data. */
  private data: T | undefined;

  /** The global document. */
  private document: Document | null = null;

  /** Execution context bound function when the button is clicked. */
  private handleClick:
    | ((this: NameCellRenderer<T>, event: MouseEvent) => void)
    | null = null;

  /** Callback function to determinate if the name is abbreviated. */
  private isAbbreviated?: (params: ValueGetterParams<T>) => boolean;

  /** AG Grid row node. */
  private node: RowNode;

  /** The user name. */
  private value: = '';

  /** Value getter params to be provided. */
  get valueGetterParams(): ValueGetterParams<T> {
    return {
      api: this.api,
      colDef: this.colDef,
      column: this.column,
      columnApi: this.columnApi,
      context: this.context,
      data: this.data,
      getValue: (field?: string) =>
        this.data && field ? this.data[field] : this.value,
      node: this.node,
    };
  }

  init(params: Params<T>): void {
    this.updateParams(params);
    this.setGui();
  }

  destroy(): void {
    if (this.handleClick !== null && this.btnEl !== null) {
      this.btnEl.removeEventListener('click', this.handleClick);
    }
  }

  getGui(): HTMLElement {
    return this.btnEl!;
  }

  refresh(params: Params<T>): boolean {
    this.updateParams(params);
    const isAbbreviated = this.isAbbreviated?.(this.valueGetterParams) ?? false;
    this.value = this.transform(params.value, isAbbreviated);
    if (this.btnEl) {
      this.btnEl.innerHTML = this.value;
    }
    return true;
  }

  private setGui(): void {
    this.btnEl = this.document.createElement('button') as HTMLButtonElement;
    this.btnEl.classList.add('user-name-cell');
    this.handleClick = (event) => {
      if (this.click) {
        this.click({
          event,
          data: this.data,
        });
      }
    };
    const isAbbreviated = this.isAbbreviated?.(this.valueGetterParams) ?? false;
    this.btnEl.innerHTML = this.transform(this.value, isAbbreviated);
    this.btnEl.addEventListener('click', this.handleClick);
  }

  private updateParams(params: Params<T>): void {
    this.api = params.api;
    this.click = params.click;
    this.colDef = params.colDef;
    this.column = params.column;
    this.columnApi = params.columnApi;
    this.context = params.context;
    this.data = params.data;
    this.document = params.document;
    this.isAbbreviated = params.isAbbreviated;
    this.node = params.node;
    this.value = params.value;
  }

  private transform(value: string, isAbbreviated: boolean): string {
    if (isAbbreviated) {
      return value.replace(/^Model/i, '');
    }
    return value;
  }
}
```

Ok, phew. Let's review the code above.

- First, we define a new `Params` type that is a union of our `NameCellRendererParams` interface and the AG Grid provided `ICellRendererParams`. The generic type `T` is the provided type for the AG Grid row data, which we further provide to the `ICellRendererParams` interface. The second typescript generic is explicitly set to `string` as we expect that the `value` of the cell will always be a string.
- We export the `NameCellRenderer` class whose generic type `T` extends our previously defined `NameCellRendererData` interface. This ensures that we have type safety between the row data provided to AG Grid and our cell renderer. As required, our class implements the `ICellRendererComp` interface from AG Grid.
- We have a lot of properties that declared that will have references and values as necessary to pass to the `isAbbreviated` provided callback function.
- Note that the `click` property is the provided callback function from the implementation that is invoked when the user clicks on the name.
- Further, note that the `handleClick` property is an execution-bound function that we'll use within the cell renderer class for adding and removing the event listener.
- The `valueGetterParams` property accessor method returns a `ValueGetterParams<T>` object that is used by the implementation to determine if a name is abbreviated or not. We have decided to use this interface from AG Grid to keep a consistent API for our users (those developers using our cell renderer in their AG Grid implementations). This is important for API ergonomics.
- The `init()`, `getGui()`, `refresh()`, and `destroy()` methods are all implemented according to the `ICellRendererComp` interface from AG Grid. These methods provide hooks to initialize the cell renderer, provide an HTML element to be appended to the DOM by AG Grid when rendering a cell, and more hooks for when the data is refreshed and when the cell is destroyed. It's important that we use the `destroy()` lifecycle method to do any necessary cleanup, such as removing event listeners, to prevent memory leaks in our application.

Finally, here is an example implementation of the `NameCellRenderer`.

```tsx
interface RowData {
  id: string;
  name: string;
}

export default function DashboardGrid () {
	const colDefs = [
	  {
	    colId: 'name',
      field: 'name',
	    headerName: 'Name',
	    cellRenderer: NameCellRenderer,
      cellRendererParams: {
        click: ({ data }) => {
          window.alert(`You clicked: ${data.name}`)
        },
        document,
        isAbbreviated: ({ data }) => {
          return data.name.length > 20;
        },
      } as NameCellRendererParams<RowData>
	  }
	] as ColDef<RowData>[];

	return (
    <AgGridReact
      colDefs={colDefs}
      rowData={rowData}
    />
	);
}
```

## Summary

So In summary, we have learned how AG Grid renders a cell, and how we can provide data to a cell, optionally format a cell, and if necessary, customize the rendering of a cell.
The key takeaways are:

- Use the `valueGetter()` callback function to fetch and/or mutate the value of a cell.
- Use the `valueFormatter()` callback function to format a cell's value.
- If necessary, provide a cell renderer to customize the HTML of a cell.
- Cell renderers can also be interactive, invoke callback functions, and more.
- It's important to remove event listeners when a cell is destroyed.
- Design an API that is ergonomic.
- Create value getters, value formatters, and cell renderers that are type safe.


AG Grid Cell Rendering Pipeline with TypeScript

Creating strongly typed APIs in TypeScript relies on understanding advanced typing strategies. NgRx heavily depends on typing strategies such as string literal types, conditional types, and template literal types to create an API surface that encourages consumers to build strongly typed applications. Let's take a look at an example API in the NgRx codebase to see how NgRx leverages these advanced typing techniques.

[NgRx v13.2](https://dev.to/ngrx/ngrx-action-group-creator-1deh) introduces a new function for defining groups of actions:

```tsx
const AuthApiActions = createActionGroup({
  source: 'Auth API',
  events: {
    'Login Success': props<{ user: UserModel }>(),
    'Login Failure': props<{ error: AuthError }>(),
  },
});
```

The type of `AuthApiActions` becomes an object containing methods for instantiating actions for each of the configured events:

```tsx
this.store.dispatch(AuthApiActions.loginFailure({ error }));
```

What excites me the most about this new API is that it is **100% type-safe**. How do we get from `‘Login Success'` to `loginSuccess` on the function names though? TypeScript's type literal type manipulation!

## Going from ‘Event Name' to eventName with TypeScript

NgRx Store's codebase contains a utility type alias that converts `'Event Name'` to `eventName`:

```tsx
export type ActionName<EventName extends string> = Uncapitalize<
  RemoveSpaces<Titlecase<Lowercase<Trim<EventName>>>>
>;
```

`ActionName` is doing all of the heavy lifting to convert event names at the type level by:

1. Starting with a string literal type (`EventName extends string`)
2. Trimming it
3. Making it lowercase
4. Titlecasing each segment of the string
5. Removing the spaces between words
6. Lowercasing the first letter

There is a lot going on here, so let's break it down step-by-step!

### 1. String Literal Types

My experience with advanced types in TypeScript is that advanced types are extremely relevant when writing libraries and not as relevant in application code. One core concept of advanced typing in TypeScript that library authors often take heavy advantage of is string literal types. If you haven't encountered them before, a string literal type is a string type but narrowed down to a specific string.

This will be a little easier to explain with examples. Let's say we have a function that takes the name of a kind of bread and prints it to the console:

```tsx
function bakeBread(kindOfBread: string) {
  console.log(`🥖 Baking: ${kindOfBread}`);
}
```

There's a problem with this function. I can pass this function any string and TypeScript won't care:

```tsx
bakeBread('Pie');
```

String literal types let us specify a concrete subtype of string to enforce correctness. For example, if we wanted to limit the type of `kindOfBread` to `"Wheat"` we could do this:

```tsx
function bakeBread(kindOfBread: 'Wheat') {
  console.log(`🥖 Baking: ${kindOfBread}`;
}
```

Now if we try to pass in a string that is not a kind of bread we get a type error:

```tsx
bakeBread('Cake');
```

This produces the error:

```
Argument of type '"Cake"' is not assignable to parameter of type '"Wheat"'.(2345)
```

Obviously, there are more types of cake than just `"Wheat"` though. By creating a union type of string literals, we can constrain the type of `kindOfBread` to be the kinds of bread that our program is aware of:

```tsx
type KindsOfBread =
  | 'Wheat'
  | 'White'
  | 'Rye'
  | 'Pumperknickel'
  | 'Sourdough'
  | 'Banana';

function bakeBread(kindOfBread: KindsOfBread) {
  console.log(`🥖 Baking: ${kindOfBread}`;
}
```

Now we can call `bakeBread` with a variety of valid bread types without error:

```tsx
bakeBread('Rye');
bakeBread('Sourdough');
bakeBread('Banana');
```

And if we try to pass in a kind of bread that our program is not aware of we get a type error:

```tsx
bakeBread('Pound Cake');
```

This results in:

```
Argument of type '"Pound Cake"' is not assignable to parameter of type 'KindsOfBread'.(2345)
```

### 2. Trimming String Literal Types

NgRx's `ActionName` operates on string literal types. From here, it starts applying advanced typing on string literal types to coerce a string literal type of `"Event Name"` into `"eventName"`.

The first step is to trim the string literal types, or, in other words, remove any surrounding whitespace. That way, if the developer passes in a string like `"   Event Name"` we don't produce a function whose name is   `eventName`.

To strip the whitespace around a string literal type, we are going to have to use **conditional types**. A conditional type is a type that checks if a condition is true or not at the *type level* and can conditionally return a different type as a result of the condition.

Let's take a look at example code!

```tsx
interface SliceOfBread {
  toast(): void;
}

interface SliceOfCake {
  frost(): void;
}

interface Bread {
  slice(): SliceOfBread;
}

interface Cake {
  slice(): SliceOfCake;
}
```

In this example, our program has interfaces for `Cake` and `Bread` both of which have a `slice()` method for producing `SliceOfCake` and `SliceOfBread` respectively.

Now let's write a function called `slice` that takes an object of type `Cake` or `Bread` and returns the right result:

```tsx
function slice(cakeOrBread: Cake | Bread): ??? {
  return cakeOrBread.slice();
}
```

What type should we use for the return type of this function? Naively, we could use `SliceOfCake | SliceOfBread`:

```tsx
function slice(cakeOrBread: Cake | Bread): SliceOfCake | SliceOfBread {
  return cakeOrBread.slice();
}
```

This would require the consumer of `slice` to inspect the return type to know if it got back a slice of cake or a slice of bread. For example, if we tried to toast a slice of bread we get back when passing in pumperknickel:

```tsx
slice(pumperknickel).toast();
```

We get an error back from the TypeScript compiler:

```
Property 'toast' does not exist on type 'SliceOfCake | SliceOfBread'.
  Property 'toast' does not exist on type 'SliceOfCake'.(2339)
```

We could use function overloads to write `slice` in a way that works correctly:

```tsx
function slice(cake: Cake): SliceOfCake;
function slice(bread: Bread): SliceOfBread;
function slice(cakeOrBread: Cake | Bread): SliceOfCake | SliceOfBread {
  return cakeOrBread.slice();
}
```

This removes the type errors and all of the types are inferred correctly. However, we can shorten this by leveraging *conditional types*. Let's write a type alias that takes in a type `T` and converts it into a `SliceOfCake` if `T` is `Cake` or `never` if `T` is not `Cake`:

```tsx
type Slice<T> = T extends Cake ? SliceOfCake : never;
```

As you can see, conditional types borrow their syntax from ternary expressions in JavaScipt. Now if we pass in `Cake` (or any subtype of `Cake`) to `Slice` we get back `SliceOfCake`:

```tsx
type Result = Slice<Cake> // Returns "SliceOfCake"
```

We can nest conditional expressions to make `Slice` aware of both `Bread` and `Cake`:

```tsx
type Slice<V> = V extends Cake
  ? SliceOfCake
  : V extends Bread
    ? SliceOfBread
    : never;
```

Now if we pass in `Bread` or `Cake` to `Slice` get back `SliceOfBread` or `SliceOfCake`, respectively:

```tsx
type Result1 = Slice<Bread> // "SliceOfBread"
type Result2 = Slice<Cake> // "SliceOfCake"
type Result3 = Slice<Cereal> // "never"
```

We can use conditional types in combination with string literal types to start producing functions with powerful type inference.

Let's take our `KindsOfBread` type from earlier and compliment it with a `KindsOfCake` type to rewrite `Slice`, only this time `Slice` will take in a string literal type and produce either `SliceOfBread` if we pass in a kind of bread or `SliceOfCake` if we pass in a kind of cake:

```tsx
type KindsOfBread =
  | 'Wheat'
  | 'White'
  | 'Rye'
  | 'Pumperknickel'
  | 'Sourdough'
  | 'Banana';

type KindsOfCake =
  | 'Vanilla'
  | 'Chocolate'
  | 'Strawberry'
  | 'Pound'
  | 'Coffee';

type Slice<T> = T extends KindsOfBread
  ? SliceOfBread
  : T extends KindsOfCake
    ? SliceOfCake
    : never;
```

Let's see what we get back now:

```tsx
type Result1 = Slice<'Banana'> // "SliceOfBread"
type Result2 = Slice<'Vanilla'> // "SliceOfCake"
type Result3 = Slice<'Tuna'> // "never"
```

This works great, but there's still an *aesthetic* problem with the code. No one writes out “Vanilla” or “Banana” and expects you to know they are talking about cakes and breads. Aesthetically, this code would be more pleasing if we wrote it out like this:

```tsx
type Result1 = Slice<'Banana Bread'>;
type Result2 = Slice<'Vanilla Cake'>;
type Result3 = Slice<'Tuna Fish'>;
```

How can we extract the first part of the string literal types (the *kind*) to figure out what we are returning? In TypeScript, expressions passed to conditional types can use inference to *infer* new types.

To take advantage of this, let's write out a type for the categories of foods our application supports:

```tsx
type Foods = 'Bread' | 'Cake' | 'Fish';
```

Now let's write a type that extracts the *kind* modifier from a type literal like `"Tuna Fish"`:

```tsx
type ExtractKind<V> = V extends `${infer Kind} ${Foods}`
  ? Kind
  : never;
```

What's this doing? We are testing if the type parameter `V` is a string literal type in the format of `${Kind} ${Foods}`. For example, if we pass in `"Tuna Fish"` we will get back `"Tuna"` as the inferred type `Kind`. If we pass in just `"Tuna"` we will get back `never` since the string literal type `"Tuna"` is not in the format of `"Tuna Fish"`. Using this, we can now improve the aesthetics of `Slice`:

```tsx
type Slice<T, V = ExtractKind<T>> = V extends KindsOfBread
  ? SliceOfBread
  : V extends KindsOfCake
    ? SliceOfCake
    : never;

type Result1 = Slice<'Banana Bread'> // "SliceOfBread"
type Result2 = Slice<'Vanilla Cake'> // "SliceOfCake"
type Result3 = Slice<'Tuna Fish'> // "never"
```

NgRx's `ActionName` needs to trim string literal types before doing any further conversion. It's trimming strings by applying the exact same string inference trick that our `ExtractKind` utility is using by recursively inferring the string surrounded by whitespace:

```tsx
type Trim<T extends string> = T extends ` ${infer R}`
  ? Trim<R>
  : T extends `${infer R} `
    ? Trim<R>
    : T;
```

If you pass in `"  Banana Cake   "` to `Trim` you get back `"Banana Cake"`. Powerful TypeScript magic!

### 3. Lowercasing String Literal Types

With our bread sliced and our strings trimmed, we are ready to move on to the next bit of TypeScript behind `ActionName`: lowercasing string literal types!

How could we get from `"Banana Bread"` to `"banana bread"`? We could write out a very long and complex conditional type that maps each uppercase character into a lowercase character. Thankfully, however, TypeScript gives us a `Lowercase` utility type out-of-the-box. 🙂

```tsx
type Result = Lowercase<"Banana Bread"> // "banana bread"
```

Lowercasing? Easy! TypeScript ships with four utility types for manipulating string literal types:

* `Lowercase<"Banana Bread">` to produce `"banana bread"`
* `Uppercase<"Banana Bread">` to produce `"BANANA BREAD"`
* `Capitalize<"banana">` to produce `"Banana"`
* `Uncapitalize<"BANANA">` to produce `"bANANA"`

### 4. Titlecasing String Literal Types

TypeScript ships with utility types to lowercase, uppercase, capitalize, and uncapitalize string literal types. It does not include string literal types to do more advanced string manipulation.

For NgRx, we ultimately want to convert a string of words describing an event into a camelCased function name. To get there, we need to first convert the words into title case. In other words, go from `"banana bread"` to `"Banana Bread"`.

Before we build a titlecasing type utility, we need to explore *template literal types*. A template literal type is a supercharged string literal type that uses string interpolation syntax to create new string literal types. In our program, we have a `KindsOfBread` type that is a union of all of the kinds of breads our program is aware of. We could expand this into a type that includes the word `"Bread"` by using a template literal type:

```tsx
type Bread = `${KindsOfBread} Bread`;
```

This would be the same as writing:

```tsx
type Bread =
  | "Wheat Bread"
  | "White Bread"
  | "Rye Bread"
  | "Pumperknickel Bread"
  | "Sourdough Bread"
  | "Banana Bread";
```

Using template literal types, we can strengthen the clarity of our `Slice` type:

```tsx
type Bread = `${KindsOfBread} Bread`;
type Cake = `${KindsOfCake} Cake`;

type Slice<T extends Bread | Cake, V = ExtractKind<T>> = V extends KindsOfBread
  ? SliceOfBread
  ? V extends KindsOfCake
    ? SliceOfCake
    : never;
```

Our types continue to infer correctly:

```tsx
type Result1 = Slice<'Banana Bread'> // SliceOfBread
type Result2 = Slice<'Coffee Cake'> // SliceOfCake
```

And now if we try to pass in a food item that is not bread or cake we get a better error:

```
Type '"Tuna Fish"' does not satisfy the constraint '"Wheat Bread" | "White Bread" | "Rye Bread" | "Pumperknickel Bread" | "Sourdough Bread" | "Banana Bread" | "Vanilla Cake" | "Chocolate Cake" | "Strawberry Cake" | "Pound Cake" | "Coffee Cake"'.
```

Template literal types let us *expand* unions of string literal types into new unions of string literals. We can build a titlecasing type utility using TypeScript's built-in string literal type utilities, conditional types, and template literal types:

```tsx
type Titlecase<T extends string> = T extends `${infer First} ${infer Rest}`
  ? `${Capitalize<First>} ${Titlecase<Rest>}`
  : Capitalize<T>;
```

Our `Titlecase` utility is doing the following:

1. Splitting up a string like `"banana nut bread"` into two types, `First` which is `"banana"` and `Rest` which is `"nut bread"`
2. It passes `First` to `Capitalize` and `Rest` to `Titlecase` for recursive processing
3. Once it gets to the very last word in the string literal type (in this case `"bread"`) it passes it to `Capitalize`

Now we can convert any string literal type into a titlecased string literal type:

```tsx
type Result = Titlecase<"banana nut bread"> // "Banana Nut Bread"
```

### 5. Removing Spaces Between Words

We can convert a string literal type that uses mixed casing with padded whitespace into a trimmed, titlecased string using the builtin `Lowercase` and our handwritten `Trim` and `Titlecase` type aliases:

```tsx
type R = Titlecase<Lowercase<Trim<"  banana NUT bread ">>> // "Banana Nut Bread"
```

We are still trying to get this to be in the form of `"bananaNutBread"` meaning we have to strip the spaces between words. Thankfully, we don't need to learn any new tricks. We have everything we need with conditional types and template literal types:

```tsx
type RemoveSpaces<T extends string> = T extends `${infer First} ${infer Rest}`
  ? `${First}${RemoveSpaces<Rest>}`
  : T;
```

This is very similar to `Titlecase`, only this time we are not doing any additional string manipulation. All this type utility does is take a string literal type in the form of `"Banana Nut Bread"` and convert it into `"BananaNutBread"`.

### 6. Lowercasing the First Letter

We are *so close* now to having the ability to go from `"  banana NUT bread "` to `"bananaNutBread"`. All we are missing is a way to uncapitalize the first letter. And if you recall, TypeScript ships with a type utility to do just that! Now we can write out our full `ActionName` utility using the built-in `Lowercase` and `Uncapitalize` in combination with our `Trim`, `Titlecase`, and `RemoveSpaces` type utilities:

```tsx
type ActionName<T extends string> =
  Uncapitalize<RemoveSpace<Titlecase<Lowercase<Trim<T>>>>>
```

🥳🎉🥖

## Conclusion

NgRx's `createActionGroup` relies on advanced TypeScript typing to convert the names of events into strongly-typed function names. It is able to cast from `"Event Name"` to `"eventName"` through a combination of string literal types, conditional types, and template literal types. I want to give a huge shout out to [Marko Stanimirović](https://dev.to/markostanimirovic) for turning this concept into a fully functioning and well tested NgRx feature. Check out the full source code if you want to see the rest of the type magic going on under-the-hood of `createActionGroup`.


The TypeScript Gluten Behind NgRx createActionGroup

“The biggest men and women with the biggest ideas can be shot down by the smallest men and women with the smallest minds.

Think big anyway.”

The first step is thinking big. The second step is validation. So, how do we validate a digital product?

Let's answer this question with more questions - specifically, 20 more questions.

**What is product validation?**

Product validation is a systematic approach to measuring a concept with potential customers. This is the moment of truth - if you build it, will they come?

Product validation does not ensure the success of a business or product. Far from it. It only enables you to have insight into the validity of a concept. It's very likely that your concept is not valid, or, perhaps that your concept needs to pivot.

**Why is product validation necessary?**

Product validation is necessary to understand your target customer. Without product validation, a startup will waste time - and money.

**When should I validate?**

As early as you can. A drawing on a napkin will do - starting validation of a product does not require sophisticated wireframes, user requirements, high-fidelity mockups, or an impressive presentations. Presenting concepts that invoke meaningful feedback is the key.

**How often should I validate?**

Product validation should be an ongoing part of your design process that occurs after each iteration of a prototype.

At LiveLoveApp, we use Google's approach to design sprints that is a sequence of the following steps:

1. Understand
2. Define
3. Sketch
4. Decide
5. Prototype
6. Validate

There it is - after each iteration of a prototype when building a product we always want to validate the concept with real users.

**How do I find early adopters?**

Not everyone is your target customer. I mean, it's likely not your mum - she's likely going validate every concept. That's not very useful.

Early adopters are interested in providing influence on the development of an early technology in return for prestige, gaining a competitive advantage, or having lifetime access to a product. Early adopters may be within the reach of your network, but they are likely one or two degrees removed. Strategies such as pre-release, invite-only access, and possibly, lifetime access can lure early adopters to your product. An often overlooked but valuable strategy for getting the attention of your early adopters is through direct communication channels for your industry and your target customers such as online groups, forums, in-person meetups, and social media.

**What feedback is useful?**

Useful feedback should measure both the satisfaction of the user and the result of a user completing a specific task using your product.

Gathering holistic feedback that is vague and filled with general platitudes is not useful.

**What if they're wrong?**

All user feedback should be noted, but not all user feedback is valuable. If *all* of your user feedback is perceived as wrong, well then, you're probably wrong. It's important to dig deeper if you believe validation feedback is incorrect. This may be an opportunity to identify a pivot.

**How do I gather feedback?**

Gather feedback through a usability study and a cognitive walkthrough. A usability study focuses on the user interface of your product to determine if the prototype's user interface is acceptable or needs to be improved. A cognitive walkthrough evaluates the product's ability to solve a specific task. It's important to instruct users that you are not testing them, rather, you are testing the product. Finally, coach your users to think aloud.

**Should I use unmoderated tools?**

Moderated usability studies are those in which a person that is familiar with the product facilitates. Moderated usability studies and cognitive walk-throughs provide the most effective feedback for validation. On the other hand, Unmoderated usability studies do not have a person present for facilitation. Similarly, unmoderated tools can measure and monitor product use, providing insight into how a user discovers and interacts with your product without guidance.

**Do I need a prototype?**

Yes. However, your prototype does not necessarily need to be high fidelity. It is useful to gather feedback through low-fi prototypes before iterating toward high-fi prototypes.

**Do I need an MVP?**

No. A minimum viable product (MVP) should only be developed after prototype iteration. Only upon completion - and validation - of a prototype should an MVP be developed.

An MVP is yet another opportunity to validate and gather feedback. The breakeven of the MVP development expense should ideally equal the value of the feedback and validation.

**Do I need to generate revenue?**

The goal of the product is to generate revenue (though, not necessarily as may be the case for a public works product, government product, not-for-profit products, etc). However, the goal of product validation is not to generate revenue.

**Should I presell?**

Using a pre-selling strategy for product validation can provide both feedback and revenue. Preselling can also build community and urgency. The risk is that things can go wrong, so it's important to clearly communicate a refund policy.

**What about LTDs?**

A lifetime deal (LTD) provides an opportunity to attract early adopters with the ongoing expense of providing access to your product.

**Do I reveal my product roadmap?**

Revealing a product roadmap to early adopters provides validation of feature expansions. However, this could also provide existing competitors and would-be competitors with insight into your future features. It is important to consider the size of the moat around your product and to use legal non-disclosure agreements.

**Should I have a public beta?**

A public beta provides further validation of your product through metrics and can build community and urgency. A public beta can be used effectively in conjunction with preselling. The risks are negative reviews or early adopters vomiting.

**Should I raise capital from early adopters?**

Raising capital from early adopters enables you to retain equity before potential liquidation during capital raising events.

**How do I identify potential pivots?**

Product validation may reveal opportunities for a pivot of your product. When gathering feedback it is important to note problems that a user identifies with the user interface and how they use the product, but also problems that exist that the product does not solve. Those problems may be beyond the scope of your existing product. As with all products, validating a potential pivot is critical.

**What are the risks with product validation?**

The goal of product validation is to reduce risk, however, there are some risks associated with product validation. Preselling can introduce risk, flopped beta launches can be risky, and leaks to existing and would-be competitors could risk your (hopeful) blue ocean. Mitigate these risks through clear communication, striving for excellence, and legal containment.


Product validation is a key step when building innovating web products. We'll answer the top 20 questions that we have heard and have learned on product validation.

20 Questions on Product Validation

Angular version 14 is a feature-packed release that brings new APIs, functionality, and a developer experience. Angular version 14 is arguably the biggest release since version 9 when Angular's newest compilation and rendering engine (called Ivy) was released.

This article is the first in a series that will cover the key features and takeaways that I believe angular developers and engineering managers should know about Angular version 14. First, we'll start with the hottest new topic called standalone components. Then, we'll dive into typed forms, what they are, and what this means for you and your organization. We'll talk about version dependency updates, improvements to the Angular Language Service, new configurations to improve testing at runtime, and a small compiler update.

Let's dive into Angular's new developer preview of standalone components!

## Angular 14 Playground on Stackblitz

Real quick - before we dive into the details - I want to mention that I have an Angular 14 Playground for you on Stackblitz. Much of the example code below is referenced from this small project. Check it out and feel free to fork it!

<a href="https://stackblitz.com/edit/angular-v14-playground" class="btn">Full code on Stackblitz</a>

## **What is a standalone component?**

Prior to version 14, all components had to be declared as part of the `declarations` array in an `NgModule`. NgModules are a critical building piece to solve architectural challenges in Angular, namely importing other modules in your codebase or importing other modules that are published as part of a library (using the Angular Package Format. NgModules also provide a mechanism for wiring up and configuring dependency injection. We'll discuss both of these in more detail below.

Standalone components enable Angular developers to build applications *without* using the `NgModule` based approach.

<aside>
💡 In this article, I will often refer to Angular's `NgModule` simply as a “module”. This is in an effort to improve readability and is not meant to be confused with ECMAScript modules.

</aside>

The immediate question is **what about applications built today with modules?** Will modules be supported in the future?

The answer is a resounding yes. Angular applications, and libraries, that are built with modules will continue to be supported. Flatly stated, modules are not going anywhere.

Further, Angular's new standalone component architecture is fully compatible with the existing module-based architecture. You can continue to use modules where necessary and/or preferred, and you can start using standalone components alongside them. Based on your team and organization's architectural style, you can start adopting standalone components, or you can continue to build Angular applications using modules as you have been doing for the past 6 years. This continues on the Angular Team's promise to not leave anyone behind with breaking changes.

**Will standalone components replace modules as the de facto style?**

At the time of this writing, as Angular version 14 is just now being released, the answer to this question is unknown. This will likely depend on community adoption and tooling. Further, the current documentation, getting started journey, and style guide do not teach standalone components over the module-based approach.

**Why are standalone components in “developer preview”?**

Standalone components are being released in version 14 as a developer preview. This means that the LTS policy for the APIs does *not* apply to standalone components. This is a good thing! As the community adopts this new architectural pattern we will all learn from each other what works well, what is cumbersome, and, potentially, what are the edge cases where this architectural pattern breaks. This learning enables the framework to innovate at a fast pace. It also means that the APIs, while public, *may* change in future minor releases.

## Getting Started with standalone Components

To use standalone components, Angular has introduced a new `standalone` property in the component metadata. The property is `false` by default.

Here is a quick example of a standalone component:

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

@Component({
  standalone: true,
  selector: 'app-root',
  template: `
    <ng-content></ng-content>, {{ name }}.
  `,
  styles: [``],
})
export class NameComponent {
  @Input() name = '';
}
```

The code example above is like any Angular component except that we have set the `standalone` property to `true`. This instructs the compiler to treat this component as standalone, and further, this prevents us from including the component in the `declarations` array of a module.

Standalone components must declare their own dependencies including child standalone components. For example, to use the `<app-name>` component in another standalone component, I must import the component:

```typescript
@Component({
  selector: 'my-app',
  standalone: true,
  template: `
    <app-name [name]="name">Hi</app-name>
  `,
  imports: [CommonModule, NameComponent],
})
export class AppComponent {
  name = 'Brian Love';
}
```

In the code example above note that I have included our `NameComponent` in the `imports` array in the component metadata. This instructs the compiler that this component is a dependency of the `AppComponent`, which is also a standalone component.

## What about existing `NgModule` uses?

As stated previously, standalone components are fully compatible with existing codebases that use the `NgModule` pattern. If a standalone component uses a directive, component, or pipe that is exported from a module then we include the module in the `imports` array in the standalone component metadata to import the module. All publicly exported members of the module are now available for use in the standalone component.

Let's expand our current example application to use Angular Material. To do so, we'll need to import the necessary modules:

```typescript
@Component({
  selector: 'app-root',
  changeDetection: ChangeDetectionStrategy.OnPush,
  standalone: true,
  imports: [
    CommonModule,
    MatIconModule,
    MatListModule,
    MatSidenavModule,
    MatToolbarModule,
    RouterModule,
  ],
  template: `
    <mat-toolbar class="toolbar">
      <button mat-icon-button aria-label="Toggle menu" (click)="toggleMatSidenav()">
        <mat-icon>menu</mat-icon>
      </button>
      <span>Angular v14 Playground</span>
    </mat-toolbar>
    <mat-sidenav-container class="container">
      <mat-sidenav [(opened)]="matSidenavOpened" fixedTopGap="64" fixedInViewport>
        <mat-nav-list>
          <a mat-list-item routerLink="/">Home</a>
          <a mat-list-item routerLink="/about">About</a>
          <a mat-list-item href="https://liveloveapp.com" target="_blank">Learn More about LiveLoveApp</a>
        </mat-nav-list>
      </mat-sidenav>
      <mat-sidenav-content class="content">
        <main>
          <router-outlet></router-outlet>
        </main>
      </mat-sidenav-content>
    </mat-sidenav-container>
  `
})
export class AppComponent {
  matSidenavOpened = false;
  name = 'Brian Love';

  toggleMatSidenav(): void {
    this.matSidenavOpened = !this.matSidenavOpened;
  }
}
```

Let's review the code above:

- First, you'll note that the `AppComponent` has the `standalone` property set to `true` in the component metadata.
- I went ahead and update the change detection strategy, really just to test out how this works with standalone components, and thankfully, it works as expected.
- Note the `imports` array. I've imported the necessary material modules that I need for the component. I've also imported the `RouterModule` since my component's template includes the `<router-outlet>` custom element.
- For the sake of brevity, I skipped the styles (but you can check out the full [Angular v14 Playground demo on Stackblitz](https://stackblitz.com/edit/angular-v14-playground?file=src%2Fmain.ts)).

## Dependency Injection with standalone Components

Before we dive into a few of the important updates in Angular v14 to support standalone components, let me reiterate a few things.

First, the developer experience for module-based Angular applications using dependency injection has no breaking changes, and for the most part, has not changed. You can continue to use the injector, injection tokens, providers, and the `@Injectable()` decorator just as you have prior to Angular version 14.

Second, the dependency injector hierarchy is still *very* similar, with a few exceptions that we'll cover shortly.

Module type injectors are available using the `providers` array within the `NgModule` metadata as well as by using the `providedIn` decorator. Specifying the `root` value for the `providedIn` decorator will register the class at the root level that is available throughout your Angular application.

Here is a quick example of module type injectors that you are likely familiar with:

```typescript
// Module type injector using NgModule metadata
@NgModule({
  providers: [
    UserService,
    {
      provide: MAT_FORM_FIELD_DEFAULT_OPTIONS,
      useValue: { appearance: 'outline' },
    },
  ]
})
export class AppModule {}

// Module type injector using providedIn property
@Injectable({
  providedIn: 'root'
})
export class UserService {}
```

Node type injectors enable us to limit the provider scope through the use of the `providers` array for a directive or component. One common use case for limit provider scope is when you are using NgRx's Component Store:

```typescript
// node type injector
@Component({
  providers: [GridComponentStore]
})
export class GridComponent {}
```

Now, let's learn some of the new terminology and features introduced in Angular version 14.

First, Angular 14 adds a new `viewProviders` property to the `@Component()` metadata that enables us to further limit the provider scope to children of the existing component.

```typescript
// node type injector usin `viewProviders`
@Component({
  selector: 'app-name',
  template: `
    Hello, {{ user$ | async | greet }}
  `
})
export class NameComponent {
  user$ = this.userService.user$;

  constructor(private readonly userService: UserService) {}
}

@Component({
  viewProviders: [UserService],
  template: `
    <app-name></app-name>
  `
})
export class ToolbarComponent {}
```

Next, Angular 14 introduces a new term called “Environment Injectors”. Environment injectors cover the following scenarios:

- Module type injectors. As discussed above, this includes providers declared in a module as well as those that use the `providedIn` property for the `@Injectable()` metadata.
- Providers that are declared when the application is bootstrapped.
- Providers that are declared within the `providers` array for a `Route`.

Let's look at an example of declaring providers when an application is bootstrapped. Common use cases include providing the `BrowserAnimationsModule`, registering root-level routes using the `RouterModule.forRoot()` static method, and registering NgRx's global store using the `StoreModule.forRoot()` static method.

```typescript
bootstrapApplication(AppComponent, {
  providers: [
    importProvidersFrom([
      BrowserAnimationsModule,
      RouterModule.forRoot(routes)
    ]),
  ],
});
```

In the example above we are also introducing the `importProvidersFrom()` function. This utility function collects all providers from one or more sources that are either a standalone component or an `NgModule`.

Also introduced in Angular 14, we can declare an array of providers within a `Route` configuration that will create an Environment Injector at the route level. This enables the providers to be used within all components within the route, and all child routes.

```typescript
const routes = [
  {
    path: 'users',
    loadChildren: () =>
      import('./users.module').then(({ UsersModule }) => UsersModule),
    providers: [
			UserService,
	    {
	      provide: MAT_FORM_FIELD_DEFAULT_OPTIONS,
	      useValue: { appearance: 'outline' },
	    },
    ]
  },
  { path: '**', redirectTo: '' },
] as Routes;
```

Finally, Angular 14 introduces an additional injector type that is termed a “Standalone Injector”. No, the poor injector is not standing alone on the playground without any friends. The Standalone Injector is a child of the root environment injector and is responsible for isolating all providers for standalone components.

## Routing with standalone Components

Angular 14 introduces an expanded API for routing with standalone components, including a feature that enables us to *very* easily lazy load a standalone component. If you are familiar with the router's `loadChildren` configuration property that enables lazy-loading modules, then you will be very comfortable using the new `loadComponent` property.

```typescript
const routes = [
  {
    path: 'about',
    loadComponent: () =>
      import('./about.component').then(({ AboutComponent }) => AboutComponent),
  }
] as Routes;
```

In the code example above we are lazy loading a single standalone component at runtime with a simple configuration within the route.

Angular 14 also introduces a new feature that enables us to lazy load routes without the need to wrap them up in an `NgModule` using the `RouterModule.forChild()` static method.

```typescript
const routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/routes').then(({ routes }) => routes),
  }
] as Routes;
```

Note, that in order to use this new feature, all routes must use standalone components. This feature is not compatible with existing non-standalone components defined within the routes.

## Conclusion

In conclusion, Angular version 14 shipped a new developer preview of the standalone components API. This API enables Angular developers to build applications without the use of the `NgModule` architecture. The primary goals of standalone components are to simplify the API, improve developer ergonomics and velocity, and to enable future innovation in the Angular ecosystem. Standalone components do introduce some changes to the dependency injection system and the routing story. Finally, we should note that this new feature is backward compatible with existing Angular code that uses the `NgModule` architecture, and that this is a developer preview - meaning that the API is not finalized and could have breaking changes in the future.


Angular 14 releases a new standalone component feature. Learn how to get started with standalone components in Angular, plus, we'll dive into the new details of using standalone components with Angular's dependency injection and routing.

Angular 14 Standalone Components


Let's just cut straight to it. When you either walk in the door of your workplace, get in the truck on the job site, or sit in front of the computer to start your workday, you do not leave your life, struggles, and concerns behind. Unlike the popular Apple TV+ show Severence, a chip in your brain does not permanently separate your work life from your personal life.

The reality is that your health matters - physical and mental. Here in the United States, we place value on individualism and financial success fueled by meritocracy. Broadly speaking, western liberal democracies vary in their devotion to the health of the society. I would propose that devoting more time and resources and placing higher regard on health would improve our own lives and the lives of those we live among.

Mental health matters for many reasons. First, mental health is a critical component of a person's overall well-being and health care that is often overlooked. Further, those who suffer from mental illness are faced with stigma and discrimination that often results in negative economic impact (2017, Bharadwaj, et.al.). Second, studies have shown there are strong correlations between mental and physical health. Third, our mental health impacts the productivity of our work (2017, Bubonya, et.al). Finally, workplace conditions and environments are a “major modifiable risk factor” for mental illness (2014, LaMontagne).

## What Are We Doing to Support Mental Health?

Mental health matters at LiveLoveApp. We are currently focused on three key areas that we believe encourage mental health, acknowledges the value of each person, and provide security and safety.

> Establishing a culture of health and well-being at work creates an environment where employees feel valued, supported, and stimulated to perform at their best in work they find meaningful (2018, Goetzel, et.al.).

**First, we have established PTO policies that encourage healthy behavior**.

Many of our peers in the software industry have adopted “unlimited” PTO policies and entice potential new hires by offering an unlimited amount of time away from work. To be blunt, most unlimited PTO policies are flawed. First, unlimited PTO policies have been shown to reduce the _actual_ number of hours an employee takes as personal time. Second, these policies eliminate the employer's responsibility to provide compensation for unused PTO when an employee leaves. Third, employers often track an employee's “unlimited” PTO - making it not so unlimited by denying requests and demanding additional hours to make up for PTO.

When establishing the PTO policy at LiveLoveApp we sought to create one that is equitable for both the employer and employee. What is our PTO policy? I'm glad you asked. Here is our vacation policy verbatim from the employee handbook.

> LiveLoveApp offers 15 days of paid time off (PTO) plus 10 holidays every year: New Year's Day, Martin Luther King Jr. Day, Memorial Day, Juneteenth, Independence Day, Labor Day, Veteran's Day, Thanksgiving Day, Day After Thanksgiving Day, and Christmas Day. Your vacation time is prorated based on your start date during your first year at LiveLoveApp. Your vacation time expires every year on December 31. If you are terminated or resign from LiveLoveApp with unused vacation days, you will not be paid the monetary equivalent for those unused days.

Please note that this policy does not describe our policy on sick time, personal leave, family leave, and bereavement leave. We have generous policies for all of these situations that align with our desires for employees, no matter their position or compensation.

I also want to be critical of ourselves in that we currently do not pay the monetary equivalent for unused vacation days. That might sound a bit hypocritical given my critique of peers above. This decision is not based on our fiduciary responsibility to the company. Rather, this decision is deliberate in an effort to _strongly_ encourage employees to use _all_ of their vacation time _every_ year. Decoupling the monetary value promotes all of us to get away from work.

I also want to briefly mention our summer policy. I don't know about you, but I love getting into the outdoors during the summer months. I also like getting out in the powder during the winter months, but we'll leave that for another time. Here is our summer policy:

> We work 4-day work weeks from July 1 through August 31 every year. An employee who has just been hired may have to complete a training program per their team lead to be eligible. When a holiday occurs during summer hours, you can take the holiday off _or_ your normal summer day off. Any additional days off would count as vacation days.

What does this mean? This equates to an additional 8 vacation days for PTO per employee which is _mandatory_. While I may want to spend one of these days out on a camping trip or hiking, you are more than welcome to spend the day doing chores, beating a video game, or playing with the kids in the backyard. Whatever you choose to do is your choice. The goal is to encourage healthy behaviors for all of our employees.

**Second, we have established compensation policies that acknowledge the value of each person.**

We strongly affirm that direct compensation for a position should be equitable and transparently communicated regardless of gender, gender identity and expression, age, sexual orientation, neurodivergence, disability, physical appearance, body size, race, ethnicity, or religion (or lack thereof).

How we do this is _actually_ quite simple. Again, let me reference our employee handbook directly.

> LiveLoveApp pays at median United States salary levels for your position regardless of your geographic location as determined by glassdoor.com. The glassdoor salary data is reviewed once per year at the end of November. If the US median salary for your position has increased, we'll increase pay on January 1st of the next year. We never decrease pay even if the US median salary has dropped. Everyone in the same role at the same level is paid the same at LiveLoveApp. When you get a promotion, that is you move from one level to another, you'll get a corresponding pay raise effective on your next pay cycle.

This means that you don't have to be worried over bargaining for a raise, be stressed out about your wage being diminished due to economic downturns, or wonder if your colleague is making more or less than you for doing the same work in the same position. This also means that we have eliminated wage discrimination entirely.

**Third, we have established (and continue to mature) a culture of personal growth that fosters security.**

LiveLoveApp has an established cadence of bi-monthly 1:1 meetings and quarterly check-ins.

Our 1-on-1 meetings are _not_ performance reviews, rather, this provides an opportunity for us to talk about:

- daily work content and load,
- overall satisfaction,
- relationships with the team, clients, vendors, etc., and
- removing blockers to personal growth.

A quarterly check-in allows us to review quarterly MBOs and ensure your satisfaction with your work. These quarterly meetings are meant to be an opportunity for you and your manager to gauge both how well you are accomplishing your MBOs as well as your overall satisfaction.

Finally, advancing your career at LiveLoveApp never requires you to change careers or to exchange your craft for upward momentum. LiveLoveApp is dedicated to growing alongside your career. We also acknowledge that your career path may include leaving LiveLoveApp to pursue another opportunity. Given that, we do expect you to make a lifetime commitment while also being committed to LiveLoveApp during your tenure. We want to grow with and alongside you.

## Conclusion

In conclusion, we believe that raising awareness, reducing stigma, and supporting a workplace that provides an environment that encourages mental health, will improve lives, and ultimately enables us to build better products for our customers.

We acknowledge the large gap that exists between our current solutions and capabilities, and the desired outcomes to wholly support and encourage the well-being of our employees, those we work with, and those we work for. We seek to listen, learn, and act in a manner that further reduces this gap.

### Works Cited

- LaMontagne, Anthony D., et al. "Workplace mental health: developing an integrated intervention approach." _BMC psychiatry_
  14.1 (2014): 1-11.
- Bharadwaj, Prashant, Mallesh M. Pai, and Agne Suziedelyte. "Mental health stigma." _Economics Letters_
  159 (2017): 57-60.
- Bubonya, Melisa, Deborah A. Cobb-Clark, and Mark Wooden. "Mental health and productivity at work: Does what you do matter?." _Labour economics_
  46 (2017): 150-165.
- Goetzel, Ron Z., et al. "Mental health in the workplace: A call to
  action proceedings from the mental health in the workplace: Public
  health summit." _Journal of occupational and environmental medicine_
  60.4 (2018): 322.


Mental health is a priority at LiveLoveApp. We affirm the value of our people through thoughtful policies and culture. Learn more about our culture!

Where Mental Health Matters


A golden age is a period of time in which there is (general) peace, prosperity, and happiness.
Is it possible that we are currently in a golden age of web 2.0?

In this article, I'd like to explore this concept a bit further.
I'll use the template of the popular Twitter meme: "How it started vs How it's going".
I'll even take it a step further and look at how this golden age may be coming to an end.

## How it started

From a user perspective, version 2.0 of the internet was marked by the enablement of the user to create and share content.
Previously, it was limited to us nerdy "web developers" who could create and share content on the internet.
I believe that this enablement led to the current explosion of content, both incredible value but also ridiculously worthless.

From a software engineer's perspective, web 2.0 of the internet was marked by terms like "ajax" and "rich web applications".
I can recall attending Adobe Max and Google I/O during this time, filled with excitement and being encouraged by the explosive growth of the internet as a platform for building web applications.
I'll never forget attending my first ajax conference.
It was in New York City, and the ballroom was packed and the enthusiasm was oozing out of the speakers and the audience alike.
We were embarking on a new journey of building web applications with rich user interfaces powered by the browser.
Finally, all those hours spent studying, struggling, and learning the "script-kiddy" language of JavaScript would pay off!

However, this excitement wore off pretty quickly as we battled cross-browser incompatibilities.
Thankfully, projects like prototype.js and jQuery came to our rescue.
Using a few libraries such as these seemed to smooth the rough edges and provide some peace and security when building web applications that would be consumed by large audiences.

## How it's going

Today, I believe we are living in the golden age of web 2.0.
The ECMAScript language has been propelled further than ever before, with (mostly) rapid widespread adoption by browser vendors.
With compilers, transpilers, and polyfills, the code that frontend UI engineers craft today is elegant and efficient.
The V8 engine parses, compiles, and executes our code faster than ever before.
The blink engine efficiently leverages the GPU to render pixels to the screen at 60 frames per second.
This all has led to a time of prosperity and general happiness.

What about the aspect of peace?
I'd say that, while there are those out there that want to gain popularity through waging war against a framework that they do not personally identify with, there is general peace and health in and amongst the many communities that exist within the larger ecosystem of the web.

I would propose we have achieved a level of peace, prosperity, and happiness as software engineers building and maintaining web applications, and as such, we are living during the golden age of web 2.0.
But, like all golden ages, and version numbers, the march must go forth, and we will eventually mark a period of time in which the major version release number of the internet is bumped to 3.0.

## How it ends

So, where do we go from here?

Just as web 2.0 was marked by terms, I think we will note a shift in terminology in the next age of the internet.
What exactly will these terms be?
I can't say with certainty, but I could hypothesize.

At the time of this writing, and we'll see how well this ages, I would include some of the following terms in web 3.0: "blockchain", "machine learning", and "5G".
I believe we will continue to identify trends such as the widespread dispersement of those that are building web applications through tooling that enables _everyone_ to build.
I also believe that we will continue to identify trends around decentralization through technologies such as the blockchain.
I hope that we will also identify trends in increasing privacy and data ownership.

So, how does web 2.0 end?

Honestly, I don't know.
What do you think?


Are we currently in the golden age of web 2.0? What will the future of the web look like? We don't know, but have some ideas we want to share with you.

The Golden Age of Web 2.0


At LiveLoveApp we focus on providing technology leadership to startups.
A startup requires rapid innovation with low-cost solutions to enable validation and potential pivots.
We reach for a lot of tools, including no-code and low-code tools, as well as serverless and frontend frameworks to make this happen.
When it comes to a frontend framework or any tool, we don't choose based on our personal favorites.
We choose a tool that drives us to the solution that the customer needs.

## Choosing Lit

Our client had the following requirements:

- As a user, I can choose between a graph or table view of a metric.
- As a user, I can choose from a list of metrics to display.
- Easily embed the display of metrics into a WordPress page.
- Responsive design using modern tooling to enable rapid innovation.

When examining the landscape of potential tooling we identified [Lit](https://lit.dev/) as meeting the needs of the project.
Lit provides a simple and _very_ lightweight approach to building reusable web components.
Further, we can leverage TypeScript and rollup for quality and building for a production environment.

Some alternatives that we considered had too heavy of a footprint or required building a custom pipeline to build for production.

## The value of Lit

Here are the key values propositions of using Lit for the project:

- The biggest value of using Lit for the project is the footprint of around 5kb.
This is hard to beat when compared to other options that are currently available.
- Further, Lit's documentation was easy to use and understand.
- The declarative template of Lit felt familiar coming from building applications using React, Angular, and Vue.
- Lit does the job of building web components well and doesn't try to do anything else.
This, in particular, was a perfect fit for building a reusable web component that will be leveraged by WordPress shortcodes.
- Finally, Lit has reactive properties making it easy to manage state and react to state changes in the component.

## The cost of Lit

Some hurdles and costs to using Lit for the project included:

- We would have preferred to use snowpack with esbuild but ended up using Rollup because of the documentation.
It would be nice if Lit updated their production build documentation to include snowpack and esbuild.
- While Lit uses shadow DOM and scoped styling, it would be nice to use Scss for writing the styles of the component.
The inline styles for the component grew pretty quickly, and using an external stylesheet is not recommended with Lit.

## Conclusion

Building at the speed and cost of a startup can be challenging.
Choosing the right tools and approach is key to the success of a project, and ultimately, of a company.
We determined that Lit was the best tool for rapidly building a web component that is highly reusable and can be composed with WordPress shortcodes for embedding the display of metrics for our client.


Case study of how LiveLoveApp uses Lit to accelerate innovation.

Rapid Innovation with Lit


For the past several months we have been working towards creating a vision for LiveLoveApp and a brand identity that reflects that.
Our process was likely not entirely unique, but we are thrilled with the result, and want to share with you the story of Bryan the Lion.
Ok, let's all jump in our time machines and go back a few months.

## A Trip to Rocket City

While I've been busy the past few years providing software consulting services to several companies I've also known that this little thing called LiveLoveApp is limited in scale by myself.
I've chatted with a few people I've worked with in the past, admire, and trust, and have been looking for someone to work with.
I understand that quitting a full-time job that provides a nice salary, health insurance benefits, personal time off, stability, and perhaps even a few bonuses here and there, is not for everyone.
I also understand that joining a company of one is risky.
But, I also appreciate that risk is often tightly correlated with reward.
With that said, I needed a business partner that understood this risk and reward, and was willing to go for an adventure.

My buddy Mike Ryan sent me a DM on Twitter in May saying that he was looking for a new gig.
I replied to him that I selfishly wished I could work with him, knowing full well that I had little to offer, and that he was more than capable of receiving several healthy offers that likely included some darn good compensation, benefits, and even an equity play.
Knowing this, I suggested a few companies and people that I knew would be willing to hire him on the spot.

Over the course of a few months we chatted a few times about what would be next for Mike.
I tried my best to convince him to come join LiveLoveApp as an equal partner.
I was hopeful that we would be able to work together and to build a business and product.
But, I must say, I didn't quite have the best offer.
Most other opportunities that Mike was considering included a six-figure salary and everything that would go along with that.
I pitched him without a salary, no benefits, no paid-time-off, but most importantly, 50% of a dream of building something new.

I pulled up my United app and punched in PDX to HSV.
"What are ya up to this weekend?"
It looked like I could get a decent flight out to Huntsville -- Rocket City as I learned -- the next day.
A weekend in Huntsville sounded like fun, so my partner Bonnie came along.
We landed in beautiful Huntsville, enjoyed some excellent BBQ, drank a few IPAs and sour beers, and thoroughly enjoyed the space museum.

After a wonderful weekend in Huntsville, not to mention, spending some time on the America's best regional airport, I chatted with Mike some more about what we might do next.
A few days later I got a message from Mike that read:

> I'm all in on LiveLoveApp 💪

## Our Just Cause

I recently read The Infinite Game by Simon Sinek.
The book is excellent, and I highly recommend you check it out.
In the book, Simon talks about "A Just Cause".
It's more than a vision statement - it's the reason an organization exists.
This seemed like a good place to start.

A Just Cause must meet the following criteria:

- Affirmative and optimistic
- Inclusive and open to contributions
- Service-oriented for the benefit of others
- Enduring and resilient
- Infinite and unattainable

Mike and I were headed to San Diego to deliver a workshop together for a client, and we thought it would be a good idea if we landed a few days early to do an offsite.
One of our first tasks was to determine our just cause.
After brainstorming, throwing out some ideas, and refining, we landed on what I believe is an excellent just cause.

## We Help People Find Absolute Joy in Shipping Apps

Optimistically, all of our clients are the hero in the story, and we're their guide, helping them to find absolute joy.
Inclusively, we want to help all people find absolute joy, and we want to work with others in the noble pursuit.
For the benefit of our clients, we are helping them to ship their app.
This just cause is enduring because the world's appetite for software is massive and exponentially growing.
And, finally, we believe that our just cause is unattainable.

We believe that this just cause will inspire and propel the future of LiveLoveApp.

## Our Culture

Culture is authentically created and groomed by the leadership of an organization.
Starting out on the journey of building LiveLoveApp Mike and I wanted to have a culture that we both desire to build.
Further, the culture should be reflective of our just cause.

The culture of LiveLoveApp seeks to be:

- Inclusive
- Sustainable
- Introspective
- Respectful
- Candid

Mike and I are deeply invested in ensuring the culture aims towards these 5 key ingredients.

## A Reflective Brand

We set out to create a brand identity that reflects both our just cause and our culture.
While I admit reluctantly that not everyone will love our new brand identity, I also admit that I love it.

### So, why a lion?

That's a good question.
And, we have our creative consultant to thank for that.

A lion represents true leadership, boldness, and strength.
But, our lion is also friendly, approachable, playful, and emotional.

### Does the lion have a name?

I can thank Mike for this one: Bryan the Lion.
It's a perfect play on both of our names.

## To the Moon 🚀

> "Leaders don't force people to follow - they invite them on a journey." -- Charles S. Lauer

With a solid foundation of our just cause and culture we are aiming high.
We hope you'll follow along and join us on this adventure.


Determining our just cause was a journey of determination, introspection, and definition of culture. Join us on our journey!

Our Blog