Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving our approach to building components #392

Open
SalihuDickson opened this issue Dec 15, 2024 · 1 comment
Open

Improving our approach to building components #392

SalihuDickson opened this issue Dec 15, 2024 · 1 comment
Labels
status: new Has not been triaged by admin

Comments

@SalihuDickson
Copy link
Contributor

Problem:

Initially, we prioritized simplicity by adopting a configuration-driven model for our components. This approach allowed users to define component behavior by passing a JavaScript object containing all necessary specifications. However, after further exploration, this model presents several limitations:

  1. Overly Bulky: Configurations can become excessively large, even for small datasets. This is a significant concern, considering our target users will often work with substantial amounts of data.
  2. Lack of Transparency: As configuration complexity increases, the relationship between the configuration and the rendered component becomes increasingly abstract and difficult to understand and modify.
  3. Rigidity and Limitations: The configuration model restricts users to predefined component creation patterns. This hinders flexibility and can significantly slow development, particularly for experienced developers who may require customizations not explicitly supported by the current model.

Proposed Solution:

To address these limitations, I propose transitioning to a more flexible model based on subcomponents. Instead of a single component accepting a monolithic configuration, users will build their desired functionality by composing smaller, more focused subcomponents. This approach offers several key advantages:

  1. Enhanced Simplicity: By making sure components can be built with just a few essential subcomponent, we can provide a foundation for users to easily create components with consistent styling and behavior while maintaining flexibility.
  2. Increased Flexibility: This approach empowers users to seamlessly integrate our components into their workflows, allowing them to replace or customize specific subcomponents as needed. This removes significant development hurdles and eliminates the need for our design team to have to specifially add new requirements as they are required.
  3. Reduced Code Size: Utilizing subcomponents promotes code reusability through the use of maps and functions, leading to more concise and efficient code.
    Improved Debugging: By isolating data within specific subcomponents, it becomes significantly easier to pinpoint the source of errors and issues.
  4. Enhanced Learnability: This approach aligns more closely with traditional HTML component development, making it easier for developers with existing HTML knowledge to learn and adopt.

This is a link to a POC for my proposed solution.

@SalihuDickson SalihuDickson added the status: new Has not been triaged by admin label Dec 15, 2024
@SalihuDickson
Copy link
Contributor Author

@anuragxxd, this is my proposal for reworking our current approach to building components

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: new Has not been triaged by admin
Projects
None yet
Development

No branches or pull requests

1 participant