[docs] Fix material-ui-popup-state IE 11 issue

[jedwards1211]

fix #13463
@oliviertassinari let me know if I overlooked anything or if you want me to solve this another way.

• I have followed (at least) the PR section of the contributing guide.

[oliviertassinari]

@jedwards1211 Changing our configuration to make the demo work isn't an option. As far as I see it, esm is about es modules, not targeting evergreen browsers. If we have this issue, people will also have it.

What do you think of only referring to your project in the documentation without a demo? It's what we do with everybody else.

[jedwards1211]

@oliviertassinari yeah I figured you might not be happy with changing the build config, I completely understand. And yeah, targeting evergreen browsers unfortunately remains way more awkward than it should be in 2018. How about I fix this in one of the following ways:

• Get rid of the es modules in material-ui-popup-state and release a patch version
• Explicitly import the transpiled modules in the demo source code
• (If nothing else, can I leave a mention in the demos, without source code or a running example?)

The main reason I wanted to put something in the demos (though it doesn't have to be running code) is because the first place anyone learning to create a menu will look is the demos page, and I bet less than 10% of those developers will ever find out about my lib if it's only in the related projects page. Plus, I believe it's most helpful for everyone if the primary approach is to use material-ui-popup-state or something equivalent for menus/popovers, and only fall back to custom state management for special cases. So really, I wish my material-ui-popup-state example came first in the menu demos, but of course I doubt you would be okay with that... 😄

I would prefer for everyone making related projects to be allowed to mention their projects in the relevant demo areas, because that way the information is better organized and accessible to developers, and they find out more easily what tools are available to help them. The related projects page is just a pile of links that isn't very efficient to read through.

Of course all this points to why I wish we could merge PopupState into @material-ui/core or a @material-ui/popup-state package. I strongly believe that everyone would greatly benefit from that.

I think it would be a real shame if anyone doesn't know my lib is here to help when they go to create a menu for the first time, wastes their time coding up the state management from scratch, and then thinks "I should write a component to take care of this..." only to then find that one already exists and think "well jeez, I really wish I knew about this to begin with!"

[oliviertassinari]

I would prefer for everyone making related projects to be allowed to mention their projects in the relevant demo areas

@jedwards1211 So do I. We do that where possible.

The main reason I wanted to put something in the demos (though it doesn't have to be running code)

I was suggesting to remove the running code as a quick workaround, not the section on its own :).

I strongly believe that everyone would greatly benefit from that.

It's definitely a path to explore, once we are set up to use the React hooks.

[jedwards1211]

Okay, I'll remove the running code then.

[jedwards1211]

Since material-ui-popup-state is intended for common rather than advanced use cases, would you mind if I put the following at the top of the page?

The following demos demonstrate how to use Menu's low-level API. However, for many cases you may find it faster and easier to use a helper like material-ui-popup-state to manage menu state instead of using the low-level API yourself.

[oliviertassinari]

Okay, I'll remove the running code then.

@jedwards1211 It's only intended as a quick workaround. If you want to patch the esm version to transpile the JavaScript down to ES5. I'm happy to wait.

We have started adding Google Analytics metrics around the usage of our demos. We should soon be able to better value each demo relatively to the other on the page. Let's see how people use it :).

Here is how it will look like once we update the demos to use the hooks.

import React from 'react';
import Button from '@material-ui/core/Button';
import Popover from '@material-ui/core/Popover';

function SimplePopover() {
  const [anchorEl, setAnchorEl] = React.useState(null);
  const open = Boolean(anchorEl);

  return (
    <div>
      <Button
        aria-owns={open ? 'simple-popper' : undefined}
        aria-haspopup="true"
        onClick={event => {
          setAnchorEl(event.currentTarget);
        }}
      >
        Open Popover
      </Button>
      <Popover
        id="simple-popper"
        open={open}
        anchorEl={anchorEl}
        onClose={() => {
          setAnchorEl(null);
        }}
      >
        The content of the Popover.
      </Popover>
    </div>
  );
}

export default SimplePopover;

Here is how it looks like with the library:

import React from 'react';
import Button from '@material-ui/core/Button';
import Popover from '@material-ui/core/Popover';
import PopupState, { bindTrigger, bindPopover } from 'material-ui-popup-state';

function PopoverPopupState() {
  return (
    <PopupState variant="popover" popupId="demo-popup-popover">
      {popupState => (
        <div>
          <Button {...bindTrigger(popupState)}>
            Open Popover
          </Button>
          <Popover
            {...bindPopover(popupState)}
          >
            The content of the Popover.
          </Popover>
        </div>
      )}
    </PopupState>
  );
}

export default PopoverPopupState;

What do you think of renaiming Advanced use cases -> Complementary projects everywhere. I think that it's more accurate :).