Menu item href breaks focus (necessary to TAB twice)

[tomasiser]

Bug Report

Steps

1. Go to https://stardust-ui.github.io/react/components/menu, version 0.5.0.
2. Edit the first example by adding href: '#', e.g., with the following code:

   import React from 'react'
   import { Menu } from '@stardust-ui/react'
   
   const items = [
     { key: 'editorials', content: 'Editorials', href: '#' },
     { key: 'review', content: 'Reviews', href: '#' },
     { key: 'events', content: 'Upcoming Events', href: '#' },
   ]
   
   const MenuExample = () => <Menu defaultActiveIndex={0} items={items} />
   
   export default MenuExample
   

3. Try keyboard navigation (TAB key) on the menu.

Expected Result

Pressing TAB moves you to the next menu item, Shift+TAB to the previous one.

Actual Result

It is necessary to press TAB or Shift+TAB twice for each menu item. The reason is that using href changes the menu item into <a>, so there are now two nested <a> taking focus one by one.

Version

0.5.0

[miroslavstastny]

getElementType() takes getDefault parameter but renderComponent() never sets that. There is no way how a Component could override that.
@levithomason, @mnajdova, @kuzhelov - before stardust-ui/react-old#21 there was such a possibility. Can we add it back?

[kuzhelov]

Agree that using getDefaultparameter of getElementType() function might be a first step to resolve this problem.

At the same time, the following line of getElementType seems like a black magic to me:

// ----------------------------------------
// infer anchor links

if (props.href) return 'a'

Where this functionality might come in need? It seems to be always possible for a client to specify as='a' alongside with href, so that desired effect would be achieved - and achieved with reasonable explicitness. And the fact that in case of href being specified component type suddenly changes its dress to appear as a - this is really weird and unexpected thing to me (at least certainly for those cases where component's as value is specified in its defaultProps).

So, my suggestion would be to avoid this 'implicit "a"', and as further steps - introduce href as handled prop of MenuItem, so that component will take care of where this attribute should be plaved in its components' tree:

// MenuItem
 renderComponent({ ElementType, classes, accessibility, rest }) {
    const { children, content, icon, href } = this.props

    const hasChildren = childrenExist(children)

    return (
      <ElementType ... href={hasChildren ? href : undefined} {...rest}>
        { hasChildren ? children
         : (
          <a href={href} ... >
          ...
          </a>
        )}
      </ElementType>
    )
  }

[miroslavstastny]

Yes, adding href to handledProps in MenuItem is my plan.
@levithomason - any strong reason against removing if (props.href) return 'a' from getElementType()?

[levithomason]

delete it 👍

[jurokapsiar]

on top of what was mentioned, all attributes relevant to the <a> need to be rendered on the anchor - href, rel, target, ...

[miroslavstastny]

Fixed by #323