Implement a dropdown/popover component

[colmtuite]

I've added a rough and basic dropdown component, you can read the docs inside docs/components/context.html, the CSS inside src/components/Context.css and the JS inside docs/js/Context.js.

To see what I have working so far, you can check out the Context component docs page.

As you can see, this component is currently called "Context". The primary reason for this is because "Dropdown" is not really suitable, since sometimes the menu will drop up and other times it will appear to the left or right. So really, this is just a contextual menu which overlays content. A more suitable name might be "Popover". I'd love to hear any suggestions on this.

That brings me to the main design question I'm thinking about regarding this component - should this component handle all contextual overlays? I'm leaning toward "yes".

In many apps you will see typical dropdown components in top app bars for example, or expanding when you click an icon. You will also see hovercard components, for example on Twitter or Facebook when you hover a username, a popover appears after a brief delay. Many apps also have context menus which appear when you right-click. From a visual design perspective, each of these components are exactly identical. There is not a single style that differs between them. This leads me to think that they should all be the same component.

If we have just one component, we can allow various options for trigger, delay, position etc. If we separate them into 3 or 4 different components, I imagine much of the code will be duplicated - certainly all of the CSS will be duplicated. So, I'm leaning toward having just one component. I'd very much like feedback on this too.

So, assuming we have just one component for all scenarios, here's how I imagine it should behave by default:

Trigger

• You interact with a trigger component to activate the Context component. The trigger component can be any component. The Context component can be triggered by "click", "hover" or "focus". This should be customisable via an option somehow. The default should be "click".
• When activated, the Context panel appears.
• Absolutely any content can be rendered inside the Context panel.
• Clicking the same trigger component again should close the Context panel.
• Clicking anywhere on the viewport should close the Context panel.
• Clicking a different Context trigger should close all open Context panels and open the Context panel which corresponds to the trigger which has just been clicked.
• Pressing the ESC key should close all active Context panels.
• When "hover" is set as the trigger event, mousing out of the trigger component should dismiss the Context panel.
• When "focus" is set as the trigger event, blurring the trigger component should dismiss the Context panel, though I think that is already completely covered by the click event and the ESC key?

Direction

• By default, a Context panel should open in a vertical, downward direction. In cases where opening downward would cause the Context panel to extend beyond the bottom edge of the viewport, the Context panel should open in an upward direction. There should be an option to force the Context panel to always open in a downward direction and an option to force the Context panel to always open in a upward direction. So, the three available options would be direction="vertical", direction="down", direction="up".
• There should be an option to open the Context panel horizontally. By default, the Context panel should open to the right. In cases where opening to the right would cause the Context panel to extend beyond the right edge of the viewport, the Context panel should open to the left. There should be an option to force the Context panel to always open to the left and an option to force the Context panel to always open to the right. So, these three options would be direction="horizontal", direction="left", direction="right", making it 6 direction options in total.

Position

• By default, a Context panel should be aligned to the center of its trigger component. Options should be provided to force alignment of the Context panel along the left edge or the right edge of its trigger component. However, when the Context panel is set to "horizontal", we want to be able to align to the top or bottom of the trigger component. So, we can use "start" and "end" here instead, in keeping with flexbox terminology. So, the three available position options would be position="center", position="start", position="end". Note that in cases where aligning the Context panel in the center of its trigger component would cause the Context panel to extend beyond either the left, right, top or bottom edges of the viewport, either "start" or "end" alignment should be applied automatically.

Delay

When trigger="hover" is set, a delay option should be provided which will delay opening the Context panel until a certain time period has passed. The delay value should be set in milliseconds. The delay should only affect the opening of the Context panel, closing should happen instantly. I think we should restrict this option to when trigger="hover" is set, though I'm not sure about that. Any feedback much appreciated.

General

• If you're planning to work on this, you should create a new branch off master.
• I have purposely omitted details about the "right-click" trigger option, because that entails nuances which I haven't fully thought through yet. We can handle that at some point in the future.
• No CSS classes should be used as JS hooks. If a class hook is necessary, add a new class prefixed with js-.
• Any event listeners should work for server-side rendered content and also for dynamically created content.
• I guess one way we could handle the options is with data-attributes. I'm not sure what the best way is though so I have no strong preference here.
• The JS should not disable any animations or transitions on the Context component. For example, settings display: none; would break any transitions.
• For now, Modulz is intended for use as a monolithic CSS toolkit with no dependencies on React or any other JS library. With that in mind, I think jQuery might be a good option for this? It would be excellent if it can be done with vanilla JavaScript, using all the fancy ES6 stuff (I've no idea what I'm talking about) but if that's not possible, I guess jQuery is fine.

[asvny]

Hey .. thanks for detailed writeup !

• I'm also in favour of one component (Context or Popover) instead of duplication.

• I also faced a similar problem a while ago , instead of having dropdown, contextmenu etc..

  I introduced a new layer "Objects" which deals with layout specific things (prefixed with .o-). IT SHOULD NOT HAVE ANY VISUAL STYLES. (Inspired from ITCSS structure by Harry roberts)

  Then each component dropdown, contextmenu will deal with it's own visual styles (prefixed with .c-)

  So example markup will kind of ..

  <div class="o-popover c-dropdown" >
    <div class="c-dropdown-trigger" ></div>
    <div class="o-popover-content c-dropdown-content" ></div>
  </div>

  Though it looks verbose .. it satisfies my needs !

• It is better to go with data-attributes which makes it easy for beginners .. but it clatters markup . (another option is to initialise via javascript kinda like jQuery UI)

• Lets go with ES6 + rollup (as build tool)

Let me start and get back to you ... when I have a working one !

[asvny]

@colmtuite I think you might have come across http://mdo.github.io/mdoml I ❤️ mdoml

your thoughts ?

[colmtuite]

I've used o- and c- prefixes a lot in the past but I've stopped using them because they don't provide any benefits to me anymore. My utility classes follow a strict kebab-case naming pattern e.g. display-block and my components are PascalCase e.g. StatusIndicator. So it's very easy to tell the difference between the two without any issues. There are never any conflicts either.

I'm fine with data-attributes if you think that's a good option. I think initialising with JS would require a separate script for each Context instance, which I imagine would become verbose? In my mind, the customisation of each Context component is specific to the view, so I'm fine with that customisation happening in the view. I'm not at all concerned with bloated markup. Browsers don't have any issues with it, so neither do I.

Thanks for getting involved with this, I'm excited to see what you come up with!

I have seen mdoml yes. I appreciate what he is experimenting with and I think there are some pros. Ultimately, I just don't think it has a significant benefit to a large project. A lot of the HTML elements have some semantic or functional value e.g. h1, h2, h3, p, span, a, form, button, header etc. The majority of components are covered by these semantic tags and I just don't think there are that many components leftover that could benefit from a custom tag. I enjoy the simplicity that React provides by abstracting the classes out of the view into a custom tag but I think this is better suited to a library like React which renders valid markup.

[colmtuite]

I thought of a detail I left out of the original spec above.

As per the spec above, when its direction attribute is set to either direction="vertical" or direction="horizontal", or when its position attribute is set to position="center", the Context panel should adapt its direction and position if it extends beyond the boundaries of the viewport/window.

However, I forgot to mention, sometimes it can be necessary to have it adapt to a specific parent element .e.g in a Context component inside a scrolling comment feed, you might want the Context panel to open downward by default, except when you reach the bottom of the comment feed, then open upward.

Again, I'm not sure how this should work. Pass the ID of the relative element in a data-attribute? Also, this can be tackled further down the line, after we get something working.

[asvny]

I am closer ... I will share the link soon !

[colmtuite]

Have you seen https://popper.js.org/? It could help us a lot with this component.

Also, we have a rough demo of a first attempt at this component in our Slack channel. If you want to join, send me your email and I'll invite you.