Feature
Add configurable visibility props for the major sections of the SupportUsButton component.
Currently, the component always renders all available sections, including:
- Project Information
- Organization Information
- Sponsors
- Background Logo
- Decorative Border
- Corner Icons
This makes the component less flexible for projects that only need specific sections. Developers currently cannot hide individual sections without modifying the source code.
Proposed API
<SupportUsButton
showProjectInfo={true}
showOrganizationInfo={true}
showSponsors={true}
showBackgroundLogo={true}
showBorder={true}
showCornerIcons={true}
/>
All props should default to true to preserve the current behavior and maintain full backward compatibility.
Use Cases
1. Minimal Landing Pages
Some projects only need a title and a sponsorship button without displaying project or organization details.
2. Organization Websites
Organizations may want to display only their organization information while hiding project-specific content.
3. Documentation Pages
Documentation websites may only want to show sponsorship information and a call-to-action.
4. Embedded Components
When embedding the component into an existing website, developers may want to disable decorative elements such as the background logo, border, or corner icons so the component better matches the host application's design.
5. Custom Branding
Different projects have different branding requirements. Being able to selectively show or hide sections makes the component more adaptable without requiring code modifications.
Benefits
- Improves component flexibility.
- Makes the component reusable across different project types.
- Reduces the need to fork or modify the library.
- Keeps the API simple and intuitive.
- Introduces no breaking changes because all new props default to
true.
- Improves the developer experience by allowing easy customization.
Additional Context
This enhancement focuses on improving the flexibility of the existing component rather than changing its current design.
The default appearance and behavior would remain exactly the same, ensuring that existing users are not affected.
The proposed visibility props would provide optional customization, allowing developers to adapt the component for a wider range of real-world use cases while maintaining a clean and straightforward API.
This feature is fully backward compatible and follows the existing design philosophy of making the component configurable through props rather than requiring source code modifications.
I'd be happy to work on this feature if the maintainers think it aligns with the project's roadmap.
Feature
Add configurable visibility props for the major sections of the
SupportUsButtoncomponent.Currently, the component always renders all available sections, including:
This makes the component less flexible for projects that only need specific sections. Developers currently cannot hide individual sections without modifying the source code.
Proposed API
All props should default to
trueto preserve the current behavior and maintain full backward compatibility.Use Cases
1. Minimal Landing Pages
Some projects only need a title and a sponsorship button without displaying project or organization details.
2. Organization Websites
Organizations may want to display only their organization information while hiding project-specific content.
3. Documentation Pages
Documentation websites may only want to show sponsorship information and a call-to-action.
4. Embedded Components
When embedding the component into an existing website, developers may want to disable decorative elements such as the background logo, border, or corner icons so the component better matches the host application's design.
5. Custom Branding
Different projects have different branding requirements. Being able to selectively show or hide sections makes the component more adaptable without requiring code modifications.
Benefits
true.Additional Context
This enhancement focuses on improving the flexibility of the existing component rather than changing its current design.
The default appearance and behavior would remain exactly the same, ensuring that existing users are not affected.
The proposed visibility props would provide optional customization, allowing developers to adapt the component for a wider range of real-world use cases while maintaining a clean and straightforward API.
This feature is fully backward compatible and follows the existing design philosophy of making the component configurable through props rather than requiring source code modifications.
I'd be happy to work on this feature if the maintainers think it aligns with the project's roadmap.