Feedback: JavaScript usage

[gakimball]

We've made a few fundamental changes to how the JavaScript is structured, which we'd like the community's feedback on.

All plugins are classes. This allows them to be initialized and manipulated programmatically.

var $elem = $('#modal');
var modal = new Foundation.Reveal($elem, {
  overlay: false,
  fullscreen: true
});

Individual options can be added as data attributes. data-options will still be available also.

<div class="reveal" data-reveal data-overlay="false"></div>

(Most) plugins don't generate markup. This makes plugins easier to reform with HTML, and cuts down on the number of plugin options that are just for changing elements. Orbit is a good example—it doesn't generate any HTML, which means if you don't want a piece of it, you just remove it from the markup.

<div class="orbit" data-orbit>
  <ul class="orbit-container">
    <button class="orbit-control orbit-previous"><span class="show-for-sr">Previous Slide</span>&#9664;</button>
    <button class="orbit-control orbit-next"><span class="show-for-sr">Next Slide</span>&#9654;</button>
    <li class="active">
      <img class="orbit-image" src="http://placecage.com/800/500" alt="Intropsective Cage">
      <figcaption class="orbit-caption">Woah. Nicolas Cage.</figcaption>
    </li>
    <li>
      <img class="orbit-image" src="http://placecage.com/800/500" alt="Intropsective Cage">
      <figcaption class="orbit-caption">Woah. Nicolas Cage.</figcaption>
    </li>
  </ul>
  <nav class="orbit-bullets-container">
    <button class="is-active" data-slide="0"><span class="show-for-sr">First slide details.</span><span class="show-for-sr">Current Slide</span></button>
    <button data-slide="1"><span class="show-for-sr">Second slide details.</span></button>
  </nav>
</div>

[juliancwirko]

Hi, I just wanted to say that it is also important to have a simple method to destroy a plugin and clean DOM. I mean when some js plugin will create some DOM elements sometimes there is a problem in such frameworks like Meteor because we need to destroy and clean all created DOM when some part of the app (which uses this plugin) will be destroyed. We don't have here whole DOM reload. I hope there will be a full plugin lifecycle API :) so for example:

var $elem = $('#modal');
var modal = new Foundation.Reveal($elem, {...});
(...)
modal.destroy(); // so for example when I will destroy my template in Meteor I want to clean the modal usage - I want to clear memory and DOM

Also $('...').foundation('reflow') will be important here, so we will be able to refresh initializated plugin or even modal.reflow()

ps. I saw that you will be supporting official Meteor package. This is great news! Remember to reserve your 'zurb' organization on Meteor Dev accounts so you will be able to use 'zurb:foundation' on http://atmospherejs.com ;) also I hope that this will be a package with Scss and not only static js and css files ;)

[gakimball]

@juliancwirko Every plugin should have a .destroy() method. If one doesn't, then we still need to implement it.

[rmartin]

hey @gakimball ,

First of all, thanks for all of your and the teams hard work on F6. There are a lot of great additions, including the new proposal for the plug-in architecture. Overall i think this is a good idea and I had a chance to review the code to get a better sense for how you're keeping track of the various instances of the plugins and registering those within the namespace.

One topic I wanted to bring up for discussion was the class style implementation. Have you considered potentially implementing the OLOO style as an alternative to the class approach? Looking through the code specifically with the reveal plugin, it doesn't appear that it's really leveraging any inheritance structure and that the 'class' implementation is more of a namespacing solution to encapsulate the instance of that plug-in. It also appears to cause a fair amount of extra work to encapsulate the this keyword in the correct scope which is adding some additional code and challenges making the various methods public / private.

It would seem that if we were to leverage a style similar to the OLOO style, it would be able to eliminate the 'new' prefix requirement and also greatly simplify the internal organization of the private / public methods. So instead of needing to setup all the methods as a prototype we'd be able to simply structure those methods separately and simply create the object on the fly.

Is that something that you've considered or think might be a worthwhile addition to explore? I know that feedback such as 'you should do X instead of Y' isn't very constructive. However, if this approach is something you'd be interested in exploring I'd be happy to work together to see how this style might work by refactoring one of the plug-ins.

References:

• You Don't Know JS - This & Object Prototypes
• OLOO vs Prototype Design Pattern
• JavaScript Pattern Comparison - John Dugan

Cheers, Roy

[gakimball]

@rmartin I'll see if @zurbchris wants to chime in on this.

We definitely can't re-architect everything right now. I will say we have ES6 in the back of our heads, at which point we'd be converting these function-based classes to ES6 classes. Since we'd have to make the switch after version 6.0.0 comes out, that would be the easiest way to keep everything backwards-compatible.

[zurbrandon]

Thanks for all the feedback, everyone! The team has went over all these discussion topics and have either incorporated the feedback, have a plan to incorporate I or decided to not include it.

We'll close these topics, but feel free to keep adding and discussing if you'd like.