Refactoring Component Observability in my-portfolio

In my-portfolio, I recently focused on cleaning up some legacy patterns in our component logic. As projects evolve, it is common to accumulate "helper" logic or complex observer-pattern setups that were once necessary but eventually become noise. Specifically, I targeted reveal.tsx to simplify how components handle state updates.

The Problem: Obsolete Complexity

Over time, the way we handle component visibility and state triggers had become bloated. The implementation relied on an observer pattern to propagate state changes across child components. While powerful, it introduced unnecessary overhead for components that no longer required such deep coupling.

• Indirection: Each state change triggered a chain of notifications that were often ignored by downstream consumers.
• Boilerplate: The observer registration lifecycle was adding excessive lines of code to simple UI components.
• Cognitive Load: Developers had to trace event emitters rather than following standard data flow.

The Refactor

I decided to strip back the observer implementation in favor of a more direct, React-idiomatic approach. By moving toward local state and controlled props, the component became significantly more predictable.

Instead of this:

// Before: Heavy Observer Pattern
useEffect(() => {
  const subscription = stateObserver.subscribe(updateState);
  return () => subscription.unsubscribe();
}, []);

I moved to this:

// After: Declarative React State
const [isVisible, setIsVisible] = useState(false);

The Outcome

By removing the abstraction, the component logic became self-contained. This change not only improved readability but also made the unit testing process straightforward. We no longer need to mock the observer bus to test a simple visibility toggle.

The Takeaway

Patterns are tools, not rules. If you find your codebase fighting against the framework's native capabilities (like React's state management) just to maintain an abstraction, it is time to delete that abstraction. Before adding complexity, ask yourself if a simpler, more direct approach can achieve the same goal.

Generated with Gitvlg.com