Implementing Generic for all Details page

[Rajgupta36]

Discussion: Generic Functionality for Detail Pages

Hi everyone, welcome to this discussion.

Currently, we have pages that contains a list (e.g., chapters, projects) that uses a unified Card.tsx component. The question is: What do you think about implementing the same generic functionality for all detail pages?

We have two approaches:

1. Create a generic component similar to Card.tsx
2. Use modular code (as we have now)

Both approaches have their own advantages and disadvantages. Let’s break them down:

---

1. Create a Generic Component (Similar to Card.tsx)

Advantages:

• Consistency: Ensures a consistent look and feel across all detail pages.
• Reusability: Reduces code duplication by reusing the component for different detail pages.
• Maintainability: Easier to maintain and update, as changes are made in one place.

Disadvantages:

• Complexity: May become overly complex with many edge cases or variations.
• Flexibility: Limits customization for pages requiring unique layouts or functionality.

---

2. Use Modular Code (Current Approach)

Advantages:

• Flexibility: Each detail page can be tailored to its specific needs.
• Performance: Optimized for specific use cases.
• Easier Debugging: Issues are isolated to specific pages.

Disadvantages:

• Code Duplication: Similar logic and UI elements may be repeated.
• Maintenance Overhead: Changes need to be applied to multiple pages.

---

Next Steps

To move forward, please share your thoughts and goals for this discussion. Specifically:

1. What are your priorities? (e.g., consistency, flexibility, maintainability, performance)
2. Which approach aligns best with our project requirements?
3. Are there any specific challenges or use cases we should consider?

Let’s collaborate to finalize the best approach! 🚀

[Naveen-Pal]

I things Generic Component will be nice if there is not much difference between in sub sections(summery, details) of them (project, chapters, ..). Generic Component will help in maintaining code much easier.

[arkid15r]

I expect minimal difference among those components. While the title, summary, details, stats blocks will be the same for most of the entities, there may be some small difference that we could handle conditionally, like a map for Chapter details page for example.

[arkid15r]

We can apply modular approach to extract something like Recent releases, Recent Issues, Top Contributors blocks if needed. I'd like to have the consistent look with reusable and maintainable code.

[Rajgupta36]

Hybrid approach

[abhayymishraa]

@Rajgupta36
what i think hybrid soulution will work great in this use case . Instead of chossing full generic or fully modular
Like we can use these steps:
creating a base generic component - base detail page which will hadle data fetching, loader , error handling,
and then allowing certain pages to customize or replace parts of the base DetailPage component, instead of being strictly tied to the generic design
and the last step - use small, reusable components like DetailCard, DetaillButton, DetailRecentreleases to assemble pages dynamically.

[kayashth1]

The generic component approach seems best for our project, as it reduces code duplication and ensures a consistent look across pages.
it prioritizes maintainability and consistency which are great things. But as requirement increases and new functionalities are introduced Hybrid of these can be an optimized solution.

[Rajgupta36]

Thanks, everyone, for sharing your valuable opinions.