Say you've built a <Button /> component in React that encapsulates your design system and perhaps some business logic to reuse across your React project using Tailwind CSS as the styling tool. It might look something like this:

export default function Button({ className, children, ...props }) {
  return (
    <button
      className={`py-4 px-6 text-white bg-blue-800 text-md hover:opacity-80 transition-opacity ${className}`}
      {...props}
    >
      {children}
    </button>
  );
}

Great! So using this <Button /> anywhere in your project will render the button with some default styles, like the bg-blue-800 background colour:

https://codesandbox.io/p/devbox/tailwind-override-in-react-component-disabled-s3jvt3

Notice, that we also support passing the className prop to this button component, for when there's an exceptional use-case where we'd want to tweak some button styles on an ad-hoc basis.

Consider the case, where we want to change the blue background colour to black. The bg-black Tailwind utility should help us do that. Wonderful, let's see what happens if we pass this in the className prop for the <Button /> component:

<Button className="bg-black">Styled button</Button>

And here's what the result looks like:

That's strange! The button still remains blue. Why didn't the bg-black class name override bg-blue-800?! After all, if we look at how the className prop is used on our <Button /> component, it's specified at the end of all the default Tailwind utilities:

className={`py-4 px-6 text-white bg-blue-800 text-md hover:opacity-80 transition-opacity ${className}`}

so the rendered HTML looks like this:

The first thought here is that since bg-black is used after bg-blue-800, it should take precedence.

However, this is not true. The order in which the class names appear in the class attribute of an HTML element does NOT matter. What matters is the order of these class rules defined in the cascading stylesheet instead.

In our case, Tailwind CSS includes the rules for all the utilities we enjoy using in our app when we include its stylesheets upon installing it. In our example the index.css file does this with:

@tailwind base;
@tailwind components;
@tailwind utilities;

So, now we know that in order for bg-black to take precedence over bg-blue-800, we need that style rule to appear later in the stylesheet, but we don't have control over it! How do we go around this?

The Solution

So, how do we override Tailwind CSS Styles in a React Component?

We can use a package called tailwind-merge! This package exposes a twMerge helper that can help remove conflicting classes and prefer the className that you pass to a React component instead. Let's see how we can make use of this helper:

import { twMerge } from "tailwind-merge";

export default function Button({ className, children, ...props }) {
  return (
    <button
      className={twMerge(
        "py-4 px-6 text-white bg-blue-800 text-md hover:opacity-90 transition-opacity",
        className,
      )}
      {...props}
    >
      {children}
    </button>
  );
}

We've updated our <Button /> component so the className is now the return value of the twMerge function imported from "tailwind-merge", with the default button classes as the first argument and the provided className prop as the second argument. With this in place, using our <Button /> with the className="bg-black" prop now renders the button as intended:

https://codesandbox.io/p/devbox/tailwind-override-in-react-component-tailwind-merge-d8nj7p?file=%2Fsrc%2FButton.component.tsx&embed=1

Bonus

If you use the clsx package for constructing classNames in React conditionally, a new helper function can help you combine clsx and twMerge and use it frequently across React components. Here's such a helper function called cn in TypeScript:

import { type ClassValue, clsx } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputClasses: ClassValue[]) {
  return twMerge(clsx(inputClasses))
}

So you can make use of this in the <Button /> component like so,

import { cn } from "../cn.helper";

export default function Button({ className, children, ...props }) {
  return (
    <button
      className={cn(
        "py-4 px-6 text-white bg-blue-800 text-md hover:opacity-90 transition-opacity",
        className,
      )}
      {...props}
    >
      {children}
    </button>
  );
}

Thanks for reading!

As seen in the above screenshots from Safari on an iPhone, using 100vh introduces a scrollbar when the Safari toolbar is visible and cuts off the bottom content.

This is because the vh unit computes the viewport size without factoring in the toolbar height. Thus, the user either needs to scroll down for the address bar to automatically disappear or manually hide it for all content to be displayed.

Unfortunately, there's no way to programmatically hide the toolbar on iOS Safari using JavaScript at the time of writing. However, there is a solution for the content to adapt with the toolbar using the dvh unit.

The dvh unit stands for dynamic viewport height and enjoys support from all the latest browsers. This unit factors in the viewport that's truly visible to users.

In case, you want to work with earlier versions of browsers that don't support dvh, you can make use of the @supports CSS rule.

Here's an example of how you'd set up a class called full-viewport-height that adapts according to the browser viewport using the dvh unit but falls back to vh if the browser doesn't support it:

.full-viewport-height {
  height: 100vh;
}

@supports (height: 100dvh) {
  .full-viewport-height {
    height: 100dvh;
  }
}

Using this full-viewport-height on our container now, the result looks as expected:

The content using 100dvh now spans the whole height of the web page even if the Safari toolbar is visible and on scrolling down or hiding it, the content adapts to fill the whole page making sure your content always covers the viewport as expected.

You can find the code sandbox for the above examples at vh-sandbox and dvh-sandbox.

Apple iOS is full of nifty animations and a great source of inspiration when thinking about motion in your next web app. Many of these take users from one view to another in a seamless transition instead of a jarring switch.

One such example is on clicking the Focus mode selection button in the Control Centre:

In this article, we'll re-build this animation in React with Framer Motion.

In case, you're not familiar with Framer Motion, I recommend checking out the article:

which goes over some basics of Framer Motion by creating a reusable animated check icon component.

Demo

Checkout the code and demo of the final animation we'll build as part of this article:

Layout Animation

After playing around with the demo above, did you notice how clicking on the Focus button takes you to the list of focus mode options in a smooth transition? This is a result of the Focus button "moving into" the list of options and becoming the Do Not Disturb button.

Wait, doesn't that require a lot of complex logic to make sure the animation happens performantly? It's the reason the FLIP technique exists, but we want to keep our code declarative. That's where the layout prop provided by Framer Motion comes into play.

You start by adding the layout prop to a motion component, in this case, the motion button:

<motion.button layout>Focus</motion.button>

Now, anytime a style change happens that affects this button's layout, Framer Motion will transition between the layout changes automatically in a performant way. Try clicking the Toggle layout button in the demo sandbox below and see it smoothly transition between two different locations. Then, try removing the layout prop from the button and see the difference!

By default, the layout prop animates any changes to the size and position of the motion component it's used on. This can, at times, lead to undesirable animations where the content can be squished or stretched when transitioning between layouts, especially when the size changes between the start and end state.

To circumvent this, the layout prop also accepts one of the following values:

• layout="size" only animates the size changes in the motion component, for instance, the width and height.

• layout="position" only animates changes in the position of the motion component, as in our example.

• layout="preserve-aspect" only animates the size & position if the aspect ratio remains the same between the transition, and just position if the ratio changes.

In our use case, where we only want the position of the Focus button to transition to the Do Not Disturb button, we'll make use of the layout="position" prop.

Now that we know we only want the layout position to change and how it works, how do we create the transition between the two buttons? After all, we don't have a pre-calculated value to know where the Do Not Disturb button should render on the DOM. We want to be able to render the focus modes list component anywhere in the app while having the animation work as desired.

Well, Framer Motion provides yet another prop called layoutId to create shared layout animations.

View the sandbox below to see how two different motion buttons are rendered separately in the DOM with their styling, but by providing the same layoutId to both of them, Framer Motion can transition between the two as they are removed or rendered in the DOM:

Variants & Stagger Animation

As we saw in the article about creating an animated check icon, we can provide an initial and animate prop to a motion component to specify the states it should start with and end at, and Framer Motion automatically animates the transition between the states. In that article, we passed an object to these props specifying the styles for the two states but the initial and animate can also accept a string which should correspond to the name of a Framer Motion Variant.

A variant is an object with the variant name for the key and the animation properties for the values. They also prove to be a nice way to be more descriptive about animation states in Framer Motion.

For instance, here's the variant object defined for the focus modes list items:

{
  hidden: {
    y: -10,
    opacity: 0
  },
  visible: {
    y: 0,
    opacity: 1
  }
}

If we break this down, we see that:

• When the variant name is hidden, the element's opacity is 0 and it sits 10 pixels above its normal position

• However, when the variant name is visible, the element's opacity is 1 and it sits at its normal position

We can take this variant object and provide it to a motion li component which we will render for each focus mode:

<motion.li
  variants={{
    hidden: {
      y: -10,
      opacity: 0
    },
    visible: {
      y: 0,
      opacity: 1
    }
  }}
>
  Do Not Disturb
</motion.li>

Alright, now that we've specified what styles we want for our list items corresponding to variant names hidden and visible, we need a way to determine when a variant gets applied.

Now's a good time to mention that variants propagate from parent components to their children. This means if we set these variant names to the parent ul to be applied for the initial and animate props, these would automatically flow down to the child li. So, as soon as the ul mounts, it's initially using the hidden variant and animates to the visible variant, which is the same behaviour its children li follow:

<motion.ul
  initial="hidden"
  animate="visible"
>
  <li variants={variantsFromTheSnippetAbove}>Do Not Disturb</li>
</motion.ul>

Not only are variants helpful to keep our animation states more readable and have the values propagate to children, but they also have another trick up their sleeves. Variants are helpful to orchestrate animations! This means we can set additional animation configurations on the parent element's variants prop to define the animation execution of its child motion components. This will become clearer by explaining the snippet below:

<motion.ul
  initial="hidden"
  animate="visible"
  variants={{
    visible: {
      transition: {
        delayChildren: 0.2,
        staggerChildren: 0.05
      }
    }
  }}
>
  <li variants={variantsFromTheSnippetAbove}>Do Not Disturb</li>
</motion.ul>

We've added a new variants prop to the ul which defines a transition behaviour for the visible variant. It says that whenever the visible variant is applied, please delay the animation of the children by 0.2 seconds and stagger them with a delay of 0.05 seconds, so they render one by one, as it does on iOS.

Play around with the code sandbox below to view how variants help us create the stagger animation we want for our focus modes list:

Putting It All Together

It's time to put the layout animation along with the variant stagger animation we've learnt to re-create the iOS animation.

We'll create the Focus button with the layout="position" prop and give it a layoutId of focusModeButton. This button's onClick event handler will update the state to display the focus modes list we'll create next.

<motion.button
  layout="position"
  layoutId="focusModeButton"
  onClick={() => setIsFocusModesListVisible(true)}
>
  Focus
</motion.button>

To create the focus modes list, we'll use the ul and li elements along with Framer Motion's variants prop as we saw in the last section.

We can define the variants for the list container and the list items in separate constant objects as follows:

const LIST_CONTAINER_VARIANTS = {
  visible: {
    transition: {
      delayChildren: 0.2,
      staggerChildren: 0.05
    }
  }
};

const LIST_ITEM_VARIANTS = {
  hidden: {
    y: -10,
    opacity: 0
  },
  visible: {
    y: 0,
    opacity: 1
  }
};

These are the same animation configurations we saw earlier to re-create the focus modes list stagger animation. Finally, we'll apply these variants to the ul and li elements, while providing the first Do Not Disturb button, the same layout animation behaviour as we did for the Focus button, i.e., layout="position" and the same layoutId of focusModeButton:

<motion.ul
  variants={LIST_CONTAINER_VARIANTS}
  initial="hidden"
  animate="visible"
>
  <motion.li>
    <motion.button
      layout="position"
      layoutId="focusModeButton"
    >
      Do Not Disturb
    </motion.button>
  </motion.li>

  <motion.li variants={LIST_ITEM_VARIANTS}>
    <motion.button>Work</motion.button>
  </motion.li>

  <motion.li variants={LIST_ITEM_VARIANTS}>
    <motion.button>Sleep</motion.button>
  </motion.li>

  <motion.li variants={LIST_ITEM_VARIANTS}>
    <motion.button>Personal</motion.button>
  </motion.li>
</motion.ul>

Using these two components, we can use React's state to toggle between the Focus mode button and the focus modes list, while Framer Motion handles the animation between the two:

{isFocusModesListVisible ? (
  <FocusModesList onClose={() => setIsFocusModesListVisible(false)} />
) : (
  <motion.button
    layout="position"
    layoutId="focusModeButton"
    className="FocusModeOpenButton"
    onClick={() => setIsFocusModesListVisible(true)}
  >
    Focus
  </motion.button>
)}

With this, we end up with the final animation as we set out to build:

Thanks for reading and stay tuned for more articles on the topic!

Both React and Framer Motion are incredible technologies that help us build next-level user interfaces in a declarative way.

If you're wondering what declarative programming is, I highly recommend checking out the article Imperative vs Declarative Programming

In this article, we'll create a reusable check icon component that animates by drawing itself in and out when it's mounted and unmounted by React. The animation utilises some core components from Framer Motion which are also described.

Demo

Setting up the icon component

We'll use the check icon provided by hero icons. Since we'll need to manipulate the path within the check icon svg, let's copy the JSX from hero icons into a new component AnimatedCheckIcon:

function AnimatedCheckIcon() {
  return (
    <svg
      xmlns="http://www.w3.org/2000/svg"
      fill="none"
      viewBox="0 0 24 24"
      strokeWidth={1.5}
      stroke="currentColor"
    >
      <path
        strokeLinecap="round"
        strokeLinejoin="round"
        d="M4.5 12.75l6 6 9-13.5"
      />
    </svg>
  );
}

Nothing special here at the moment (of course, apart from the beautiful icon by the hero icons team), so let's install framer motion in preparation for adding animations to this component

npm install framer-motion

Animating an SVG path with Framer Motion

The first step to animate a path element is converting it to a motion.path component. Motion components exist for all HTML and SVG elements and add animation super-powers to their DOM primitive counterparts.

These super-powers include defaults bundled with Framer Motion leading us to better looking and performant animations without worrying about the intricate details. The bare bones version to animate a motion component from one state to another requires passing the initial and animate prop specifying the styles for these states. Framer Motion then transitions between these states while providing satisfying defaults for its easing function and its duration at the least.

Declarative programming at its best!

Amongst these super-powers, is the ability to animate pathLength for a motion.path component.

Let's take a look at what happens when we use motion.path in our AnimatedCheckIcon instead of path and specify the initial and animate props to take us from a pathLength of 0 to 1:

<motion.path
  strokeLinecap="round"
  strokeLinejoin="round"
  initial={{ pathLength: 0 }}
  animate={{ pathLength: 1 }}
  d="M4.5 12.75l6 6 9-13.5"
/>

Great! We're already animating the check icon drawing itself in.

Similarly, if we switch up the initial and animate pathLengths to go from 1 to 0, we'll see the check icon erase itself:

<motion.path
  strokeLinecap="round"
  strokeLinejoin="round"
  initial={{ pathLength: 1 }}
  animate={{ pathLength: 0 }}
  d="M4.5 12.75l6 6 9-13.5"
/>

The transition duration in the GIFs has been increased from the default value for clarity but is not displayed in the code snippets as we'll be touching on that later in the article

Okay, so we now know how to animate the pathLength but what happens if we mount/unmount this component? Let's render this component based on some state that we can toggle with a button. So we can now conditionally render our <AnimatedCheckIcon /> like so:

{isCheckIconVisible && <AnimatedCheckIcon />}

We can see the path now animate when the component mounts but how do we specify an animation to run when it un-mounts?

Adding an unmount animation with Animate Presence

Framer motion provides the AnimatePresence component that helps us define animations that happen when a component is removed from the DOM by React.

This can be done by wrapping the component to be removed within <AnimatePresence /> and adding the exit prop to the motion component defining its animation behaviour.

To make use of AnimatePresence, first let's add an isVisible: boolean prop to our <AnimatedCheckIcon /> component that conditionally renders our icon based on the value provided:

function AnimatedCheckIcon({ isVisible = true }) {
  return (
    isVisible && (
      <svg
        xmlns="http://www.w3.org/2000/svg"
        fill="none"
        viewBox="0 0 24 24"
        strokeWidth={1.5}
        stroke="currentColor"
      >
        <motion.path
          strokeLinecap="round"
          strokeLinejoin="round"
          initial={{ pathLength: 0 }}
          animate={{ pathLength: 1 }}
          transition={{ duration: 0.5 }}
          d="M4.5 12.75l6 6 9-13.5"
        />
      </svg>
    )
  );
}

We now need to nest our conditionally rendered icon within <AnimatePresence />:

function AnimatedCheckIcon({ isVisible = true }) {
  return (
    <AnimatePresence>
      {isVisible && (
        <svg
          xmlns="http://www.w3.org/2000/svg"
          fill="none"
          viewBox="0 0 24 24"
          strokeWidth={1.5}
          stroke="currentColor"
        >
          <motion.path
            strokeLinecap="round"
            strokeLinejoin="round"
            initial={{ pathLength: 0 }}
            animate={{ pathLength: 1 }}
            transition={{ duration: 0.5 }}
            d="M4.5 12.75l6 6 9-13.5"
          />
        </svg>
      )}
    </AnimatePresence>
  );
}

It's necessary that <AnimatePresence> component is outside of the isVisible && condition as that allows Framer Motion to workaround React's limitation of not providing enough data to animate an element when it's being removed from the React tree

With our component wrapped in AnimatePresence, we can now add the exit prop to our motion.path:

<motion.path
  strokeLinecap="round"
  strokeLinejoin="round"
  initial={{ pathLength: 0 }}
  animate={{ pathLength: 1 }}
  exit={{ pathLength: 0 }}
  d="M4.5 12.75l6 6 9-13.5"
/>

We specify exit animation to complete with pathLength: 0 so the icon erases itself as we saw before. In summary, the props:

initial={{ pathLength: 0 }}
animate={{ pathLength: 1 }}
exit={{ pathLength: 0 }}

declare that the component should transition from pathLength 0 to 1 when it mounts and 1 to 0 when it un-mounts.

If we connect the toggle state for rendering our icon from earlier but use the isVisible prop as follows:

{<AnimatedCheckIcon isVisible={isCheckIconVisible} />}

we now see the unmount animation too:

Disabling the initial mount animation

At this point, whenever our <AnimatedCheckIcon /> component first mounts, it will animate itself based on the value of the isVisible prop. This might be the behaviour that's desired within a certain use case but perhaps not in others.

Thankfully, the <AnimatePresence /> component exposes the initial prop that accepts a boolean value to handle this concern. Passing false suppresses the first mount animation while true, which is the default, runs the animation on the initial mount. Adding it as a prop to our icon component, to mimic this behaviour, our component interface now looks like the following:

function AnimatedCheckIcon({ initial = true, isVisible }) {
  return (
    <AnimatePresence initial={initial}>
      {/* Rest of the component */}
    </AnimatePresence>
  )
}

Fine-tuning the animation

Our animation is now set up but we can play around with yet another prop for Motion Components – transition – to make it even better! The transition prop can be used to fine-tune how the animation values go from one state to the other.

We'll make use of 3 properties within transition:

1. Type

The type property accepts multiple options but two worth highlighting are spring and tween. Spring animations use spring physics to transition between animation states while Tween is a duration-based type and can be customised with an easing function. Framer Motion picks the most appropriate defaults based on the styles being animated which in our case would be tween.

2. Duration

The duration property specifies how long the transition takes to go from the initial to the animated state, specified in seconds. The default duration for tween animations is 0.3 seconds.

3. Ease

The ease property accepts an easing function to customise how fast the values change while animating over the specified duration. We'll use the built-in ease-out easing when the check icon mounts and ease-in when it un-mounts. The ease-out function starts quick but ends in a relaxed fashion while the ease-in animation starts in a relaxed fashion and ends quick. Try reverting these values in the sandbox to see how they affect our animation!

Putting these customisations together:

<motion.path
  initial={{ pathLength: 0 }}
  animate={{ pathLength: 1 }}
  exit={{ pathLength: 0 }}
  transition={{
    type: "tween",
    duration: 0.3,
    ease: isVisible ? "easeOut" : "easeIn"
  }}
  strokeLinecap="round"
  strokeLinejoin="round"
  d="M4.5 12.75l6 6 9-13.5"
/>

we get the animation from the demo!

Our final reusable animated check icon component

So, here's what we end up with as our reusable component that you can drop into your project for that well-polished micro-interaction:

import { AnimatePresence, motion } from "framer-motion";

function AnimatedCheckIcon({ initial = true, isVisible }) {
  return (
    <AnimatePresence initial={initial}>
      {isVisible && (
        <svg
          xmlns="http://www.w3.org/2000/svg"
          fill="none"
          viewBox="0 0 24 24"
          strokeWidth={1.5}
          stroke="currentColor"
          className="CheckIcon"
        >
          <motion.path
            initial={{ pathLength: 0 }}
            animate={{ pathLength: 1 }}
            exit={{ pathLength: 0 }}
            transition={{
              type: "tween",
              duration: 0.3,
              ease: isVisible ? "easeOut" : "easeIn"
            }}
            strokeLinecap="round"
            strokeLinejoin="round"
            d="M4.5 12.75l6 6 9-13.5"
          />
        </svg>
      )}
    </AnimatePresence>
  );
}

In case, you're curious about the toggle button animation on the demo sandbox, it uses Framer Motion gestures to animate its scale on hover and tap. You can check out the code sandbox for the full code and stay tuned for more articles on the topic.

Thanks for reading!

I recently finished working on an Angular web app and it was time to set up analytics to better understand the user experience it delivers. My choice of analytics provider was Segment as it allows setting up a single analytics source within the app and feed the data to various other destinations like Google Analytics and Amplitude.

Having decided on the analytics service to use, I now wanted to integrate it within Angular and test it across different app environments. For the app, I had three environments - dev, staging and production. By specifying different analytics keys for each environment, it prevents skewing live analytics while allowing us to test our integration in a non-production environment.

Including the Segment analytics tracking snippet

Setting up Segment starts with including their tracking snippet in our index.html:

<script>
  !function(){var analytics=window.analytics=window.analytics||[];if(!analytics.initialize)if(analytics.invoked)window.console&&console.error&&console.error("Segment snippet included twice.");else{analytics.invoked=!0;analytics.methods=["trackSubmit","trackClick","trackLink","trackForm","pageview","identify","reset","group","track","ready","alias","debug","page","once","off","on","addSourceMiddleware","addIntegrationMiddleware","setAnonymousId","addDestinationMiddleware"];analytics.factory=function(e){return function(){var t=Array.prototype.slice.call(arguments);t.unshift(e);analytics.push(t);return analytics}};for(var e=0;e<analytics.methods.length;e++){var key=analytics.methods[e];analytics[key]=analytics.factory(key)}analytics.load=function(key,e){var t=document.createElement("script");t.type="text/javascript";t.async=!0;t.src="https://cdn.segment.com/analytics.js/v1/" + key + "/analytics.min.js";var n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(t,n);analytics._loadOptions=e};analytics._writeKey="YOUR_WRITE_KEY";analytics.SNIPPET_VERSION="4.15.2";
  analytics.load("YOUR_WRITE_KEY");
  analytics.page();
  }}();
</script>

Note the following lines of code towards the end:

  analytics._writeKey="YOUR_WRITE_KEY"
  analytics.load("YOUR_WRITE_KEY");
  analytics.page();

We'll remove these lines from the snippet and handle them ourselves in the Angular app, so the new tracking code we include in our index.html becomes:

<script>
  !function(){var analytics=window.analytics=window.analytics||[];if(!analytics.initialize)if(analytics.invoked)window.console&&console.error&&console.error("Segment snippet included twice.");else{analytics.invoked=!0;analytics.methods=["trackSubmit","trackClick","trackLink","trackForm","pageview","identify","reset","group","track","ready","alias","debug","page","once","off","on","addSourceMiddleware","addIntegrationMiddleware","setAnonymousId","addDestinationMiddleware"];analytics.factory=function(e){return function(){var t=Array.prototype.slice.call(arguments);t.unshift(e);analytics.push(t);return analytics}};for(var e=0;e<analytics.methods.length;e++){var key=analytics.methods[e];analytics[key]=analytics.factory(key)}analytics.load=function(key,e){var t=document.createElement("script");t.type="text/javascript";t.async=!0;t.src="https://cdn.segment.com/analytics.js/v1/" + key + "/analytics.min.js";var n=document.getElementsByTagName("script")[0];n.parentNode.insertBefore(t,n);analytics._loadOptions=e};analytics.SNIPPET_VERSION="4.15.2";}}();
</script>

This allows us to share the "base" Segment tracking snippet in all app environments while specifying a SEGMENT_WRITE_KEY specific to each.

Specifying a different key for each environment

Now, how do we go about specifying a key for each environment?

At the time of writing, when creating a new app with the Angular CLI using ng new, it creates two environment files in the environments folder by default:

1. environment.ts: environment variables for local development
2. environment.prod.ts: environment variables for the production build when running ng build --configuration production or the default ng build command

So, we can use these files to specify different analytics keys for Segment:

// file environment.ts:

export const environment = {
  production: false,
  analytics: {
    segmentWriteKey: 'DEV_SEGMENT_WRITE_KEY'
  }
};

// file environment.prod.ts:

export const environment = {
  production: true,
  analytics: {
    segmentWriteKey: 'PRODUCTION_SEGMENT_WRITE_KEY'
  }
};

Having specified the different keys, we need to initiate Segment analytics with the correct key. This can be done in our main.ts file which is responsible for bootstrapping our Angular app. Before the platformBrowserDynamic().bootstrapModule(AppModule) call that loads our app, we can initialise Segment by adding back analytics._writeKey="YOUR_WRITE_KEY" and analytics.load("YOUR_WRITE_KEY"); we removed from the tracking snippet earlier but replace "YOUR_WRITE_KEY" with our environment variable segmentWriteKey.

Trying out this line of code as is though, makes TypeScript unhappy with the following error:

Cannot find name 'analytics'. ts(2304)

Well, this means that analytics isn't defined anywhere, but with the way Segment works, it should be part of the window object. So, let's try changing it to window.analytics.load(environment.analytics.segmentWriteKey). This gives us a different error:

Property 'analytics' does not exist on type 'Window & typeof globalThis'. ts(2339)

A different error message, some progress!

This is because TypeScript still does not know if the analytics object exists or the interface it provides within the window object. Thankfully, we can strongly type the analytics object by installing its types as a dev dependency using:

npm install --save-dev @types/segment-analytics

With the types installed, there's one last thing we need to do, to make TypeScript happy with using the analytics object anywhere within our code. That bit is making sure we include the segment-analytics namespace within our tsconfig.app.json types property like so:

// file: tsconfig.app.json

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/app",
    "types": ["segment-analytics"]
  },
  "files": [
    "src/main.ts",
    "src/polyfills.ts"
  ],
  "include": [
    "src/**/*.d.ts"
  ]
}

Remember to restart your dev server with ng serve after updating tsconfig.app.json!

With this in place, we can now call all functions exposed by the analytics object anywhere in our code and enjoy all of TypeScript's goodness when doing so. Our final main.ts file should now look like:

// file: main.ts

import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

// typing this as any since the types we installed don't include _writeKey
(analytics as any)._writeKey = environment.analytics.segmentWriteKey
analytics.load(environment.analytics.segmentWriteKey)

platformBrowserDynamic().bootstrapModule(AppModule)
  .catch(err => console.error(err));

Tracking page changes

Our final task is to now bring back the analytics.page() call we removed from the snippet earlier. Segment analytics includes this call in the tracking snippet assuming its usage in a traditional Multi Page Application (MPA) where we load a new index.html file for each page and thus invoke a new analytics.page() call.

With Angular though, this is a different story as we're building a Single Page Application (SPA) that only loads a single index.html file and handles page changes via JavaScript. So, we need to take control of the analytics page calls.

This is a perfect use-case for Angular Router Events as it allows us to hook into the lifecycle of the Angular router and subscribe to page changes. With this, any time the Angular Router loads a new page, we can hook into that event, and make a call to analytics.page(). We'll make use of the NavigationStart event, so we trigger the call as soon as a page is changed.

To be able to listen to router events, we first need to inject the Angular Router in our app.component.ts:

import { Router } from '@angular/router';

constructor(private _router: Router) {}

Using the injected router we can subscribe to all its events:

this._router.events.subscribe((event) => {
  console.log(event)
})

Since we're interested in the NavigationStart event only, we can add a check with instanceof:

import { NavigationStart } from '@angular/router';

if (event instanceof NavigationStart) {
  console.log(event)
}

If we replace console.log(event) in the above snippet with analytics.page(event.url), we can trigger an analytics page call, each time Angular Router changes a page. Putting all of these pieces together and remembering to unsubscribe from our subscription when this component destroys to prevent memory leaks, we get:

// file: app.component.ts

import { Subscription } from 'rxjs';
import { NavigationStart, Router } from '@angular/router';
import { Component, OnDestroy, OnInit } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit, OnDestroy {
  routerEventSubscription: Subscription | undefined;

  constructor(private _router: Router) {}

  public ngOnInit(): void {
    this.routerEventSubscription = this._router.events.subscribe((event) => {
      if (event instanceof NavigationStart) {
        analytics.page(event.url)
      }
    });
  }

  public ngOnDestroy(): void {
    this.routerEventSubscription?.unsubscribe()
  }
}

That sets us up for using Segment analytics in our Angular app! 🎉

For tracking particular events, like clicks, make use of the analytics.track() call which would also now be strongly typed thanks to the @types/segment-analytics package we set up.

Bonus – setting up the staging environment

As an added bonus, let's look at setting up a staging (or QA) environment for the app. We'll make use of the configuration and fileReplacement properties in angular.json which allow us to create a new build target and specify specific file replacements at compile time.

To do this, we'll duplicate the production configuration, rename the key to staging and within fileReplacements, specify environment.ts to be replaced with environment.staging.ts when we build the app for staging:

"staging": {
  "budgets": [
    {
      "type": "initial",
      "maximumWarning": "500kb",
      "maximumError": "1mb"
    },
    {
      "type": "anyComponentStyle",
      "maximumWarning": "2kb",
      "maximumError": "4kb"
    }
  ],
  "fileReplacements": [
    {
      "replace": "src/environments/environment.ts",
      "with": "src/environments/environment.staging.ts"
    }
  ],
  "outputHashing": "all"
},

Remember to create the environment.staging.ts file! Our new configuration will now be used when building the app with ng build --configuration staging

View the code from this article on GitHub

Thanks for reading!