home / skills / harborgrid-justin / lexiflow-premium / dependency-injection-patterns

dependency-injection-patterns skill

/frontend/.github-skills/dependency-injection-patterns

This skill helps you implement dependency injection patterns in React by providing a DI container, enabling mockable services, and safer testing.

npx playbooks add skill harborgrid-justin/lexiflow-premium --skill dependency-injection-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

578 B

---
name: dependency-injection-patterns
description: Decouple business logic from UI using Inversion of Control with Context and Hooks.
---

# Dependency Injection Patterns in React

## Summary
Decouple business logic from UI using Inversion of Control with Context and Hooks.

## Key Capabilities
- Inject service implementations.
- Mock dependencies.
- Manage service lifecycles.

## PhD-Level Challenges
- Prevent Context hell.
- Ensure type safety.
- Avoid re-renders.

## Acceptance Criteria
- Provide DI container.
- Demonstrate hot-swapping.
- Show improved testability.

Overview

This skill teaches dependency injection patterns for React to decouple business logic from UI by applying Inversion of Control with Context and Hooks. It shows how to inject and swap service implementations, mock dependencies for tests, and manage service lifecycles for a premium legal management platform. The focus is practical patterns that reduce coupling and improve maintainability.

How this skill works

The skill provides a lightweight DI container implemented with React Context and custom Hooks. Components request services via hooks that resolve implementations from the container, enabling hot-swapping or mocking without changing component code. Lifecycle hooks ensure services are instantiated and disposed predictably to avoid resource leaks and minimize re-renders.

When to use it

When UI components should not contain business logic or API calls
When multiple implementations of a service must be swapped at runtime
When writing unit or integration tests that require mockable dependencies
When managing long-lived resources that need controlled initialization and disposal
When scaling a component library across teams to enforce consistent behavior

Best practices

Keep Context providers as narrow as possible to avoid Context hell and unnecessary re-renders
Prefer stable hook signatures and memoized service instances for type safety and performance
Expose only the minimal API from each service to reduce coupling
Use factory functions for service construction to enable dependency graphs and lazy instantiation
Provide clear testing helpers that swap implementations at the provider level

Example use cases

Injecting an HTTP client service so components remain agnostic to Axios, fetch, or a custom client
Hot-swapping a billing service between sandbox and production implementations without touching UI code
Replacing authentication and authorization services with mocks in unit tests to validate UI flows
Managing a document indexing service lifecycle for a legal document viewer to control memory and subscriptions
Sharing business rules across different UIs (web, admin panel, embedded widgets) via the same service contracts

FAQ

Will using Context cause excessive re-renders?

Not if providers expose stable references and you memoize service instances; keep providers narrow and use selectors when possible.

How do I test components that use injected services?

Wrap the component with a test provider that supplies mock implementations or use the container’s swap API to inject test doubles.