AccordionPane

[bitpshr]

Enhancement

Add an AccordionPanel component

[rishson]

So we need to list out the initial features.

Things to consider:

• Can multiple sections be open at the same time, or only 1 section at a time?
• Does the accordion's height stay constant, irrespective of the open section(s) content, or does it resize?
• Can you disable sections?

For the initial implementation, my suggestion would be:

1 section open at once height stays constant - (overflow sections if needed) no disabled sections.

[rishson]

Also, I'd like to standardise on naming things that may have been called 'panel' in the past. I've been using semantic ui for too long, but i've got used to the brevity of their widget naming, so we could have:

accordion tab sideBar split

Thoughts?

[msssk]

I am also a fan of names being as long and descriptive as necessary, but no more. I think the "panel" suffix is often unnecessary.

For now, we should try to agree on the accordion name, and my vote goes to "accordion".

The overall naming scheme might be best tracked in a separate issue, but some quick thoughts:

• tab: we probably want both tabs (or tabContainer?) and tab, yes?
• split: this is a little lacking in descriptiveness for me... the "panel" suffix might actually be warranted

[rishson]

tab is a contentious one. I've always viewed tab as both the tabStrip and the tabContents (for want of better names. tabPane and splitPane? (I just dislike 'panel' as its too retro).

[rishson]

Which would give us:

• tabPane
• splitPane
• slidePane
• accordion ?

[bitpshr]

While I don't really care what suffix we use (e.g. "Pane" vs. "Panel" vs. anything else), I do think that every container component should use the same suffix. I think having one component that doesn't use it, like "Accordion", is confusing. This suffix sort of serves as an indicator that a component is a container-style component in my mind.

[rishson]

@bitpshr I've started to wonder if we need to consider all the widgets where the primary function is layout, such as :

• menu
• header
• footer

To me, it seems clunky to have pane suffixes to these widgets. If the list was something like:

• tabPane
• splitPane
• slidePane
• accordion
• menu
• header
• footer

then I think its ok to drop the suffix at times. [shrug_emoji]

[bitpshr]

@rishson sounds good to me.

[msssk]

Some questions on what we want from an accordion pane:

• Should it accept arbitrary children? Or only TitlePanes?
• Should it have an exclusive option to enforce only a single pane open at a time?

[bitpshr]

I don't think an AccordionPane should accept arbitrary children. If another widget is needed next to the internal TitlePanes, the widget should just be a sibling to the AccordionPane within a wrapping div.

I like the idea of an exclusive option.

[mwistrand]

Based on the work already done for TitlePane, is a dedicated accordion widget even needed? It seems like an accordion is simply a collection of TitlePanes and any control logic can use existing properties:

v('div', {}, [
  w(TitlePane, {
    open: this.state.index === 0,
    onRequestOpen: () => this.setState({ index: 0 }),
    onRequestClose: () => this.setState({ index: undefined })
  }, [ /* ... */),

  w(TitlePane, {
    open: this.state.index === 1,
    onRequestOpen: () => this.setState({ index: 1 }),
    onRequestClose: () => this.setState({ index: undefined })
  }, [ /* ... */ ]),

  w(TitlePane, {
    open: this.state.index === 2,
    onRequestOpen: () => this.setState({ index: 2 }),
    onRequestClose: () => this.setState({ index: undefined })
  }, [ /* ... */ ])
]);

[smhigley]

I agree with @mwistrand, I don't really see a need for this widget. Would it add anything apart from limiting one open TitlePane at a time?

[rishson]

Accordion might be just a small wrapper widget to do just the limited opening. I think in this case, there is some justification in that it is a widget that you expect a toolkit to have, and if we have a tutorial explaining the above, rather than a widget, then I'm unsure what message that sends to the user base. On one hand we could look minimal, clean, elegant, or it could be perceived that we are asking too much of the user; that they have to do too much themselves..

[smhigley]

On the other hand, writing the above is already simpler that writing a Menu widget 😂.

[rishson]

I think we should maybe ask in dojo2 if small wrapped widgets are something we feel add value for users (Accordion, Loader)..

[smhigley]

Maybe it should be pushed down the road, at least? It doesn't seem to add a lot of value, especially compared to TimePicker or Tooltip or one of the others. That would also let us gauge against any feedback we (hopefully) get on beta2

[rishson]

but, but, its on my list! Won't someone think of the list!?

OK, maybe small widgets should be shelved until we have consensus on their inclusion.

[sebilasse]

Just wanted to mention that my Semantic UI dojo2 Integration also contains Accordion, posted a WIP preview here : https://github.com/dojo/widget-core/issues/559

[eheasley]

We are very near completion on this as a result of working on related tasks, so we will go ahead and get this taken care of for beta 4.