# Modal Views - can we agree on a best practice? **URL:** \ **Category:** Uncategorized\ **Created:** [March 23, 2013, 12:37am UTC](https://discuss.emberjs.com/t/modal-views-can-we-agree-on-a-best-practice/707 "2013-03-23T00:37:39Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![jacobk](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.emberjs.com/jacobk/32/14280_2.png) [@jacobk](https://discuss.emberjs.com/u/jacobk)\ **Post date:** [March 23, 2013, 5:18pm UTC](https://discuss.emberjs.com/t/modal-views-can-we-agree-on-a-best-practice/707/4 "2013-03-23T17:18:29Z")
Some good ideas on this topic was brought up in [this thread about Discourse’s modals](http://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344). > [@Should discourse have so much logic in their modal views?](https://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344/2): > > I also try to make my controllers as thin as possible by moving events into the route. Unfortunately if a view does not represent a higher state (and thus no route exists for it), and might be re-used in any route, I either use App.ApplicationRoute to handle its events, or handle its events in its controller. Elegantly formulates the lack of mapping to a “higher state” which I think is true for many modal scenarios. > [@Should discourse have so much logic in their modal views?](https://discuss.emberjs.com/t/should-discourse-have-so-much-logic-in-their-modal-views/344/9): > > I think a good, clean approach (especially with complex modals) is to have a stateManager control when a modal is shown or hidden, and more precisely, when a modal is inserted or removed from the DOM. > > My basic architecture for this in pseudocode is: > > create a modalStateManager object and an instance that is globally accessible put an outlet (e.g., {{outlet modal}} for the modal in your main template (i.e., the template where the user will click to open the modal) when user clicks to open modal, call an open function on your modalStateManager instance open function renders the modalView, modalTemplate and modalController into the modal outlet. (in old ember, you could do this with connectOutlets, I believe the new way is with renderTemplate) you’d then also have some function that closes modal (and can destroy the modal). > > I actually did a presentation on this topic at the Ember.js meetup: it’s old ember, but the architecture should still be valuable. [https://speakerdeck.com/ashaegupta/managing-modals-and-other-non-url-based-views-in-ember-dot-js](https://speakerdeck.com/ashaegupta/managing-modals-and-other-non-url-based-views-in-ember-dot-js) Brings up the usage of how `StateManger`s could be used for modals. I think there might be a lot of cool stuff that could be done with state machines for both simple and more complex, wizard flow kind of, modals. I think [this part](http://www.youtube.com/watch?&v=B8vyxHZc4fo#t=936s) of Peter Bergströms “Ember.js in the Wild” [(slides)](https://speakerdeck.com/schmonference/ember-dot-js-in-the-wild?slide=24) talk shows some really cool use cases for StateManagers which would marry well with modals. Another requirement on modals should be that they need to work well with browser history (back/forward buttons). E.g. Discourse’s modals remain on screen even when you navigate away from the context that triggered them. --- _[View the full topic](https://discuss.emberjs.com/t/modal-views-can-we-agree-on-a-best-practice/707)._