I am building a three-way selector: companies, departments and users.

I am trying to figure out the best way to structure this in my Backbone app. Here's the current problem I'm having.
Say a user has selected a company. Then, the departments and user collections will be populated and the view will update:

The user can then select a department from the list, which will further refine the user select. This I have working well.
Or, the user can go straight to User list and find a user (without first having to specify a department). In this case, the view for both departments and users needs to update:
I am struggling with the best way to do this. So far, my departments and users collections have a selected property, so that's how I'm maintaining state. Currently I'm doing something like
departments collectionI do this because if I had the view only trigger the event (without setting the departments selected property first), I would have a race condition: both the departments and users collections would be responding to the event, and depending on the timing the users may not be properly refined.
The second piece:
users collectiondepartments collection (which it knows about)and this is where I'm stuck. The departments collection doesn't really need to do anything, since its selected property is already correct; really, its view just needs to re-render. And so does the users' view.
But this is not all, because there are lots of other things that can happen. I feel like it's getting out of control.
Update: Should I just use routes to save application state? This may simplify things...
Update 2: This question has been helpful to me. Having a separate model to manage state definitely seems the way to go.
Update 3: Having a separate model to store state + the use of jQuery deferreds is amazing. Seriously. It completes me.
I find it useful to use a model for keeping track of the state. That way you can pass that model around to different views and don't have views referencing each other directly.
You can use built-in and custom events on the state model to manage state transitions.
In your case collections would not need to store selected. Instead selectedUser and selectedDepartment could be attributes of the state model.
Then you could have logic in your model that triggers custom events ('update:users:view' or 'update:departments:view') depending on what is selected.
I hope that makes sense.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With