I had to create an embeddable and portable widget for one of our customers. What it seemed to be an easy task it had a number of challenges to overcome. On this blog post I am sharing those challenges and what I did to solve each one of them.
The third party JavaScript widget
Our customer wanted to have a calculator widget on its website for one its lab products. The widget had to be hosted in our servers and the calculation algorithm was to be somehow protected. As with any third party javascript widget, we face the following:
- We don't own the DOM, so forget about modifying the container page's CSS or altering the page
- We should avoid conflicts with site's script and its global scoped variables
- To encapsulate the algorithm in an API, thus our API should support CORS
CSS Inline Injection
If you cannot modify the container's CSS there is only a couple of solutions available in order to avoid overlapping with their site's style. One of them is using a tool like cleanslate, which provides the functionality to reset your widget's stylesheet providing a top-level namespace (cleanslate), that you use to style the HTML of your widget. But I was in a rush (had to do the widget in less than three days) and I also wanted to use bootstrap style elements and I didn't want to include the full CSS, so the other option was to use a technique I call: CSS Inline Injection.
The technique is very simple, we create the HTML of the form (call me lazy but I used an online tool for this task too: http://bootsnipp.com/forms), and then we "inject" the styles that the HTML classes specify into their elements themselves. For that task, I used the excellent tool created by "TijsVerkoyen": CssToInlineStyles.
Assuming you are on your project root and having composer installed on your computer globally:
composer require tijsverkoyen/css-to-inline-styles
Then I created the following script:
require('vendor/autoload.php'); // use composer vendor autoloader
use TijsVerkoyen\CssToInlineStyles\CssToInlineStyles;
// create instance
$cssToInlineStyles = new CssToInlineStyles();
// get the HTML of your bootstrap form
$html = file_get_contents(__DIR__ . '/form.html');
// get the CSS contents
$css = file_get_contents(__DIR__ .'/bootstrap.css');
// and finally save the HTML of the form with the inline injected styles
file_put_contents(__DIR__ . '/inline-form.html', $cssToInlineStyles->convert($html, $css));
After we do that, the form elements will have this nasty look:
<input id="{INPUT-ID}" name="{INPUT-NAME}" type="text" placeholder="Enter value in liters"
class="form-control input-md"
style="margin: 0; font: inherit; color: #555; line-height: 1.42857143; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; font-family: inherit; font-size: 14px; display: block; width: 100%; height: 34px; padding: 6px 12px; background-color: #fff; background-image: none; border: 1px solid #ccc; border-radius: 4px; -webkit-box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075); box-shadow: inset 0 1px 1px rgba(0, 0, 0, .075); -webkit-transition: border-color ease-in-out .15s, -webkit-box-shadow ease-in-out .15s; -o-transition: border-color ease-in-out .15s, box-shadow ease-in-out .15s; transition: border-color ease-in-out .15s, box-shadow ease-in-out .15s;"/>
It's ugly I know, but this way we do not need to add a big CSS file shipped with our widget. Nevertheless, I would say that my widget wasn't really big (only five inputs), if you need to create a bigger widget, I highly recommend you to check cleanslate. Very, very easy to use (wink).
Avoiding Script Conflicts
Here comes the fun part, we need to ensure that our code doesn't conflict with our beloved host. So, my first thought was to simply create a jquery module with a loader that ensures jQuery existed. The following is the pattern I was about to use:
; (function (MYNAMESPACE, undefined) {
// private variables here
// ...
// public methods
MYNAMESPACE.initialize = function () {
// initialization procedures here
initializejQuery();
};
MYNAMESPACE.scrollTo = function (id) {
jQuery('html,body').animate({ scrollTop: $("#" + id).offset().top - 120 }, 'slow');
};
// private methods
// ensure jQuery existed?
function initializejQuery() {
if (window.jQuery === undefined || (MYNAMESPACE.jQueryLatest && window.jQuery.fn.jquery !== '3.1.0')) {
injectScript(getProtocol() + 'code.jquery.com/jquery-3.1.0.min.js', main);
} else {
jQuery = window.jQuery;
main();
}
}
function getProtocol() {
return ('https:' == document.location.protocol ? 'https://' : 'http://');
}
function injectScript(src, cb) {
var sj = document.createElement('script');
sj.type = 'text/javascript';
sj.async = true;
sj.src = src;
sj.addEventListener ? sj.addEventListener('load', cb, false) : sj.attachEvent('onload', cb);
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(sj, s);
}
function main() {
// initialization magic
}
})(window.MYNAMESPACE = window.MYNAMESPACE || {});
That module pattern was good but that implied the usage of a third call to our API to get the form's html. So, I decided to use requireJs as it makes the process of an embeddable script very simple and it has an optimizer tool called r.js that takes care of dependency handling, uglifying, minifiying, etc...
Setting up the development environment
We will need requirejs, bower and gulp. If you don't have any of them, then you need to install them using npm package manager - I am assuming that you have nodejs installed in your development machine. We are at the project's root folder, so lets start with our our package.json file:
npm init
This will prompt us to answer a few questions and once completed, it will create a file in the root directory named package.json. This file provides information about the project and its dependencies. For more information, please see the great tutorial of Travis Maynard. Now, lets do the second step:
# install global dependencies if we don't have them
npm install -g requirejs
npm install -g bower
npm install -g gulp
# we also need to install gulp locally on our projects root
npm install --save-dev gulp
The -g parameter means that you install them globally. If you don't want to do that, you are free to install them locally on your project's directory by removing that parameter. The commands will be placed on the node_modules/.bin directory.
After, I needed to install the required packages for my gulp.js file. My tasks were really simple: use the requirejs optimizer tool and move the built to another location. So, I only installed gulp-run pipe plugin. The resulting gulp.js file was the following:
var gulp = require('gulp');
// include plugins
var run = require('gulp-run');
// use gulp-run to build requirejs optimizer
gulp.task('build', function () {
return run('r.js -o build.js').exec()
.pipe(gulp.dest('output'))
});
// use watch to automatically build when the file has been changed
gulp.task('watch', function () {
gulp.watch('js/*.js', ['build']);
});
gulp.task('move', ['build'], function () {
return run('cp ./dist/my-widget-min.js ~/path/api/web/js/').exec()
.pipe(gulp.dest('output'));
});
That file created three tasks: build, watch and move. The only thing I had to do was to call gulp move to have my plugin compiled and moved to the location of my local api service to test it.
As you can see on the above code is the use of the build.js file. That file is required for the requirejs optimizer tool. For requirejs there is a couple of files to do (please visit http://requirejs.org/ for further information). There is a number of processes and files to be done prior having that build.js:
Install bower components
We need almond (an AMD replacement loader for RequireJS), requireJs-Text (a text loader plugin) and jquery.
# https://github.com/requirejs/almond#almond
bower install almond
# https://github.com/requirejs/text
bower install requirejs-text
bower install jquery
Those commands will install the project dependencies into the bower_components folder.
Create RequireJs config.js file
For more information about the configuration options available, please visit: http://requirejs.org/docs/optimization.html#basics
var requirejs = {
paths: {
jquery: 'bower_components/jquery/dist/jquery',
text:'bower_components/text/text'
}
};
Create RequireJs build.js file
And finally our build.js file. This file tells the r.js optimizer tool the options on the command line when building your optimized file. Mine looked like this:
({
baseUrl:'',
mainConfigFile: 'config.js',
name: 'bower_components/almond/almond',
include: ['js/widget'],
out: 'dist/widget.min.js',
optimizeCss: 'standard', // if we need it
stubModules: ['text']
})
The actual widget.js file
I created a new js directory and created my widget.js file there:
require(["jquery", "js/app"], function($, app){
'use strict';
var config = {
// configuration parameters here
};
$(function() {
app.init(config);
});
});
This file worked as an entry script to initialize settings for the actual widget, the one that had all the widget functionality and dynamics was the app.js:
define(['jquery', 'text!template/form.html'], function ($, formHtml) {
'use strict';
// private variables here...
var settings, $form;
var app = {
init: function (config) {
// get the settings and make them available through the app
settings = config;
$(formHtml).insertAfter('element where to inject the form');
// get a reference of the form after is inserted
$form = $('#FORM-ID');
// call initialization methods
initializeEvents();
}
};
// example initialization
function initializeEvents() {
// here I have used the $form pointer to initialize the events on the form
}
return app;
});
My finished project folder structure look like this (dist is only created once I call gulp build or gulp move commands):
+- bower_components
+- node_modules
+- js
|-- widget.js
|-- app.js
+ dist
|- widget.min.js
+ template
|- form.html
build.js
config.js
gulpfile.js
package.json
I know it's not easy to follow, that's why I have created a template repository to ease the task to understand this process.
Embedding the widget
In order to embed the widget to the page, I opt for the following technique:
<script>
(function (window, document) {
var loader = function () {
var script = document.createElement("script"), tag = document.getElementsByTagName("script")[0];
script.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'example.js/widget.min.js';
tag.parentNode.insertBefore(script, tag);
};
window.addEventListener ? window.addEventListener("load", loader, false) : window.attachEvent("onload", loader);
})(window, document);
</script>
Add CORS support to your API
There are many ways to do it, but remember, I had no much time so I decided for the easiest, configuring our .htaccess file:
<IfModule mod_headers.c>
Header always set Access-Control-Allow-Origin *
Header always set Access-Control-Allow-Methods "POST,GET,DELETE,PUT,PATCH,DELETE,HEAD"
Header always set Access-Control-Max-Age 86400
Header always set Access-Control-Allow-Headers "Content-Type, Access-Control-Allow-Headers,
Authorization, X-Requested-With, Origin, Accept, Client-Security-Token"
</IfModule>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule . blank.html
You probably asking why I added all possible methods on my headers, that means all end points of my api do handle those methods? Well, the answer is no. My API is built upon request filters (or middlewares) that permit only certain methods. For example, my calculator API only permitted POST, so even if my headers are set to all possible methods, my API only support POST for that specific controller.
Why did I do it that way? The reason was a matter of speed and by adding that line on my .htaccess file I didn't have to provide an extra method on my API for each endpoint that specifies which methods were allowed. If I was to create a public API I would've changed it but for a private usage, I thought that by adding OAuth2 + Filtering options that was more than enough.
One interesting part is the last one. Let's check it again:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule . blank.html
I created a blank.html page and redirected all requests calls to OPTIONS to that page. So that request will always returned the allowed headers and doesn't need to go throughout the filtering process of my API routes. The reason for that call from the jQuery.ajax of your widget is because of preflighted calls: **Unlike simple requests, "preflighted" requests first send an HTTP OPTIONS request header to the resource on the other domain, in order to determine whether the actual request is safe to send.
**
