Edges inside React

[richard-jones]

• Do a quick demo
• Embed into Invenio with React + Semantic UI

[varadekd]

@richard-jones

"Embed into Invenio with React + Semantic UI" does this mean, I need to work on Invenio project and plug edges inside the already existing code base? If so can you point me to the correct repo in which we need to build this.

[varadekd]

@richard-jones

The current library is built using a class-based approach, which makes integration with modern JavaScript frameworks like React and Vue difficult. These frameworks support a module-based approach, which is different from our current structure. While the existing library works well with Vanilla JS, to ensure compatibility with both Vanilla JS and modern JavaScript frameworks, we need to refactor it to use a module-based approach.

---

Approaches for Refactoring the Library

1. Incremental Refactoring (Patchwork Approach)

Description: This approach involves gradually converting the library to a module-based structure piece by piece without making significant architectural changes.

Pros:

• Speed: This approach is faster since it doesn't require major discussions or planning.
• Flexibility: Allows for quick adjustments and iterations as issues or improvements are identified.

Cons:

• Technical Debt: May lead to an accumulation of technical debt and inconsistencies in the codebase.
• Integration Issues: Potential for integration issues as some parts of the library may remain class-based while others are module-based.

2. Comprehensive Refactoring (Architectural Redesign)

Description: This approach involves planning and redesigning the library’s architecture before making any code changes.

Pros:

• Consistency: Ensures a consistent and cohesive codebase with a clear modular structure.
• Future-Proofing: A well-designed architecture can be more easily maintained and extended in the future.

Cons:

• Time-Consuming: This approach is slower due to the need for detailed discussions and planning.
• Initial Overhead: Higher initial investment in time and resources for architectural design and planning.

Summary

Approach 1: Faster, more flexible, but may lead to technical debt and inconsistencies. Approach 2: Slower, ensures consistency and maintainability, but requires more initial investment in planning and design.

We can discuss this over a call or on chat.