Persistent Drawer links not working as expected with react-router-dom

When mdc-web persistent drawer is used with react-router-dom (BrowserRouter), the links inside the drawer are losing SPA behavior. That is links the links (html <a>) inside the drawer are bypassing react-router, and making a fresh request to the server.

What MDC-Web Version are you using?

https://unpkg.com/material-components-web@latest/dist/material-components-web.css https://unpkg.com/material-components-web@latest/dist/material-components-web.js

What browser(s) is this bug affecting?

Chrome

Version 59.0.3071.115 (Official Build) (64-bit)

What OS are you using?

macos sierra, and windows 10.

What are the steps to reproduce the bug?

1. npm install -g create-react-app
2. git clone https://github.com/smandava/router-issue
3. cd router-issue
4. npm i
5. npm start
6. open http://localhost:3000 on your browser
7. open developer tools and network tab
8. click on About link, network tab shows about 12 requests made to the server to render the page (actual behaviour)

---

1. open app.js in a text editor.
2. replace BrowserRouter with HashRouter and save the file.
3. open http://localhost:3000 on your browser
4. open developer tools and network tab
5. click on About link, you see the No network requests but the link is still functional. (expected behaviour).

What is the expected behavior?

Described in (12) above.

What is the actual behavior?

Described in (7) above.

Any other information you believe would be useful?

None.

[AustP]

I had this same issue. This is my workaround until something gets implemented:

if (!MDCTemporaryDrawer.prototype.getDefaultFoundation_) {
  MDCTemporaryDrawer.prototype.getDefaultFoundation_ = MDCTemporaryDrawer.prototype.getDefaultFoundation;
  MDCTemporaryDrawer.prototype.getDefaultFoundation = function() {
    const foundation = this.getDefaultFoundation_();

    foundation.drawerClickHandler_ = (e) => {
      if (e.target.tagName !== 'A') {
        e.stopPropagation();
      }
    };

    return foundation;
  };
}

[kfranqueiro]

This has been fixed via 3e173e1ddc3bff5c7c9c2d794eeb36a9354ec98c (based on #1138), which refactors out the stopPropagation call.