-
Notifications
You must be signed in to change notification settings - Fork 41
Closed
Labels
developementRelated to perspective development, as opposed to developer usageRelated to perspective development, as opposed to developer usagedocumentationImprovements/bugs/changes to documentationImprovements/bugs/changes to documentationquestionQuestions about use, potential features, or improvementsQuestions about use, potential features, or improvements
Description
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:
- subclassing/
extend-ing theRegularTableElementclass (this is dependent on what we decide about Should RegularTableElement be explicitly marked asfinal? #60) - composition of the
'regular-table'custom element (within another custom element, a React component, etc) - 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.
sebinsua
Metadata
Metadata
Assignees
Labels
developementRelated to perspective development, as opposed to developer usageRelated to perspective development, as opposed to developer usagedocumentationImprovements/bugs/changes to documentationImprovements/bugs/changes to documentationquestionQuestions about use, potential features, or improvementsQuestions about use, potential features, or improvements