Change builtInButtons to buttons

[chuckcarpenter]

This branch obfuscates the binding for buttons in steps to the user and makes setup mirror the docs from Shepherd.js.

Resolves #224

[RobbieTheWagner]

@chuckcarpenter I don't think we should call something that's not the same as Shepherd, the same as Shepherd here. builtInButtons have a type and generate a button that is built into ember-shepherd. These include cancel, back, next, etc. If we're trying to align with Shepherd and just be a pass through, this will be confusing to people, I think, right?

[RobbieTheWagner]

I'm still in favor of merging builtInButtons output and buttons if you want vanilla Shepherd buttons.

[BrianSipple]

It seems like the primary issue here is that the interface lacks constraint. What if we had two separate options: shepherdButtons and customButtons.

Each is focused, explicit, and unambiguous — for us and for users... unlike builtInButtons and buttons, apparently 😛.

[RobbieTheWagner]

@BrianSipple I would keep builtInButtons I think. The buttons are built in and provided. customButtons makes it sound like you want to do something custom.

We could potentially use just buttons I suppose, and add a check for type. If you pass type we use a built in one we provide, if you do not, it's just treated like a vanilla Shepherd button. What do you think @chuckcarpenter?

[BrianSipple]

customButtons makes it sound like you want to do something custom.

Right, isn't that what we're trying to enable? The current confusion is from the fact that builtInButtons allows you to select from one of shepherd's built-in buttons and pass in something different.

Or am I confused about what we're confused about? (#224)

[RobbieTheWagner]

@BrianSipple Shepherd does not provide any buttons. Shepherd takes an object to construct buttons, but has no built in or default types. ember-shepherd, however, does provide built in buttons, so you just set type: 'cancel' etc and the button is automatically hooked and bound to the cancel method.

With this in mind, I think perhaps it would make sense to just use buttons to align with Shepherd's docs, but then allow an extra param to the button options of type. Then check if type is defined and call makeButton, otherwise, just pass the vanilla buttons on to Shepherd itself.

Would this work for you @chuckcarpenter?

[BrianSipple]

Ah, got it.

I'm leaning towards using buttons exclusively, then. I don't think it would be confusing if part of the documentation for buttons mentions that a type can be passed in order to bind the click action to either the back, cancel, or next event.

Because that's actually the only difference between ember-shepherd and shepherd when it comes to buttons: Occasionally we can handle the click action for you. Otherwise, you need to pass your own function to the action property.

So I think... a) keeping the interface consistent while... b) documenting the extra sugar... strikes a pretty good mix.

[RobbieTheWagner]

Totally agree @BrianSipple! We just need to fix conflicts here and add the type check stuff.