Refactoring Data Structures for Component Scalability

Introduction

In the tonybnya/portfolio project, I have been focusing on refining how data flows into the SkillsSlider component. As a project grows, the way we structure our props often becomes the bottleneck for maintainability. This post covers the recent refactor aimed at improving data clarity and component consistency.

The Challenge

Initially, the data structures passed into the component were somewhat tightly coupled with specific UI implementations. This meant that changing a label or adding a new skill attribute required hunting through the UI layer to update the data schema. Like rearranging a bookshelf where the labels don't match the contents, it makes finding what you need difficult as the collection grows.

The Refactor

To address this, I normalized the data structure passed to the SkillsSlider. By separating the data definition from the view logic, we gain a cleaner contract between the parent state and the UI component.

Consider this generic representation of our data transition:

// Before: Less descriptive keys
const skills = [{ n: 'React', l: 90 }];

// After: Meaningful and predictable keys
const skills = [
  {
    name: 'React',
    proficiency: 90
  }
];

This shift allows the SkillsSlider to focus purely on rendering the data without needing to know the context of the naming conventions. It acts as a clear schema for any future additions, such as icons or proficiency levels.

Results

By renaming these properties to reflect their intent, the component logic becomes more readable and self-documenting. New team members (or your future self) can now understand the data structure at a glance without traversing the component's internal logic.

Next Steps

With a normalized structure in place, the next phase is to potentially move this configuration into a centralized state store or a static JSON file to decouple the content layer entirely from the React component tree.

Generated with Gitvlg.com