2024-08-15 Frontend Working Group Meeting Notes: Custom component props

 Date, time, location

• Date:Aug 15, 2024 at 15:00 UTC (timezone converter)

• Location: https://meet.google.com/cxz-yjwi-gvi

 Discussion topic(s)

• Proposal on Component Prop Overrides: Adam Stankiewicz introduced a proposal aimed at enabling the extension or overriding of component properties without hard-coding vendor-specific attributes in the codebase. The primary motivation was to handle vendor-specific attributes, such as those used by tools like Datadog and Hotjar, more flexibly.

Meeting notes

• @Adam Stankiewicz https://github.com/openedx/frontend-platform/pull/723

  • Open questions:

    • Could this approach be abused from a security POV (e.g., XSS)?

    • Is there a better name than selectors (or is this key needed at all?

    • Is there a concern env.config could become quite large?

    • How do we ensure this doesn’t get overly used as a theming/mechanism in lots of places?

      • E.g., wrt to its support of shallow merge of style props.

    • How does one ensure uniqueness of the componentPropOverrides selector for any given component? E.g., using the same component selector as another component without knowing?

• @Fox Piacenti Update on the two themes problem space with BTR?

  • Unsure; maybe Adolfo/BrianS might know?

🎥Recording

• Video: Frontend Working Group Meeting (2024-08-15 12:04 GMT-3)

• Chat: Frontend Working Group Meeting (2024-08-15 12:04 GMT-3) - Chat Transcript

• Transcript: Frontend Working Group Meeting (2024-08-15 12:04 GMT-3) – Transcript

 Participants

Adam Stankiewicz, David Joy, Fox Piacenti, Jason Wesson, Max Frank, Milad Emami, Rabeeh T A, Sarina Canelake, Steven Girón

🤖 Summary

Discussion Points:

1. Current Challenges:

   • Hard-coding attributes for specific vendors like Hotjar across the platform is not ideal as not all instances use the same vendors.

   • The proposed solution involves using a hook or higher-order component to apply custom prop types to any component dynamically.

2. Implementation Details:

   • The proposal includes a configuration schema that allows specifying selectors and corresponding prop overrides.

   • A key part of the discussion was about ensuring that this approach doesn't unintentionally allow the abuse of this flexibility, such as by overriding important properties like className or style incorrectly.

3. Concerns Raised:

   • Security: David Joy and others expressed concerns about potential security issues, particularly with handlers like onClick, which could introduce vulnerabilities if misused.

   • Abuse of Flexibility: There were concerns about developers misusing this flexibility to override too many aspects of a component, potentially leading to bloated and hard-to-maintain configurations.

4. Suggestions:

   • Limiting Scope: It was suggested that the proposal might need to be narrowed down, focusing on specific use cases such as PII masking rather than being too generic.

   • Naming Conventions: The term "selectors" was seen as potentially confusing, and a better naming convention was suggested to clarify the intent and usage.

5. Next Steps:

   • Adam will refine the proposal based on the feedback, particularly focusing on security concerns and the potential for misuse.

   • A decision on whether to proceed with the current generic approach or to narrow it down will be considered.

Meeting Conclusion:

• The group agreed to take the discussion async and revisit the proposal after further refinement. The meeting concluded with no additional topics raised.

 Action items

 Decisions