Forem: Anthony Tambrin

[Boost]

Anthony Tambrin — Fri, 28 Nov 2025 12:00:34 +0000

How I Built an F1 Top-Down Racer in 48 Hours

Anthony Tambrin ・ Nov 23

How I Built an F1 Top-Down Racer in 48 Hours

Anthony Tambrin — Sun, 23 Nov 2025 08:28:45 +0000

Play the game: https://copet80.itch.io/lap-legends

I've made games before, but somehow I had never built any top-down racing game. And because I know myself extremely well... I also know that if I didn't give myself a strict time limit, this thing would quietly grow in scope until it turned into another multi-year side project (looking at you, Guilds n Glory 👀).

So I gave myself 48 hours.

No extensions. No polishing forever. Just build a tiny F1-inspired racer and ship it.

It turned out to be one of the most fun coding weekends I've had in years.

Why Build a Top-Down Racing Game?

It started with a simple conversation at work.

A colleague had hidden a tiny drifty F1 mini-game as an easter egg in our product. His version was intentionally oversteery, very "Initial D meets corporate software". I loved it, but I also found myself thinking:

"These are F1 cars... should they drift this much?"

He told me he might tighten the physics, which immediately made my developer brain go:

What if I just try building my own?

No copying his code. No reverse-engineering someone else's idea.

Just... see if I could recreate the feeling of tight, grippy F1 handling from scratch.

And that curiosity spiralled into a 48-hour sprint.

The 48-Hour Build Timeline

Here's roughly how the 48 hours went. It wasn't glamorous, but it was surprisingly steady:

0-4 hours: Core Rendering & Movement

Got the absolute basics in:

rendering the car and track
player input
simple physics: acceleration, steering, friction

It didn't feel like an F1 car yet, but it moved, which was enough to keep me going.

4-8 hours: Track Integration & Game Loop

Pulled the real track into the game and added:

off-road friction
skid effects
spark particles

By hour 8, I actually had something that resembled a tiny racing game.

8-16 hours: Racing Line & Autodrive

Implemented the racing line and built the autopilot to follow it.

Also created the title screen, where the bot drives around to make things look alive.

16-24 hours: Ghost Recording & Playback

Added ghost recording, playback, and local storage saving.

This was the moment the game suddenly felt replayable.

24-36 hours: UI & Leaderboard

Built the UI and wired the leaderboard to Firebase Storage.

Ghost data is encoded/decoded so each run is only ~3–4 KB.

36-48 hours: Polish & Deployment

Did the classic last-day marathon:

UI polish
bug fixing
physics tuning
final tweaks to the autopilot
zipped the build and deployed to itch.io

And then it was done.

Want to See It in Action?

If you want a quick vibe check of what Lap Legends looks like, here's the tiny trailer I put together:

🎥 Game Trailer

And if you're curious how chaotic the early hours were, I recorded my first 4 hours coding session:

🎥 First 4 Hours Dev Log

Challenges (AKA: Every Simple Idea Is Actually Three Ideas in a Trench Coat)

Challenge #1: Making the Bot Follow a Racing Line

This was way more fun than I expected.

The racing line is just a list of points. But making the bot follow it like a human driver --- not teleport, not cheat, not solve physics separately --- was trickier.

The bot uses the exact same steering logic as the player. No special rules.

Which means:

If the physics are bad, the bot exposes them instantly.

There's still one part I want to refine: letting the bot drive from the starting grid to the start checkered line so it can seamlessly hand off control to ghost playback. Right now there's the occasional snap or jump when switching from autopilot → recorded ghost data.

Challenge #2: Effects, Skidmarks & Performance

I really didn't want to drop into WebGL or WebGPU for such a small project.

So everything is a bit of a Frankenstein, but in a charming way.

Cars, track, and UI are all DOM elements, styled with CSS.
Spark effects are object-pooled DOM elements with CSS animations.
Skid marks are drawn using plain 2D canvas, except the track is divided into many 1000×1000 pixel canvases placed in a grid. I only draw on the canvas cell where the skid happens. This works, but it also introduces some visible seams between canvases.

What I learned very quickly:

too many canvases reduce FPS.

Even if they look innocent.

Challenge #3: The Engine Sound (My Favourite Part)

This was the rabbit hole I didn't expect.

I built a small engine simulator that:

pitches an engine loop up/down with speed
fakes gear shifts
downshifts under braking
handles acceleration/deceleration smoothly
snaps into new gear ratios realistically

It ended up sounding... actually pretty good.

This is the part of the game I'm proudest of.

It really sells the speed.

Building the Physics (A.K.A.: "I Thought I Understood Maths... Until I Didn't")

Going in, I wasn't planning to simulate aerodynamics, tyre temperatures, downforce, slip angles, or anything resembling real motorsport science. I just wanted the car to feel responsive, fast, and "F1-ish".

I actually ended up using very simple movement physics --- the same kind you'd use for flocking behaviour:

acceleration
friction
a steering force
rotation based on speed

And surprisingly... that was good enough!

The car felt tight, grounded, and fun.

Bugs (Because No Weekend Project Is Complete Without Them)

Bug #1: "F1 Train on Rails"

At one point, the turning was so tight that the car looked like it was running on an invisible track system. Zero drift. Zero slide. It turned like a robotics lab demo.

The fix was simple and elegant:

scale steering sensitivity based on speed.

Slow = more angle.

Fast = gentle input only.

Instantly felt better.

Bug #2: The Autopilot Had an Existential Crisis

The title screen features a bot driving the car automatically in a looping sequence. It's supposed to look smart and confident.

Instead, it started oscillating back and forth like it forgot how to human. It couldn't decide whether to brake or accelerate and kept stuttering at corners.

The fix?

Let the bot "look further ahead" on straights, and "look closer" when braking.

Basically: give it vision proportional to intention.

Suddenly it stopped panicking.

What I Cut (Because 48 Hours Is 48 Hours)

The biggest thing I couldn't polish fully:

the handoff between bot driving >> ghost playback.

Ghost data is recorded starting at the checkered line, which is ahead of the starting grid so the bot must drive from the grid to the exact ghost start point. That small transition is where the occasional snap happens. One day I'd love to smooth it out.

Shipping It Fast

With the deadline almost up, I prioritised:

fun physics
stable performance
a working bot
ghost replay
track layout
engine sound
and just enough effects to feel satisfying

Aside from the core game systems, I also squeezed in:

a multiplayer leaderboard
ghost uploads to Firebase Storage
encoded ghost data, reducing each ghost to ~3–4 KB

Then I zipped the build, uploaded it to itch.io, and called it done.

What I Learned

You don't need perfect physics to make a fun racing game.

You don't need advanced graphics APIs to make satisfying effects.

Sometimes, the constraints are what make a project fun.

Mostly, I rediscovered how joyful it is to tinker ---

try something, break something, try again, laugh, fix it, continue.

That's the whole point of coding for me.

Try It Out & Tinker Yourself

If you want to see what a tiny 48-hour F1 experiment looks like:

Play Lap Legends

https://copet80.itch.io/lap-legends

If this inspires you to build your own tiny game, even better.

Give yourself a deadline.

Take a weird idea.

And see where it leads.

You might surprise yourself.

Creating a Smooth Transitioning Dialog Component in React: My Journey

Anthony Tambrin — Fri, 19 Jul 2024 05:38:34 +0000

I've been working on a project to create a smooth transitioning dialog component in React, and I want to share my journey through the process, highlighting key steps and challenges encountered along the way.

Part 1: Setting the Foundation

In the first part of the series, I laid the groundwork by setting up the component structure. I created a context to manage the state and developed the main dialog component with its header, body, footer, and container.

My primary goal was to ensure that the dialog could support minimisation and expansion while being adaptable to content changes. This foundation was crucial for building a reusable and functional dialog component.

Read the full article

Part 2: Adding Smooth Animations

Next, I focused on adding smooth animations to the dialog's minimise and expand transitions using CSS properties like max-width and max-height. I preferred these properties over transform and zoom for better fluidity and control. I introduced the DialogAnimation component and updated the DialogContainer to support these animations.

Managing state with React hooks was essential to ensure that the transitions were smooth and seamless. This step significantly improved the user experience by making the dialog interactions more fluid.

Read the full article

Part 3: Refining Animation Reliability

In the third part, I addressed the reliability of the dialog's animations by calculating both expanded and minimised dimensions. To achieve this, I expanded and minimised the dialog in successive render cycles to measure dimensions accurately using getBoundingClientRect.

This approach improved state management and involved using styled components for seamless animations. Although this step increased the complexity and potential performance overhead, it was necessary to ensure smooth and accurate transitions.

Read the full article

Part 4: Eliminating Flickering Issues

Finally, I resolved flickering issues by introducing an invisible container for dimension calculations. This technique, inspired by game development practices like double buffering, allowed for smoother, jank-free transitions. I detailed the setup of a secondary container, managed state with context, and refined the transition functions to ensure clean and accurate animations.

Despite the added complexity, this approach significantly enhanced the overall user experience by eliminating any flickering during transitions.

Read the full article

Conclusion

Creating a smooth transitioning dialog component in React has been a rewarding journey filled with challenges and learnings. By setting a solid foundation, adding smooth animations, refining animation reliability, and eliminating flickering issues, I've gained valuable insights into creating robust and user-friendly components.

Thank you so much for taking the time to read through this post. I really encourage you to dive into each blog post for all the nitty-gritty steps and code details. I'm genuinely looking forward to hearing your thoughts and suggestions to validate or even enhance this approach. Do you think the animation is worth the complexity and trade-offs? Can we find a better way to pull this off? Maybe sticking to vanilla JS/CSS or exploring 3rd-party libraries like framer motion could be the way to go. Your comments and insights mean a lot to me.

Creating a Smooth Transitioning Dialog Component in React (Part 4/4)

Anthony Tambrin — Wed, 17 Jul 2024 09:10:48 +0000

Part 4: Final Refinements

In Part 3, I enhanced the DialogAnimation component to calculate both expanded and minimised dimensions. This approach ensured accurate and visually appealing transitions by using successive render cycles to measure the dimensions. However, it introduced complexity and potential performance issues, particularly causing jank or flicker during the dimension calculation process.

Introducing the Invisible Container

To tackle the flickering issue, I'm introducing a secondary, invisible container exclusively for dimension calculations. This concept is inspired by techniques used in game development, such as double buffering, blitting, or offscreen rendering. These techniques help manage rendering by performing calculations offscreen and then applying the final result to the visible screen.

Understanding Double Buffering, Blitting, and Offscreen Rendering

Double Buffering: In game development, double buffering involves using two buffers to hold frame data. While one buffer is displayed, the other is used to prepare the next frame. This reduces flickering and provides smoother visuals by ensuring that only fully rendered frames are shown to the user.
Blitting: Blitting (block transfer) is the process of transferring blocks of data (usually images) from one buffer to another. This technique is used to quickly update the screen with pre-rendered images, enhancing performance and visual stability.
Offscreen Rendering: Offscreen rendering involves rendering content to an offscreen buffer rather than directly to the screen. Once rendering is complete, the content is transferred to the visible screen in one operation. This prevents incomplete renders from being seen by the user and helps in managing complex animations or visual updates smoothly.

Why This Approach Could Be Worth Trying

Eliminates Jank and Flicker: By calculating dimensions offscreen, we can avoid the visible jumps that occur during the transition. This makes the user experience smoother and more polished.
Accurate Measurements: The invisible container can be manipulated freely without affecting the user's view, allowing for precise measurements using getBoundingClientRect.
Cleaner UI Transitions: The final dimensions can be applied to the visible dialog in one go, ensuring a clean and seamless transition without intermediate visual states.

Although this approach does introduce some performance overhead by rendering the DOM twice, the trade-off can be worth it for the improved visual quality and user experience.

By implementing this approach, I aim to enhance the reliability and visual quality of the dialog animations, addressing the primary concerns identified in the previous parts.

Implementing the Invisible Container Approach

With this approach, I introduce significant changes to the DialogAnimation component to tackle the flickering issue observed in Part 3. Here's how it works.

Step 1: Context and Providers

First, I introduce a new context, DialogAnimationContext, and a provider, DialogAnimationProvider, to manage state specific to animation calculations.

const DialogAnimationContext = createContext();

export const useDialogAnimation = () => useContext(DialogAnimationContext);

export const DialogAnimationProvider = ({ children, isExpandedForCalculation }) => {
  return <DialogAnimationContext.Provider value={{ isExpandedForCalculation }}>{children}</DialogAnimationContext.Provider>;
};

This setup allows me to manage the expanded state for dimension calculations separately from the visible dialog.

Step 2: Calculation Container

Next, I add a CalculationDialogContainer, a secondary invisible container used for offscreen calculations.

const CalculationDialogContainer = styled.div`
  position: fixed;
  bottom: 0;
  left: 0;
  opacity: 0;
  max-width: ${({ maxWidth }) => `${maxWidth}px`};
  pointer-events: none;
  user-select: none;
`;

This container is fixed at the bottom of the screen, invisible, and non-interactive, ensuring it doesn't affect user interactions or layout.

Step 3: State Management

I introduce a new state variable, isExpandedForCalculation, to manage the expanded state for the calculation container.

const [isExpandedForCalculation, setIsExpandedForCalculation] = useState(isExpanded);

This allows the calculation container to be expanded and minimised independently of the visible dialog.

Step 4: Calculation Logic

I shift the dimension calculation logic to the invisible container instead of the original container, using calculationContainerRef to reference it.

useEffect(() => {
  const container = calculationContainerRef?.current;

  switch (dimensionCheckState) {
    // expand
    case 1:
      startTransition(() => {
        setIsExpandedForCalculation(true);
        setDimensionCheckState(2);
      });
      break;

    ...
});

This ensures dimensions are calculated in the invisible container, avoiding visual disruptions in the visible dialog.

Step 5: Minimise and Expand Functions

I introduce new functions, minimiseFn and expandFn, to handle the transition states smoothly. These custom functions override the default behavior in the DialogProvider.

const minimiseFn = useCallback(() => {
  setIsAnimating(false);
  setIsAnimatedExpanded(false);
  setDimensionCheckState(1);
}, []);

const expandFn = useCallback(() => {
  setIsAnimating(false);
  setIsAnimatedExpanded(true);
  setDimensionCheckState(1);
}, []);

These functions ensure the dialog’s state transitions are managed seamlessly. Instead of directly changing the isExpanded variable, the header component now directly calls the minimise and expand functions. This change is reflected in the DialogHeader component:

export default function DialogHeader({ children, expandedTitle }) {
  const { dialogId, isExpanded, expand, minimise } = useDialog();

  return (
    <DialogHeaderComponent id={`${dialogId}_label`}>
      <ExpandedState isVisible={isExpanded}>
        <Title>{expandedTitle ?? children}</Title>
        <IconButtons>
          <IconButton icon="chevron-down" onClick={() => minimise()} />
        </IconButtons>
      </ExpandedState>
      <MinimizedState isVisible={!isExpanded} onClick={() => expand()}>
        <Title>{children}</Title>
        <IconButtons>
          <IconButton icon="chevron-up" />
        </IconButtons>
      </MinimizedState>
    </DialogHeaderComponent>
  );
}

Step 6: Children Wrapping and Invisible Container Rendering

Finally, I wrap the children in DialogAnimationProvider within the CalculationDialogContainer, rendering the secondary invisible container for dimension calculations.

return (
  <>
    <AnimatedDialogContainer ref={containerRef} dimensions={dimensions} isAnimating={isAnimating}>
      <FixedContainer dimensions={expandedDimensions} isAnimating={isAnimating}>
        {children}
      </FixedContainer>
    </AnimatedDialogContainer>
    <CalculationDialogContainer ref={calculationContainerRef} maxWidth={maxWidth}>
      <DialogAnimationProvider isExpandedForCalculation={isExpandedForCalculation}>{children}</DialogAnimationProvider>
    </CalculationDialogContainer>
  </>
);

This setup ensures that the invisible container is used for all dimension calculations, improving the smoothness and reliability of the animation transitions.

Step 7: Adjusting DialogContainer

I wrap the children in DialogAnimationProvider within the CalculationDialogContainer. The CalculationDialogContainer is the secondary invisible container, used for offscreen calculations. By doing this, the children's expand/minimise state is affected by isExpandedForCalculation rather than isExpanded. Here’s how it works:

isExpanded: This state is used for the actual DOM when the dialog is visibly expanded or minimised.
isExpandedForCalculation: This state is used during the successive calculation cycle and only affects the DialogContainer when wrapped within DialogAnimationProvider.

export default function DialogContainer({ children }) {
  const { isExpanded } = useDialog();
  const dialogAnimation = useDialogAnimation();

  const isVisible = dialogAnimation?.isExpandedForCalculation ?? isExpanded;

  return (
    <DialogContainerComponent isVisible={isVisible}>
      {children}
    </DialogContainerComponent>
  );
}

This ensures that the invisible container is used for all dimension calculations, improving the smoothness and reliability of the animation transitions.

Try the Demo!

Now that you have a detailed understanding of the improvements and changes made in Part 4, it's time to see the implementation in action. You can try out the demo to experience the smooth and reliable transitions of the dialog component.

Check out the live demo below or access the whole source code for this approach on CodeSandbox.

Pros and Cons of This Approach

Before wrapping up, let's dive into the pros and cons of using the invisible container approach compared to the previous implementation in Part 3.

Pros

Eliminates Jank and Flicker: By performing dimension calculations in an invisible container, we avoid the visible jumps that occurred during transitions in Part 3, resulting in a smoother user experience.
Accurate Measurements: Just like the approach from Part 3, it allows for precise dimension calculations using getBoundingClientRect, ensuring the dialog transitions to the exact size needed.
Cleaner UI Transitions: The final dimensions are applied to the visible dialog in one go, ensuring a clean and seamless transition without intermediate visual states.
Separation of Concerns: By separating the visual state (isExpanded) from the calculation state (isExpandedForCalculation), we manage the dialog's transitions more effectively.

Cons

Increased Complexity: The introduction of an additional invisible container and context adds complexity to the codebase, making it harder to maintain.
Performance Overhead: Rendering the dialog twice (once invisibly for calculations and once visibly) can introduce performance overhead, especially with frequent content changes.
Initial Setup: The initial setup and understanding of this approach require more effort, as it involves additional state management and context usage.

While this approach addresses the primary concern of jank and flicker, it does come with trade-offs in terms of complexity and performance. However, the improved user experience and smooth transitions make it a compelling solution for creating a polished dialog component.

Conclusion and Next Steps

In Part 4, I introduced the invisible container approach to enhance the dialog's animation transitions, eliminating flicker and providing a smoother user experience. By performing dimension calculations offscreen and separating visual and calculation states, this approach addresses the primary concerns of the previous implementation.

Key Takeaways:

Eliminates Jank and Flicker: Offscreen calculations result in smoother transitions.
Accurate Measurements: Ensures precise dimension calculations.
Cleaner UI Transitions: Provides seamless visual transitions.
Increased Complexity: Adds complexity to the codebase.
Performance Overhead: Involves rendering the dialog twice.

Feel free to explore the code and interact with the demo to see how the invisible container approach effectively eliminates flickering and provides a polished user experience.

Thank you for following along this journey of refining the dialog component. I look forward to hearing your feedback and comments as they help in refining and improving the implementation further.

Creating a Smooth Transitioning Dialog Component in React (Part 3/4)

Anthony Tambrin — Tue, 16 Jul 2024 12:16:52 +0000

Part 3: Improving Animation Reliability

In Part 2, I enhanced our dialog component by adding smooth animations for minimise and expand actions using max-width and max-height. This approach ensured the dialog dynamically adapted to its content, providing fluid and natural transitions. However, one key limitation was the assumption that minimised dimensions are zero, which caused the transition to not scale down smoothly and look less natural.

Also in Part 2, I added DialogAnimation inside DialogContainer to animate DialogBody and DialogFooter individually. For Part 3, I've unified the animation to affect both components at a higher level, inside the Dialog component. This change simplifies the structure and eliminates the need for animate props in DialogBody and DialogFooter in preparation to the improvement that I was planning to make from the last approach.

Here are the changes I've made:

// src/components/FluidDialog/Dialog.js
// The children are now wrapped within DialogAnimation
<DialogComponent
  role="dialog"
  aria-labelledby={`${dialogId}_label`}
  aria-describedby={`${dialogId}_desc`}
  ref={rootRef}
  maxWidth={maxWidth}
>
  <DialogAnimation>{children}</DialogAnimation>
</DialogComponent>

// src/components/FluidDialog/DialogContainer.js
// The DialogAnimation has been removed
export default function DialogContainer({ children }) {
  const { isExpanded } = useDialog();
  return <DialogContainerComponent isVisible={isExpanded}>{children}</DialogContainerComponent>;
}

I'm eager to hear your thoughts on this approach and whether you find it an improvement. Your feedback will be invaluable in refining this component.

Improvement From Last Approach

In the last approach, the assumption that minimised dimensions are zero (max-width: 0, max-height: 0) caused the transition to not scale down smoothly. This is because the actual minimised dimensions are never zero, leading to the transition overcompensating and making the animation look less natural.

As an improvement, I'm going to calculate both expanded and minimised dimensions so that the DialogAnimation component can use those dimensions to reliably transition between the two states.

What Changes

Calculate Both Expanded and Minimised Dimensions: The DialogAnimation component will now calculate dimensions for both expanded and minimised states. This is crucial for ensuring the animation transitions smoothly between the correct dimensions.
Successive Render Cycles: To obtain accurate dimensions, the dialog needs to be expanded and minimised in successive render cycles. This allows the DOM element dimensions to be calculated using getBoundingClientRect.

What Remains

Fluid Height: The dialog still needs to hug the content correctly, so max-width and max-height need to be unset when the animation transition is not happening.

Step-by-Step Dimension Calculation

Here's the step-by-step process for calculating the dimensions (consider each numbered bullet represent the nth render cycle):

Expand the Dialog: The dialog is expanded first to measure its full size.
Calculate and Store Dimensions: The dimensions are calculated using getBoundingClientRect and stored as expandedDimensions.
Minimise the Dialog: The dialog is then minimised to measure its compact size.
Calculate and Store Dimensions: The dimensions are recalculated and stored as minimisedDimensions.
Prepare for Transition: The dialog is set to the correct state (either expanded or minimised) with max-width and max-height set to the current state dimensions, and the transition property unset.
Animate the Transition: Finally, max-width and max-height are set to the target state dimensions with the transition property enabled, initiating the animation.

Rewriting and Improving DialogAnimation

Now that I'm armed with that strategy, I'm going to rewrite (probably most of) the DialogAnimation.js code. I’ll explain it as I go, bear with me.

Imports and Constants

import { useState, useEffect, useRef, useTransition } from 'react';
import { styled } from 'styled-components';
import { useDialog } from './DialogContext';

const transitionSpeed = 0.3; // second

Nothing much changed here except that I've set a constant for the transition speed.

Component and State Initialization

export function DialogAnimation({ children }) {
  const containerRef = useRef(null);
  const { isExpanded, setIsExpanded, rootRef } = useDialog();
  const [isAnimatedExpanded, setIsAnimatedExpanded] = useState(isExpanded);
  const [_, startTransition] = useTransition();
  const [isAnimating, setIsAnimating] = useState(false);
  const [dimensions, setDimensions] = useState({ width: 0, height: 0 });
  const [minimisedDimensions, setMinimisedDimensions] = useState({
    width: 0,
    height: 0,
  });
  const [expandedDimensions, setExpandedDimensions] = useState({
    width: 0,
    height: 0,
  });
  const [dimensionCheckState, setDimensionCheckState] = useState(0);

I set up my state variables and refs. containerRef points to the dialog container. isExpanded and rootRef come from useDialog. I use state variables to track animation states and dimensions.

Here's a detailed breakdown of the variables and what they are used for:

containerRef: A reference to the dialog container DOM element. Used to access and manipulate the DOM directly for dimension calculations.
isExpanded: Tracks if the dialog is expanded.
rootRef: A reference to the root element of the dialog.
isAnimatedExpanded: Tracks the animated state of the dialog separately from isExpanded. This helps manage the animation timing and ensures smooth transitions.
isAnimating: A boolean state to indicate if an animation is in progress. This is used to conditionally apply transition properties.
dimensions: Stores the current dimensions (width and height) of the dialog. This is dynamically updated during the animation process.
minimisedDimensions: Stores the dimensions when the dialog is minimised. Calculated and stored to ensure smooth transitions to this state.
expandedDimensions: Stores the dimensions when the dialog is expanded. Calculated and stored to ensure smooth transitions to this state.
dimensionCheckState: Manages the state of the dimension calculation process. This state machine controls the sequence of expanding, measuring, minimising, and animating the dialog.

A Quick Note on useTransition

The useTransition hook in React is used to manage state transitions smoothly without blocking the UI. In DialogAnimation, startTransition is employed to handle state updates, supposedly ensuring that the dialog remains responsive during dimension calculations and animations. By marking updates as transitions, React prioritizes keeping the UI fluid and preventing rendering delays. For more details, check out the official useTransition documentation. (A colleague suggested this approach but I have yet benchmarked the performance. What do you think? Would it help in this case?)

First Effect Hook: Handling Expansion State Changes

  useEffect(() => {
    if (dimensionCheckState === 0 && isExpanded != isAnimatedExpanded) {
      const container = rootRef?.current;
      container.style.opacity = 0; // Make transparent to avoid flicker
      setIsAnimating(false);
      setIsAnimatedExpanded(isExpanded);
      setDimensionCheckState(1);
    }
  }, [isExpanded, isAnimatedExpanded]);

When the expansion state changes, I make the dialog transparent to avoid flickering, then update my state to start calculating dimensions.

Main Effect Hook: Managing Dimension Calculation and Animation

  useEffect(() => {
    const container = rootRef?.current;

    switch (dimensionCheckState) {
      // Expand
      case 1:
        startTransition(() => {
          setIsExpanded(true);
          setDimensionCheckState(2);
        });
        break;

      // Set expanded dimensions
      case 2:
        {
          const { width, height } = container.getBoundingClientRect();
          startTransition(() => {
            setExpandedDimensions({ width, height });
            setDimensionCheckState(3);
          });
        }
        break;

      // Minimise
      case 3:
        startTransition(() => {
          setIsExpanded(false);
          setDimensionCheckState(4);
        });
        break;

      // Set minimised dimensions
      case 4:
        {
          const { width, height } = container.getBoundingClientRect();
          startTransition(() => {
            setMinimisedDimensions({ width, height });
            setIsExpanded(true);
            setDimensionCheckState(5);
          });
        }
        break;

      // Prepare animation
      case 5:
        setIsAnimating(true);
        setDimensions(
          isAnimatedExpanded ? minimisedDimensions : expandedDimensions
        );
        setTimeout(() => {
          startTransition(() => setDimensionCheckState(6));
        });
        break;

      // Animate
      case 6:
        startTransition(() => {
          setDimensions(
            isAnimatedExpanded ? expandedDimensions : minimisedDimensions
          );
          setDimensionCheckState(0);
        });
        container.style.opacity = 1;

        // Finalize animation state after transition
        setTimeout(() => {
          startTransition(() => {
            setIsExpanded(isAnimatedExpanded);
            setIsAnimating(false);
          });
        }, transitionSpeed * 1000);
        break;

      // Idle
      default:
        break;
    }
  }, [dimensionCheckState, startTransition]);

This is where the magic happens. The effect hook manages the entire animation lifecycle through a switch case:

Expand the dialog.
Measure and store expanded dimensions.
Minimise the dialog.
Measure and store minimised dimensions.
Prepare for animation by setting current dimensions.
Perform the animation and reset states.

Rendering the Animated Container

  return (
    <AnimatedDialogContainer
      ref={containerRef}
      dimensions={dimensions}
      isAnimating={isAnimating}
    >
      <FixedContainer dimensions={expandedDimensions} isAnimating={isAnimating}>
        {children}
      </FixedContainer>
    </AnimatedDialogContainer>
  );
}

Here, I render the AnimatedDialogContainer and FixedContainer, passing the necessary props to manage dimensions and animation states.

Styled Components

const AnimatedDialogContainer = styled.div`
  overflow: hidden;
  transition: ${({ isAnimating }) =>
    isAnimating
      ? `max-width ${transitionSpeed}s, max-height ${transitionSpeed}s`
      : undefined};
  max-width: ${({ dimensions, isAnimating }) =>
    isAnimating ? `${dimensions.width}px` : undefined};
  max-height: ${({ dimensions, isAnimating }) =>
    isAnimating ? `${dimensions.height}px` : undefined};
`;

const FixedContainer = styled.div`
  width: ${({ dimensions, isAnimating }) =>
    isAnimating ? `${dimensions.width}px` : '100%'};
  height: ${({ dimensions, isAnimating }) =>
    isAnimating ? `${dimensions.height}px` : '100%'};
`;

AnimatedDialogContainer: Manages the transition properties based on whether an animation is happening. The max-width and max-height are unset when it's not animating so the dialog can hug thecontent correctly.
FixedContainer: Ensures the minimised content maintains its dimensions during the animation to avoid appearing squashed.

Try the Demo!

You can access the whole source code for this approach on CodeSandbox.

You can also see a live preview of the implementation below. Play around with the dynamic adaptability of the dialog and also pay close attention to the occasional (or frequent?) flickering jank when you minimise and expand the dialog.

Pros and Cons of This Approach

Before we wrap up, let's dive into the pros and cons of this approach compared to the one in Part 2.

Pros

Accurate Transitions: By calculating both expanded and minimised dimensions, this approach ensures the dialog transitions to the exact right size, making the animation smooth and visually appealing.
Clean Structure: Wrapping the DialogAnimation around the children of the Dialog component simplifies the code structure, eliminating the need for individual animate props in DialogBody and DialogFooter.
Dynamic Adaptability: The dialog adapts to content changes more reliably, as dimensions are recalculated during specific render cycles.

Cons

Increased Complexity: Managing state transitions and dimension calculations in multiple steps adds complexity to the codebase.
Performance Overhead: Expanding and minimising the dialog in successive render cycles could introduce performance overhead, particularly with frequent (complex) content changes.
Jank/Flicker During Calculation: The biggest drawback is the introduction of jank or flicker when calculating dimensions. The dialog needs to be expanded and minimised to measure with getBoundingClientRect, causing visible jumps in the UI.
Initial Calculation Delay: The initial dimension calculation process involves multiple steps, which may introduce a slight delay before the animation starts.

Conclusion and Next Steps

In Part 3, I improved the DialogAnimation component to calculate both expanded and minimised dimensions for more accurate and visually appealing transitions. This approach involved using successive render cycles to expand and minimise the dialog, allowing for precise dimension calculations. However, it also introduced some complexity and potential performance issues, particularly the jank or flicker during dimension calculations.

Key Takeaways:

Accurate Transitions: Calculating both expanded and minimised dimensions ensures smooth animations.
Jank/Flicker Issue: Expanding and minimising the dialog for dimension calculations can cause visible UI jumps.

Next, in Part 4, I'll tackle the flickering issue by introducing a secondary, invisible container exclusively for dimension calculations. This approach aims to eliminate the jank while maintaining smooth and reliable transitions. Stay tuned as we continue to refine and perfect the dialog component!

I invite feedback and comments from fellow developers to help refine and improve this approach. Your insights are invaluable in making this proof of concept more robust and effective.

Creating a Smooth Transitioning Dialog Component in React (Part 2/4)

Anthony Tambrin — Mon, 15 Jul 2024 12:34:58 +0000

Part 2: Introducing Animation for Minimise/Expand Transitions

In Part 1, I laid the foundation for our dialog component with basic minimise and expand functionality. Now, it's time to add smooth animations to these transitions. After brainstorming several CSS properties, including transform: scale(), zoom, and width and height, I decided to use max-width and max-height for the animation.

Here’s why:

Using max-width and max-height for animations has several advantages:

Fluidity: These properties allow the dialog to adapt dynamically to the content size, creating a smooth and natural animation.
Control: They offer precise control over the dimensions during transitions, ensuring the dialog does not overflow its container.
Consistency: When dealing with fluid content that may vary in size, max-width and max-height ensure the dialog transitions remain consistent with the content's natural dimensions.

While transform and zoom are other potential options, they have some drawbacks in this context:

Scale Transform: Although performant, scaling affects both the dialog and its content, leading to possible distortion or undesirable scaling effects on inner elements.
Zoom: Similar to transform scale, zoom can lead to pixelation or blurriness, especially on non-vector elements, and doesn't provide as precise control over dimensions as max-width and max-height.
Width and Height: Directly animating width and height can be less performant due to layout recalculations that the browser must perform, which can lead to jankier animations compared to using max-width and max-height.

These benefits make max-width and max-height ideal choices for implementing fluid and efficient dialog transitions in React.

Introducing the DialogAnimation Component

My first thought was to provide the option to toggle animations allows for greater flexibility, accommodating different user preferences and performance considerations. Animations can be resource-intensive and may not be desirable in all contexts, such as on lower-powered devices or when a simpler user experience is preferred. By making animations optional, the component can be easily adapted to various use cases without sacrificing performance or usability.

So... to make the animation an optional feature (while resisting the temptation to implement prefers-reduced-motion media query), I introduced a DialogAnimation component.

Here’s a boilerplate of the DialogAnimation component:

// src/components/FluidDialog/DialogAnimation.js
import { useState, useEffect, useRef } from 'react';
import { styled } from 'styled-components';
import { useDialog } from './DialogContext';

export function DialogAnimation({ children }) {
  // Animation logic here
  return <AnimatedDialogContainer>{children}</AnimatedDialogContainer>;
}

const AnimatedDialogContainer = styled.div`
  // Styled component logic here
`;

Updating the DialogContainer Component

To use the DialogAnimation component, I updated the DialogContainer component to include a boolean prop called animate. When animate is set to true, the DialogContainer will return the children wrapped in DialogAnimation, which supports animation transitions.

Here’s the updated code for DialogContainer:

// src/components/FluidDialog/DialogContainer.js
import { styled } from 'styled-components';
import { useDialog } from './DialogContext';
import { DialogAnimation } from './DialogAnimation';

export default function DialogContainer({ animate, children }) {
  const { isExpanded } = useDialog();

  if (animate) {
    return <DialogAnimation>{children}</DialogAnimation>;
  }

  return (
    <DialogContainerComponent isVisible={isExpanded}>
      {children}
    </DialogContainerComponent>
  );
}

const DialogContainerComponent = styled.div`
  display: ${({ isVisible }) => (isVisible ? undefined : 'none')};
`;

To ensure this works, I set the animate prop to true for both DialogBody and DialogFooter since these are the components whose content I want to "hide" when minimised.

// src/components/FluidDialog/DialogBody.js
<DialogContainer animate>
  <DialogBodyContent id={`${dialogId}_desc`}>{children}</DialogBodyContent>
</DialogContainer>

// src/components/FluidDialog/DialogBody.js
<DialogContainer animate>
  <DialogFooterContent>{children}</DialogFooterContent>
</DialogContainer>

Building the DialogAnimation Component

Now, let's dive into building the DialogAnimation component. This component is essential for managing the smooth transitions between the expanded and minimised states of the dialog. It dynamically adjusts max-width and max-height based on the dialog's state and uses hooks to manage the animation lifecycle. This approach ensures fluid and smooth transitions, although it comes with its own set of pros and cons, which I'll discuss later.

Here's how this approach works:

Calculating Expanded Dimensions: The component calculates the dialog's expanded dimensions using the DOM's getBoundingClientRect() method, which provides the most accurate dimensions.
Timing the Calculation: The calculation occurs when the dialog is minimised. This ensures that when it expands, it does so to the correct size.
Detecting State Changes: The calculation is triggered by changes in the isExpanded state. To track these changes, the component compares isExpanded with isAnimatedExpanded, recalculating dimensions whenever there's a difference. This also allows the component to respond to any content changes that affect the dialog's height.
Assumptions for Minimised State: When the dialog is minimised, it assumes max-width and max-height are zero. This approach has some drawbacks, which I'll discuss later.
Applying CSS Transitions: Once the dimensions are calculated, the component sets max-width and max-height accordingly and relies on CSS to smoothly transition between these properties.

And here's how I built the DialogAnimation component step-by-step:

Setting Up the Basic Structure

First, I set up the basic structure of the component, importing necessary hooks and styled-components:

import { useState, useEffect, useRef } from 'react';
import { styled } from 'styled-components';
import { useDialog } from './DialogContext';

export function DialogAnimation({ children }) {
  const { isExpanded, rootRef } = useDialog();
  const containerRef = useRef(null);
  const [isExpandSettled, setIsExpandSettled] = useState(isExpanded);
  const [isAnimatedExpanded, setIsAnimatedExpanded] = useState(isExpanded);
  const [expandedDimensions, setExpandedDimensions] = useState(undefined);

Calculating Dimensions

To handle the dimensions for the expanded state, I created a helper function. This function measures the container’s dimensions and updates the state accordingly.

updateExpandedDimensions: Measures the dimensions when the dialog is expanded and the updates the state if they haven't been set yet or if the current width and height differ from the stored values. This prevents unnecessary updates and re-renders, optimizing performance.

const updateExpandedDimensions = (
  containerRef,
  expandedDimensions,
  setExpandedDimensions
) => {
  const container = containerRef?.current;
  if (!container) return;

  const { width, height } = container.getBoundingClientRect();
  if (
    !expandedDimensions ||
    width !== expandedDimensions.width ||
    height !== expandedDimensions.height
  ) {
    setExpandedDimensions({ width, height });
  }
};

Managing State and Effects

Next, I used several useEffect hooks to manage the state and animation lifecycle:

Step 1: Handle State Changes: This hook updates dimensions and state when isExpanded changes.

Why setTimeout?: The setTimeout ensures that the state update for isAnimatedExpanded occurs after the dimension calculation, allowing for a smooth transition.
isAnimatedExpanded: Tracks the animation state separately from the expansion state to manage the timing of transitions.

useEffect(() => {
  if (isExpanded !== isAnimatedExpanded) {
    if (!isExpanded) {
      updateExpandedDimensions(
        containerRef,
        expandedDimensions,
        setExpandedDimensions
      );
    }
    setTimeout(() => {
      setIsAnimatedExpanded(isExpanded);
    });
  }
}, [containerRef?.current, rootRef?.current, isExpanded, isAnimatedExpanded]);

Step 2: Set Initial Dimensions: This hook sets the initial dimensions and handles transition end events.

Why handleTransitionEnd?: This function sets setIsExpandSettled to true after the transition completes. This is crucial for unsetting max-width and max-height, allowing the dialog to grow and shrink according to the content size.
setIsExpandSettled: Manages whether the expansion transition has completed, ensuring the dialog remains fluid post-transition.

useEffect(() => {
  const container = containerRef?.current;
  if (!container) return;

  if (!expandedDimensions) {
    updateExpandedDimensions(
      containerRef,
      expandedDimensions,
      setExpandedDimensions
    );
  }

  const handleTransitionEnd = () => {
    if (isExpanded) {
      setIsExpandSettled(true);
    }
  };

  container.addEventListener('transitionend', handleTransitionEnd);

  return () => {
    container.removeEventListener('transitionend', handleTransitionEnd);
  };
}, [containerRef?.current, rootRef?.current, expandedDimensions, isExpanded]);

Step 3: Update Settled State: This hook resets the settled state when the dialog is minimised.

Resetting Settled State: Ensures the dialog is ready for the next transition by resetting the settled state when minimised.

useEffect(() => {
  if (!isExpanded) {
    setIsExpandSettled(false);
  }
}, [isExpanded]);

Try the Demo!

You can access the whole source code on CodeSandbox.

You can also see a live preview of the implementation below. Play around with the dynamic adaptability of the dialog and also pay close attention to how the transition to minimised state looks a bit strange.

Pros and Cons of This Approach

Before wrapping up, let's dive into the pros and cons of this approach of calculating expanded dimensions to transition max-width and max-height for our dialog animation. Understanding these will help us refine and optimise the approach in future steps.

Pros

Fluid Transitions: The use of max-width and max-height ensures the dialog grows and shrinks smoothly, offering a natural and visually appealing experience.
Dynamic Adaptability: By dynamically calculating dimensions, the dialog adjusts to various content sizes, making it highly adaptable and versatile for different use cases.
Simplicity: The implementation is straightforward, leveraging CSS transitions and React hooks, making it easy to understand, implement, and maintain.
Accurate Measurements: Using getBoundingClientRect() provides precise dimension calculations, crucial for accurate and seamless animations.

Cons

Assumption of Minimised Dimensions: The assumption that minimised dimensions are zero (max-width: 0, max-height: 0) can cause the transition to not scale down smoothly. The actual minimised dimensions are not zero, leading to the transition overcompensating and making the animation look less natural.

Conclusion and Next Steps

In Part 2, I enhanced our dialog component by adding smooth animations for minimise and expand actions. Using max-width and max-height, I ensured the dialog dynamically adapts to its content, providing fluid and natural animations.

Key Takeaways:

max-width and max-height: Chosen for their fluidity, control, and consistency.
DialogAnimation Component: Manages the transition logic and dynamically adjusts dimensions.
State Management: Utilises useState and useEffect hooks to handle state changes and lifecycle events.

Next, in Part 3, I’ll tackle the transition overcompensation issue with the current approach and improve animation reliability. Stay tuned as we continue to refine and optimise the dialog component.

I invite feedback and comments from fellow developers to help refine and improve this approach. Your insights are invaluable in making this proof of concept more robust and effective.

Creating a Smooth Transitioning Dialog Component in React (Part 1/4)

Anthony Tambrin — Sun, 14 Jul 2024 10:31:15 +0000

Part 1: Setting Up the Basic Dialog Component with Minimise/Expand Functionality

Welcome to the first part of my four-part series on creating a responsive dialog component in React. In this series, I'll explore different approaches to achieve smooth animation transitions while maintaining the dialog's fluid dimensions. In this initial part, I'll set up the basic dialog component with minimise and expand functionality.

Please note that accessibility and responsive design are not included as part of the considerations in this series. The primary focus is on creating a reusable dialog component with smooth animation transitions.

This series is part of a proof of concept I've been working on, aimed at discussing and refining techniques for animating UI components. I invite feedback and insights from fellow developers to validate my approach or suggest improvements.

Setting Up the Basic Dialog Component

Let's start by creating a highly reusable dialog component that supports minimising and expanding. I'll use the compositional pattern to ensure the dialog can adapt to changing content.

File Structure:

src/
  components/
    FluidDialog/
      Dialog.js
      DialogContext.js
      DialogHeader.js
      DialogBody.js
      DialogFooter.js
      DialogContainer.js
      index.js
  App.js
  index.js

Step 1: Dialog Context

First, I'll create a context to manage the state of our dialog component.

Key Points:

The DialogContext will hold the state and provide functions to toggle the dialog between minimised and expanded states.
The DialogProvider component initialises the state and provides it to the dialog components via context.

// src/components/FluidDialog/DialogContext.js
import { createContext, useContext, useId, useState } from 'react';

const DialogContext = createContext();

export function DialogProvider({
  rootRef,
  isExpandedByDefault,
  children,
  maxWidth,
}) {
  const dialogId = useId();
  const [isExpanded, setIsExpanded] = useState(isExpandedByDefault);

  return (
    <DialogContext.Provider
      value={{ dialogId, rootRef, isExpanded, setIsExpanded, maxWidth }}
    >
      {children}
    </DialogContext.Provider>
  );
}

export function useDialog() {
  return useContext(DialogContext);
}

Step 2: Dialog Component

Next, I'll create the main dialog component that uses the context to handle expansion and minimisation.

Key Points:

The Dialog component initialises the context provider with relevant props.
The DialogComponent styled-component handles the basic styling and layout of the dialog.

// src/components/FluidDialog/Dialog.js
import { useRef } from 'react';
import { styled } from 'styled-components';
import { DialogProvider } from './DialogContext';

export default function Dialog({
  id,
  isExpandedByDefault = true,
  maxWidth = 400,
  children,
}) {
  const rootRef = useRef(null);
  return (
    <DialogProvider
      dialogId={id}
      rootRef={rootRef}
      isExpandedByDefault={isExpandedByDefault}
    >
      <DialogComponent
        role="dialog"
        aria-labelledby={`${id}_label`}
        aria-describedby={`${id}_desc`}
        ref={rootRef}
        maxWidth={maxWidth}
      >
        {children}
      </DialogComponent>
    </DialogProvider>
  );
}

const DialogComponent = styled.section`
  max-width: ${({ maxWidth }) => (maxWidth ? `${maxWidth}px` : undefined)};
  position: absolute;
  right: 16px;
  bottom: 16px;
  border: 1px solid #ccc;
  border-radius: 6px;
  box-shadow: 0 0 8px rgba(0, 0, 0, 0.35);
  overflow: hidden;
`;

Step 3: Additional Components

I'll create additional components for the dialog header, body, footer, and container to ensure modularity and reusability.

Key Points:

DialogHeader includes a button to toggle between minimised and expanded states using the context.
DialogContainer wraps the body and footer content to automatically hide them when the isExpanded value is changed.
DialogBody and DialogFooter components are simple containers for the dialog's content.

// src/components/FluidDialog/DialogHeader.js
import { styled } from 'styled-components';
import { IconButton } from '../IconButton';
import { useDialog } from './DialogContext';

export default function DialogHeader({ children, expandedTitle }) {
  const { dialogId, isExpanded, setIsExpanded } = useDialog();

  return (
    <DialogHeaderComponent id={`${dialogId}_label`}>
      <ExpandedState isVisible={isExpanded}>
        <Title>{expandedTitle ?? children}</Title>
        <IconButtons>
          <IconButton
            icon="chevron-down"
            onClick={() => setIsExpanded(false)}
          />
        </IconButtons>
      </ExpandedState>
      <MinimizedState
        isVisible={!isExpanded}
        onClick={() => setIsExpanded(true)}
      >
        <Title>{children}</Title>
        <IconButtons>
          <IconButton icon="chevron-up" />
        </IconButtons>
      </MinimizedState>
    </DialogHeaderComponent>
  );
}

const DialogHeaderComponent = styled.div``;

const ExpandedState = styled.header`
  transition: opacity 0.3s;
  opacity: ${({ isVisible }) => (isVisible ? 1 : 0)};
  pointer-events: ${({ isVisible }) => (isVisible ? 'all' : 'none')};
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  background: #f3f3f3;
  display: flex;
  flex-direction: row;
`;

const MinimizedState = styled.header`
  transition: opacity 0.3s;
  opacity: ${({ isVisible }) => (isVisible ? 1 : 0)};
  pointer-events: ${({ isVisible }) => (isVisible ? 'all' : 'none')};
  background: #f3f3f3;
  display: flex;
  flex-direction: row;
  cursor: pointer;
`;

const Title = styled.span`
  flex-grow: 1;
  text-align: left;
  display: flex;
  align-items: center;
  padding: 0 16px;
`;

const IconButtons = styled.div``;

// src/components/FluidDialog/DialogContainer.js
import { styled } from 'styled-components';
import { useDialog } from './DialogContext';

export default function DialogContainer({ children }) {
  const { isExpanded } = useDialog();

  return (
    <DialogContainerComponent isVisible={isExpanded}>
      {children}
    </DialogContainerComponent>
  );
}

const DialogContainerComponent = styled.div`
  display: ${({ isVisible }) => (isVisible ? undefined : 'none')};
`;

// src/components/FluidDialog/DialogBody.js
import { styled } from 'styled-components';
import DialogContainer from './DialogContainer';
import { useDialog } from './DialogContext';

export default function DialogBody({ children }) {
  const { dialogId } = useDialog();

  return (
    <DialogBodyComponent>
      <DialogContainer>
        <DialogBodyContent id={`${dialogId}_desc`}>
          {children}
        </DialogBodyContent>
      </DialogContainer>
    </DialogBodyComponent>
  );
}

const DialogBodyComponent = styled.div``;

const DialogBodyContent = styled.div`
  padding: 8px 16px;
`;

// src/components/FluidDialog/DialogFooter.js
import { styled } from 'styled-components';
import DialogContainer from './DialogContainer';

export default function DialogFooter({ children }) {
  return (
    <DialogFooterComponent>
      <DialogContainer>
        <DialogFooterContent>{children}</DialogFooterContent>
      </DialogContainer>
    </DialogFooterComponent>
  );
}

const DialogFooterComponent = styled.div`
  background: #f3f3f3;
`;

const DialogFooterContent = styled.div`
  padding: 8px 16px;
`;

Step 4: Putting It All Together

Finally, I'll import and use the dialog component in the main app.

Key Points:

The App component includes the Dialog with its header, body, and footer components.
This setup ensures the dialog is ready for further enhancements and animations in the upcoming parts.

// src/App.js
import React from 'react';
import Dialog from './components/FluidDialog/Dialog';
import DialogHeader from './components/FluidDialog/DialogHeader';
import DialogBody from './components/FluidDialog/DialogBody';
import DialogFooter from './components/FluidDialog/DialogFooter';

function App() {
  return (
    <div className="App">
      <Dialog>
        <DialogHeader>My dialog/DialogHeader>
        <DialogBody>This is the content of the dialog.</DialogBody>
        <DialogFooter>This is the footer of the dialog.</DialogFooter>
      </Dialog>
    </div>
  );
}

export default App;

// src/index.js
import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

You can access the whole source code on CodeSandbox.

You can also see a live preview of the implementation:

Conclusion

In this first part, I've set up a basic dialog box in React with minimise and expand functionality. This foundational component will serve as the basis for further enhancements in the upcoming articles. The dialog component is designed to hug its content and adapt to changes, making it highly reusable and flexible.

Stay tuned for Part 2, where I'll delve into adding animations to the dialog transitions, exploring different options to achieve smooth effects.

I invite feedback and comments from fellow developers to help refine and improve this approach. Your insights are invaluable in making this proof of concept more robust and effective.