Skip to content

Instantly share code, notes, and snippets.

@adeleke5140

adeleke5140/reademe.md

Last active October 31, 2023 12:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save adeleke5140/7a58b84d87a6b558eee00caa792a9142 to your computer and use it in GitHub Desktop.
Save adeleke5140/7a58b84d87a6b558eee00caa792a9142 to your computer and use it in GitHub Desktop.
Download ZIP
Dependency Injection in React
Raw
reademe.md

Dependency Injection in ReactJS

This is a conversation on the DI pattern in ReactJS.

This article from the folks at 8th Light is great. The author explains how it makes component very easy to test. It encourages unit testing rather than integration testing.

In essence:

It also allows for substitution of a dependency with a mock, or fake, during testing.

I know the importance of loose coupling of dependencies and how it helps in building software that is resilient to change.

My reservations

I came across this tweet and it made me start thinking about the DI pattern we used in Shiga.

This is an intersting line:

It makes a codebase really difficult to ramp up on because you can't trace things bottom-up, only ever top-down.

I ran into this issue a lot in Shiga where it felt complicated. For me to understand a child's dependency, I had to go to the Parent. If the Child is deeply nested, it creates this sorta Dependency drilling situation where you have to find the parent and the parent's parent.

The top-down approach is complexity. Complexity in the sense that it is:

  1. Hard to reason about
  2. Components are pretty much static. We didn't really extend them after creation.

I wonder if the complexity could be improved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment