Pattern for incorporating modals – examples for Semantic UI, Bootstrap, and Foundation


#1

Over the last couple of months, I’ve been trying to optimize the use of modals in my project. The project uses Semantic UI, which has a nice set of components implemented with jQuery.

I’ve created this hackpad with the full pattern:

A pattern for incorporating modals

And here are some demos:

Blaze modals: Semantic UI
Blaze modals: Bootstrap
Blaze modals: Foundation

It would be great to get comments from people using other UI libraries. Can the pattern be applied to these libraries directly?

(This post was originally posed as a question, but since the answer is pretty clear, I’ve changed it to an announcement.)


#2

Here’s a meteorpad that I created using Foundation and your pattern: Need to select sign in twice the first time.

[MeteorPad - Modal test][1]
[1]: http://meteorpad.com/pad/3x4hpLTYqCkzggsGd/Modal

A couple of glitches…

  1. Not sure why you have to select sign in twice
  2. No idea where the iron router content is coming from.

#3

Cool – I’m checking it out now. The IronRouter stuff is there because no routes have been configured.


#4

If you check out my hackpad again, I did a tiny edit some time ago – instead of parent_view = template.view.parentView it is now parent_view = template.parent().view.

This is a straight bug-fix, but it relies on the aldeed:template-extension package for the parent() function, which finds the proper parent template’s view.

Try to edit your pad (or make it publicly editable) and let me know :sunny:


#5

Also, you have to destroy the Blaze View in the onHidden hook for the modal – I’m sure Foundation has something similar to Semantic’s – or there will be more and more hidden modals in the view hierarchy, leaking DOM nodes.

Thanks for taking the time to try this method out, btw.


#6

Thanks Deb - I’ll take a look a bit later and update. I’m not seeing a way to make the meteorpad publicly editable, but it looks as if you can fork it.


#7

I forked your pad, but ended up doing it from scratch, since it’s actually really simple with Foundation – this is all you need for the basic pattern:

Blaze modals: Foundation

I did some memory profiling, and there are no leaked nodes. Notice that I’m faking a Meteor.call with a setTimeout, btw.


#8

Turned out Bootstrap was really easy, too:

Blaze modals: Bootstrap


#9

Nice. I’ve switched to using materialize - I’ll give your approach a try. I ended up using anti:modals which worked well.


#10

Is there any way of passing parameters to the modal from the template?

In a “traditional” way, you could add for example some attributes to the a/button/input element that’s triggering it, but with this way any parameters you add to the {{#appModalOpen}} go to the appModalOpen template instead of the final template, so inside the modal you don’t what triggered it…


#11

The data context of the modal is given as the second argument to Blaze.renderWithData.