Skip to content

What are best practices for 3rd party libraries that want to build components on top of regular-table? #62

@telamonian

Description

@telamonian

I am currently experimenting with building a more heavy-duty/dedicated tree-browser on top of regular-table over at github.com/telamonian/tree-finder, and I imagine (what with our high media profile, and all) that there will be interest from other parties as well.

With that in mind, at least from a documentation perspective, what should we consider to be the best practice for extending the 'regular-table' custom element? I think(?) there's roughly three choices:

  1. subclassing/extend-ing the RegularTableElement class (this is dependent on what we decide about Should RegularTableElement be explicitly marked as final? #60)
  2. composition of the 'regular-table' custom element (within another custom element, a React component, etc)
  3. collections of static functions to help set up data listeners, style listeners, etc

I've been experimenting with 1., but inheritance in general seems to be out of fashion these days. In asking this question I'm somewhat inspired/motivated by the React folks, who have taken a hard line on composition over inheritance when it comes to extending custom components.

Metadata

Metadata

Assignees

No one assigned

    Labels

    developementRelated to perspective development, as opposed to developer usagedocumentationImprovements/bugs/changes to documentationquestionQuestions about use, potential features, or improvements

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions