DEV Community: Ivor

Triggering a Popover with Pure CSS (No JavaScript Required)

Ivor — Thu, 30 May 2024 10:12:42 +0000

When building interactive web elements, it's common to rely on JavaScript for tasks like triggering popovers. However, CSS alone can often suffice for simple interactions. In this post, we'll demonstrate how to create a popover using only CSS. This approach is intended for demonstration purposes and may not replace JavaScript for more complex scenarios.

The Popover API

Before diving into the CSS-only solution, it's worth noting that modern browsers support the Popover API for handling popovers. This API provides a more robust and accessible way to manage popups, but for educational purposes, we'll explore a pure CSS approach.

HTML Structure

Here's the HTML structure we'll use:

<label id="acts-as-button" for="trigger">
  <input type="checkbox" name="trigger" id="trigger">
  Open
</label>

<div id="popover">
  <h1>Popover</h1>
  <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Velit, labore!</p>
</div>

In this setup:

A hidden checkbox (#trigger) controls the state of the popover.
A label (#acts-as-button) acts as a button to toggle the checkbox.
A div (#popover) contains the popover content.

CSS Styling

Next, we'll apply CSS to style the button and popover, and to control the popover's visibility based on the checkbox state.

#acts-as-button {
  background: orange;
  color: #845704;
  padding: 0.5rem 1rem;
  display: inline-block;
  cursor: pointer;
  width: fit-content;
  user-select: none;
}

#acts-as-button:hover,
#acts-as-button:has(#trigger:checked) {
  background: darkorange;
}

#trigger {
  display: none;
}

#popover {
  display: none;
  background-color: lightgrey;
  width: 300px;
  padding: 1rem;
  h1,
  p {
    margin: 0;
  }
  h1 {
    margin-bottom: 0.5rem;
  }
}

#acts-as-button:has(#trigger:checked) ~ #popover {
  display: block;
}

#acts-as-button: Styled to look like a button, with a pointer cursor and a background color.
#popover: Initially hidden (display: none), with a light grey background and padding.
#acts-as-button:has(#trigger:checked) ~ #popover: Uses the :has pseudo-class to display the popover when the checkbox is checked.

Explanation

Button Styling: The label styled as a button is clickable, which toggles the checkbox.
Popover Visibility: The :has pseudo-class is used to target the label and check if it contains a checked checkbox. When the checkbox is checked, the popover's display property is set to block.

This method leverages CSS to achieve a simple popover effect without JavaScript. However, remember that this approach is mainly for demonstration. For more robust and accessible solutions, consider using the Popover API or JavaScript.

Conclusion

Creating popovers with pure CSS is a great way to understand CSS capabilities and limitations. While this method can be useful for simple cases, for production-ready applications, combining CSS with JavaScript or using built-in browser APIs is recommended for better control and accessibility.

Understanding the Importance of @Injectable in NestJS

Ivor — Fri, 10 May 2024 10:36:38 +0000

When we dive into the world of modern web development, especially with frameworks like NestJS, we encounter a lot of concepts that are both powerful and a bit complex to grasp at first. One of these concepts is Dependency Injection (DI), a design pattern used extensively in building scalable and easily maintainable applications. In NestJS, this pattern is beautifully simplified through the use of decorators like @Injectable. Let's explore how this little piece of code makes our development life easier.

The Basics: What is `@Injectable`?

In simple terms, when you annotate a class with @Injectable(), you are essentially storing metadata using the reflect-metadata library, then when you add the class to the providers array you're telling NestJS: "Hey, please manage this class for me!" What does that mean? It means that NestJS will take care of creating an instance of this class and manage its entire lifecycle, based on the scope you define—singleton, request, or transient. But there’s more to it.

Consider a simple service in a NestJS app, like CarService:

export class CarService {
  getMake(): string {
    return 'Tesla';
  }
}

Without following NestJS's conventions, you might end up manually creating an instance of CarService inside your controllers or other services. However, this approach is not just cumbersome but also contrary to the principles of good software architecture that NestJS advocates.

The Right Way: Leveraging DI

Instead of manually handling the object lifecycle, you should lean on NestJS's powerful DI system. By marking CarService as @Injectable and registering it in a module, NestJS handles its instantiation and ensures that it's ready to be injected wherever it's needed:

@Injectable()
export class CarService {
  getMake(): string {
    return 'Tesla';
  }
}

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService, CarService /* register as a provider */],
})
export class AppModule {}

Now, CarService can be easily injected into any controller or service without the need to manually create an instance:

@Controller()
export class AppController {
  constructor(
    private readonly appService: AppService,
    private readonly carService: CarService,
  ) {}

  @Get()
  getHello(): string {
    console.log(this.carService.getMake());
    return this.appService.getHello();
  }
}

What If You Forget `@Injectable`?

Interestingly, even if you don’t explicitly use @Injectable() in your classes, NestJS's DI mechanism might still handle the injection correctly if the class doesn’t depend on other providers. However, this works until it doesn't—especially when your classes start having dependencies of their own.

For instance, if CarService requires LoggerService, you must decorate CarService with @Injectable() to ensure that LoggerService is properly injected:

@Injectable()
export class LoggerService {
  log(message: string): void {
    console.log(message);
  }
}

export class CarService {
  constructor(private readonly loggerService: LoggerService) {}

  getMake(): string {
    console.log(this.loggerService); // 💣💥
    return 'Tesla';
  }
}

If CarService is not properly decorated with @Injectable, this.loggerService would be undefined.

Conclusion: Embrace the Simplicity

NestJS's DI system is robust and designed to simplify your development process. By using @Injectable(), you ensure that your services are properly managed and that dependencies are handled correctly. This not only makes your code cleaner and more modular but also aligns with best practices that allow for greater scalability and easier maintenance.

So, next time you’re setting up services in your NestJS application, remember the importance of @Injectable(). It’s a small annotation that carries a lot of weight, making your coding journey much smoother and enjoyable. Happy coding!

Designing React Hooks for Flexibility

Ivor — Tue, 23 Apr 2024 23:57:17 +0000

As developers, we constantly seek patterns and practices that enhance our code's efficiency, reusability, and maintainability. A recent Twitter discussion I engaged in highlighted two methods for managing volume state in media players using React Hooks.

Because I believe this approach significantly enhances reusability across various media players, I will explore why adopting a flexible hook interface is beneficial. This post contrasts two methodologies and demonstrates how thoughtfully crafted hooks can be effectively utilized in multiple applications.

The Pitfall of Inflexible Interfaces

The discussion featured two examples. Example A depicted useVolume tightly coupled to the useVideoPlayer hook. This design limits useVolume to the video player, preventing its independent use or integration with other player hooks like useAudioPlayer.

In contrast, Example B presented useVolume as a standalone hook that accepts a player object. While aligning with React's core principles, this design challenges the Interface Segregation Principle (ISP). ISP advocates that no client should be forced to depend on methods it does not use, suggesting that useVolume should not need player-specific knowledge.

Why Flexibility Matters

Reusability: A standalone useVolume hook can be seamlessly reused with different media players, eliminating the need to rewrite or duplicate logic.
Separation of Concerns: Isolating volume control from player logic enhances code manageability.
Testability: Independent hooks simplify testing by encapsulating their logic.

Designing for Reusability

Recognizing the need for better interface segregation, I proposed an interface where useVideoPlayer and useVolume operate independently yet communicate effectively when necessary. Here's the improved interface demonstrated through a demo:



const { isPlaying, pause, play, player, onChangeVolume } = useVideoPlayer();
const { setVolume, volume, mute, unmute } = useVolume();

Here's how the hooks are implemented:



const useVideoPlayer = () => {
  const [isPlaying, setIsPlaying] = useState(false);
  const [playerVolume, setPlayerVolume] = useState(0);
  const videoRef = useRef();

  const play = () => setIsPlaying(true);
  const pause = () => setIsPlaying(false);

   // This code can be improved, this is just for demo purposes
  useEffect(() => {
    // sets volume
    videoRef.current.volume = playerVolume / 100;
    // play/pause programatically  
    isPlaying ? videoRef.current.play() : videoRef.current.pause()
  }, [playerVolume, isPlaying]);

  const player = (<video ref={videoRef} width="400" controls>
    <source src="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4" type="video/mp4" />
  </video>);

  return {
    isPlaying,
    play,
    pause,
    player,
    onChangeVolume: (volume) => setPlayerVolume(volume),
  };
};



const useVolume = (initialVolume = 50) => {
  const [volume, setVolume] = useState(initialVolume);

  const mute = () => setVolume(0);
  const unmute = () => setVolume(50);

  return {
    volume,
    setVolume,
    mute,
    unmute,
  };
};

And the component that uses both hooks:



function VideoPlayer() {
  const { isPlaying, pause, play, player, onChangeVolume } = useVideoPlayer();
  const { setVolume, volume, mute, unmute } = useVolume();

  useEffect(() => {
    onChangeVolume(volume);
  }, [volume]);

  return (
    <div className='App'>
      <button onClick={isPlaying ? pause : play}>
        {isPlaying ? 'Pause' : 'Play'}
      </button>
      <input type="range" min="0" max="100" value={volume}
             onChange={(e) => setVolume(parseInt(e.target.value, 10))} />
      <button onClick={mute}>Mute</button>
      <button onClick={unmute}>Unmute</button>
      {player}
      <h1>Player Volume: {volume}</h1>
    </div>
  );
}

This design respects ISP by allowing each hook to be consumed independently, without assuming the presence of the other. It provides a clean separation that facilitates better modularity and reusability, ensuring that components only interact with the functionalities they require.

Conclusion

The flexibility of a hook is determined by how well it can operate in different contexts. By embracing flexibility in our hook designs, we make them more reusable and adaptable, leading to a cleaner and more efficient codebase. Designing with reusability in mind is essential, whether you're building hooks for video or audio players or any other functionality. Let's write code that stands the test of time and adaptability.

DEV Community: Ivor

Triggering a Popover with Pure CSS (No JavaScript Required)

The Popover API

HTML Structure

CSS Styling

Explanation

Conclusion

Understanding the Importance of @Injectable in NestJS

The Basics: What is @Injectable?

The Right Way: Leveraging DI

What If You Forget @Injectable?

Conclusion: Embrace the Simplicity

Designing React Hooks for Flexibility

The Pitfall of Inflexible Interfaces

Why Flexibility Matters

Designing for Reusability

Conclusion

The Basics: What is `@Injectable`?

What If You Forget `@Injectable`?