Navbar does not have a change event

[MattFriedman]

It seems to me that the navbar should have a change event to hook into when the active class has been added to the clicked item and removed from the others.

I don't see a way otherwise to ensure that the state change is completed before reacting to that event. As well, it looks like I need to manually monitor the navbar for changes in order to hook it into my app (unless I'm missing something) - it would make a lot more sense to have a change event issued.

I've thought of using the radio button control group instead which it seems to me could be styled to look just like the navbar. In fact, since a navbar follows the radio button paradigm why not implement the navbar based on radio buttons? Just a thought.

In any case, it would be ideal if the navbar had a change event.

Thanks.

[jaspermdegroot]

@MattFriedman

The navbar widget's add/remove active state logic is bound to the vclick event. You can bind to the same event, but would have to add a check to see if it's not the currently active button that was clicked.
I am not sure if we need to make it emit a change event, but I am flagging this ticket as feature request.

BTW - Basing the navbar on radio buttons doesn't seem semantically correct to me.

[MattFriedman]

Thanks so much for the response. :)

I'm not sure about the order in which the vclicks would be fired so I don't feel confident that I would be notified correctly. Emitting an event guarantees that there won't be any timing or ordering issues. IMO architecturally, the widget has all of the information about what was clicked and what wasn't; to me that indicates that the widget itself should own the responsibility of emitting an event. It seems to me that most everyone who uses the navbar will want to be notified of when someone clicked so again I'd say that responsibility belongs there. Otherwise, many who use the widget will have to implement their own sort of notification.

Semantically the navbar is set of choices and you can only choose one at a time. To me that is semantically identical to radio buttons. Styled similarly using the controlgroup styles it could also look identical to the current implementation. This would have the added benefit of the change event being built in.

In any case, I do really appreciate your attention to this. I think if you implement the feature you'll find a lot of folks to be very grateful.

Many thanks,
Matt

[jaspermdegroot]

Closing as feature request. We will consider this when working on #6337.