button: Allow Button to have user provided custom markup

Enhancement Request

I would like to be able to provide an alternate element for the Button to render with so that I can integrate with 3rd party routing libraries - like react-router - and use their Link element, but keep the Button styles.

Prior art:

• https://material-ui.com/demos/buttons/#third-party-routing-library
• http://elemental-ui.com/buttons#usage

In both of these examples, an additional component prop is present on the Button that allows the consumer to specify what component should ultimately be rendered

Desired behavior

I’d like to be able to leverage the Button styles, but for arbitrary components that I provide.

Today’s behavior

Trying to use a Link from react-router end up generating “awkward” HTML (potentially not semantically correct).

<Button>
  <Link>My Text</Link>
</Button>

will result in:

<button>
  <a href="...">My Text</a>
</button>

The Value Add

This would make the Button component more flexible to help integration with 3rd party libraries

The Tradeoffs

I’m not sure? This seems to be a fairly common practice I’ve encountered among components libraries (regardless of framework).

[jaketrent]

There is definitely overlap between the two design systems. Yes, I want to learn from others’ successes. I don’t want to do things just because they’ve been done with success elsewhere. If copying their successful idea feels like the best option, we shouldn’t shy away from it. I’m just not convinced it is, and so I’m not ready to jump on the bandwagon there.

Solutions to deal with react-router seem to fit in userland very well. The Design System has no affiliation with react-router. Inasmuch as our users use react-router, we should enable them to be compatible with us, but it’s looking like we don’t need to do anything new in this case. React-router already envisioned how their tools should be used in this case and created a solution which seems simple and easy enough for their users.

If you’d like to work on this, I have no problem with it. It might be fun to explore. As you can tell, I’m not super hot on the material-ui solution, and I will feel worse after you’ve created the PR for implementing it if we decide not to go that direction, which is my current leaning. But, if after those caveats you’re still enthusiastic to work on it, I’d be happy to look at what can be created and perhaps would find something compelling about seeing concrete code in a branch of our code in order to make a better comparison.

Thanks for sharing your perspective with me in this thread thusfar. Enjoy the weekend, and we can talk more next week.

[willsoto]

Thanks for continuing to look into this!

My biggest concern with most(?) of the solutions provided in the SO post is the fact that they aren’t semantically correct. button > a actually doesn’t work in FF (which is how it should be as you pointed out in https://github.com/pluralsight/design-system/issues/376#issuecomment-445360453). Having a > button is technically valid markup, but I think it could be simpler if you just had a with some CSS classes that made it look like a button.

In terms of bootstrap: a.btn.btn-primary looks exactly like button.btn.btn-primary which feels like a pretty clean API to me.

---

In terms of creating a custom HOC that leverages “private styles” from the button - I am not sure I am totally crazy about that idea.

As a consumer: using the DS in its native language (React) I have to reach into private APIs in order to get the styles I want.

As an API provider: I wouldn’t feel comfortable with letting people leverage my internal styles like that for what I would consider a “common” use case.

That is, of course, totally my opinion.

---

If I can ask, is there anything in particular you don’t like about how two major design systems handle this situation? I personally find it to be a very clean solution to this problem.