Skip to content

Foundation 7: JavaScript plugin initialization #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Foundation 7: JavaScript plugin initialization #13

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions proposals/f7-javascript-plugin-initialization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Foundation 7: JavaScript plugin initialization

## Introduction
Foundation JavaScript architecture is really a piece of beauty, and you can easily proof that by opening the `foundation.core.js` then you will clearly notice these arguments:
- Wrapping the whole stuff in a namespace
- Registering and Unregistering the plugins
- Smart initializing technique
- Storing the initialized plugins
- And more...

One more thing, Foundation JavaScript plugins are not defined directly to jQuery, but they are completely live in that isolated namespace which is called Foundation, that kind of isolation gives Foundation the power to manage those plugins and keep them away from jQuery’s plugins and other worlds!

I am not going to describe the other strengths of the Foundation JavaScript architecture, but I would only like to make you notice that Foundation really has the principles of the Scalable Architecture.

## Foundation JavaScript plugin initialization
Foundation is smart enough to recognize the elements that should be initialized, it looks for any element that has the data attribute, for example: data-dropdown, and once Foundation finds that plugin name in the registered plugins list, it will initialize that element. Additionally, Foundation will collect and merge the plugin’s options from three resources: plugin’s default options, the value of `data-options`, and the individual data attributes.

However, what about if Foundation is used with any other non-Foundation JavaScript plugin or framework? I am sure mixing UI frameworks is not recommended, but as you know there are many other front-end frameworks that don’t target the UI but the data binding, so let’s assume this scenario:

You have a non-Foundation JavaScript plugin that requires this data attribute `data-what-ever`, while you also have a Foundation JavaScript plugin that assume `data-what-ever` is a plugin name or an option name. That is a very simple example of the expected conflicts, and regardless that conflicts, Foundation is assumed to be used even partially, that means you can only use one plugin from Foundation in your application and that implicitly means you will use another bunch of other JavaScript code, so in this case Foundation must not assume that all data attributes are reserved for it!

## Solution
I would suggest these two steps to solve that:
- Adding a namespace to the data attribute of the plugin name and the plugin’s options, so the data attributes should look like: `data-zf-plugin-name` and `data-zf-options`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wether in Sass, JS, HTML (ect...), everywhere we work on the global namespace, we can't declare names without prefixs. The probability of naming collisions are too high, and they are often incorrigible for the user.

So YES, we should use a Foundation namespace, thank you !

About data- attributes :

JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to make the exact name used in the attribute names customizable, so that libraries whose authors unknowingly picked the same name can be used on the same page, and so that multiple versions of a particular library can be used on the same page even when those versions are not mutually compatible. -- W3C

However, I think zf is rare enough for we use it as prefix without risk of a naming collision.

- Removing the previous data individual options, and keep all the passed options in `data-zf-options`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it makes difficult the change of an option through HTML ? If yes, we have to ensure that all options can be modified through Foundation. in Js.


I think that will help Foundation to be easily mixed with any other JavaScript plugins and avoiding any expected naming conflicts, and the most important is to free the data attribute to be used from others.