Add dselect and select to the tabset, not just each tab

[asgh]

Request: Add deselect and select to the tabset, not just each tab.

This way I don't have to write the identical code in each tab. But add in also a reference to the tab that triggered the deselect/select.

If both are set (in the tabset and the tab) then both run. Probably for select the tabset first, and for deselect the tab first.

[icfantv]

@asgh, i like this idea in principle, but i think it could be very confusing for the user, not to mention it's API bloat and more maintenance (and thus, user/but support on our end to have BOTH options. users THINK they want infinite configuration options, but at some point it gets ridiculous...

@wesleycho, thoughts?

[asgh]

@icfantv If it were up to me I'd remove it from tab entirely and only add it to tabset. For those few times when a tab needs individual code then just use the tab index passed in to differentiate.

But since backwards compatibility prevents that, I suggested adding it as an option for tabset.

[icfantv]

@asgh, that would, undoubtedly piss off a lot of other people as that would be a huge breaking change. Passing in just the tab index would require the end user to do all kinds of gymnastics to figure out what tabs are in question.

Not only that, one of your original statements points to the crux of the problem:

If both are set (in the tabset and the tab) then both run. Probably for select the tabset first, and for deselect the tab first.

Someone will undoubtedly want the reverse of what we've chosen and then what? Do we then also add a flag to dictate order? This is what I mean by API bloat. You cannot have an infinitely configurable API that is also adequately maintainable. Don't forget we are all volunteers.

You cite code duplicity as your reasoning. Can you not just have those methods on a parent controller?

[asgh]

that would, undoubtedly piss off a lot of other people as that would be a huge breaking change

Obviously, that's why I didn't suggest it. I was just saying that as a way of saying that tabset is actually (IMO) the preferred place for it, not each tab.

would require the end user to do all kinds of gymnastics to figure out what tabs are in question

Would it? You have the index - can't you get to the tab from the tabset object? Maybe not, I guess I don't actually know.

You cite code duplicity as your reasoning

The code duplication is not huge, but it is there.

I add: deselect="func($event, $selectedIndex, this)" to every tab. It's identical on all the tabs so it seemed duplicative to me, so I suggested this feature. (The this gives me access to the tabset object from a controller in a parent scope, it's a single function I apply to every single tab on the site so I don't have direct access to the child scope.)

It's obviously not a big deal, it just seemed like it would be a nice feature.

Do we then also add a flag to dictate order?

Just pick one and that's all, the order rarely matters anyway, it just has to be specified. Not adding a feature because someone would want something else doesn't make sense - after all if you didn't add the feature they would have nothing. So better something than nothing.

Like I said, this isn't a huge deal, it just seemed like a nice addition to me.

[wesleycho]

I feel like moving it to the tabset makes a lot of sense - I might entertain that breaking change in a major release such as 3.0.0. That these functions are on the tabs also turns out to be buggy.