The Problem
I came up with this select-box variant in answer to a question on UX.SE: https://ux.stackexchange.com/a/48951/16187

enter image description here

However, working out how to implement it has been driving me mad ever since I wrote that post.

What I've tried
Initially I figured it would be easy enough to do.

The strategy I would have taken would be to model all the options in a javascript object, with their own name and selected properties, and then write a view function to display them as an unordered list or something.

I could then create the button as another javascript object, modelling it's own state, and have a view function spiting it out a representation of it into the widget. Maybe throw in some event code for transitioning between button states and I'm done.

Where I'm Stuck
The more I thought about that approach, the more I realised that having all of the state sitting in javascript objects was a terrible idea. I figured that I should probably store the state in the dom, and mutate it with javascript.

However I have no clear idea what that sort of architecture would look like, or how I should go about coding it.

Can you help me work out what a better high level implementation strategy for this sort of widget looks like?

  • 1
    There is never a best way to do something. Only the way which works best for you.
    – Philipp
    Dec 13, 2013 at 11:54
  • @Philipp I agree in principle, but in practice I know there will always be some ways that are worse than the others, no matter who is implementing them. Here, I'm good enough to spot that my way is a bad one, but not good enough to spot what the actual good way looks like.
    – Racheet
    Dec 13, 2013 at 16:50
  • (Also: point taken; question improved.)
    – Racheet
    Dec 13, 2013 at 16:52

1 Answer 1


Why would you think that having the state in js would be bad? I think it's as good as in the DOM, if not better.

Anyway, you most likely already have the state in the DOM, since for display purposes you will add/remove classes from the list elements. In such cases I often just let jQuery find all elements with a certain class within the list. Get the amount of those elements and you already know how many were selected.

Put all of this functionality (count objects with class "selected_list_thing", update button state) in a function and add an mouse click handler to your list elements. There switch the class (eg add or remove "selected_list_thing" is blue) and then call the function you defined to update the button.

  • One of the issues with having the state in javascript rather than html is that if I want to add new options, I've got to go and fiddle with the javascript, not just add another <li>.
    – Racheet
    Dec 13, 2013 at 11:57
  • @Racheet good point, having a fixed sized array or similar would make things ugly. So at a minimum it would have to get the amount of items in the list at page load. And then if you want to make it even more dynamic and add options at run time it gets worse. This 'class based state' I described worked very well for me, even with hierarchical elements where sub-lists are loaded at run time. If you need even more information within the DOM and attach to an element then maybe jQuery.data() would be interesting too. Dec 13, 2013 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.