Zurb Foundation for Sites 6 allows you to design and develop your own custom responsive plugins. As previously mentioned in What’s new in Zurb Foundation 6, plugins help facilitate consistent integration and enable extensibility. Foundation comes with several out of the box plugins such as accordion, dropdown, menu, reveal, slider, and tooltip. Foundation is great at getting you most of the way there, but sometimes it is not enough. Your project or client may require more specific functionality. However, Zurb has deemed these too broad to include in the base framework. This is fair. Most frameworks work this way, at least in the beginning. jQuery, Java, and Microsoft .NET have ballooned in size with features that most of us never use. Worse, it’s difficult or near impossible to cherry pick only what you need. Unfortunately, it can be all or nothing, but I digress.
I find it helpful to think of plugins using this analogy: Zurb is an electrical outlet that provides responsive framework power. A Zurb plugin is the pronged ending that literally “plugs” into the Zurb Foundation outlet.
Zurb is an electrical outlet that provides responsive framework power.
Boilerplate Skeleton Code
reveal with three dropdowns (one for day, month, and year). Example markup for a Zurb datetime plugin is shown here:
In the traditional object-oriented programming world, the aforementioned datepicker composes one or more existing components. When the datepicker is destroyed via
destroy (see below), the three dropdowns are also destroyed. Depending on your plugin, destroy can mean DOM removal and unbinding events. A custom Zurb plugin that owns (or wraps) another component that has no meaning or purpose outside the context of the plugin, is an example of composition. Each dropdown would not make sense outside the container component. They have a strong association to the datepicker plugin. Moreover, each would probably look terrible on their own and confuse users. Arrows bookending a filmstrip slider, a legend within a chart component, and a sortable grid column header are some other examples of not existing well on their own.
The idea is to not fight against the framework. Work with it.
These examples have me thinking. Specifically, the sortable grid column has me thinking about, grids. Can traditional reporting data grids be responsive? Anything can be made responsive, but will it provide meaningful value to users? Do tabular data grids even fit in the responsive world? I do not know or have answers to these questions as “mobile-first data grid” does not roll off the tongue well. I need to do some research, find use cases, and see what Zurb’s stacked table offers. If you have thoughts or ideas, please leave a comment or email me directly. Also a Zurb pie, bar, scatter plot, or line chart plugin sounds like a potential useful open-source project. Does anyone want to create a new Github repository? Again, I digress. Back to plugins.
Plugin methods prefixed with an underscore are considered part of the internal API, which means they could change, break, or disappear without warning.
At minimum, your plugin should contain these methods (technically
_events are not required, but it’s a good idea to have these separate for readability):
constructor(element, options)- class constructor to initialize, create, and register your plugin. Zurb 6 utilizes Babel to transpile to prototype-based ES5. This is also the place to register any
destroy()- destructor for clean up tasks: DOM removal, unbind events, and unregister your plugin.
_init()- initialize or
reInitto reinitialize, reset/remove event listeners, recalculate position, etc.
_events()- define and setup events. The fictional datepicker previously described might trigger
isValidevents. It might also decide to bind and handle dropdown events, encapsulating or forwarding them to plugin users.
How are plugins managed by the framework? Inside the
destroy methods are calls to
Foundation.unregisterPlugin. Each are found in
foundation.core.js and described below:
registerPlugin is how your plugin announces to the Zurb framework, “Hey, I am here!” Foundation stores a unique id pointer (think C# or Java reference) for each plugin instance in an internal
Array and then triggers the plugin’s initialization event. Additionally, it adds the
zfPlugin data-attribute to allow your plugin to be used programmatically like this:
$('#myZurbPlugin').foundation('destroy');- I am done with you. Now go away and make sure you clean yourself up.
$('#myZurbPlugin').foundation('formatTime');- Call the publicly available
formatTimefunction on a custom datepicker plugin.
$('#myZurbPlugin').foundation('buyKrisCoffee');- Buy Kris a cup of coffee.
unregisterPlugin is the way your plugin announces to the Zurb framework, “Hey, I am done!” Foundation removes the unique id pointer from the internal
Array, removes the added
zfPlugin data-attribute to clear stored data, and iterates over the object’s property collection setting each to
null to help nudge garbage collection. Finally, it triggers the plugin’s
Zurb Foundation 6 for Sites plugins are a great way to roll your own responsive components and provide missing pieces for your project under a consistent framework. If you follow some guidelines and work with (not against) the framework, plugins are a breeze. This allows you to focus on your project’s specific needs. Zurb plugins are a good way to isolate, manage, and reuse your custom code.
I hope to have a non-fictitious Zurb datepicker plugin available soon if there is interest. Additionally, I decided to not discuss namespacing and publishing a custom Zurb plugin package to NPM at this time. Please stay tuned for a future post.
Disclaimer: I am a Foundation fan, user, and minor open-source contributor.