Archive: JavaScript
Wednesday 31 July 2013 10:28
For the same reasons that breaking down programs into short, composable functions is a good idea, it seems like breaking down web code into short, composable web widgets would be a good idea. (By web widget, I mean the HTML, CSS and JavaScript that go together to implement a particular piece of functionality.) Having shorter snippets makes code easier to understand and change, with the potential for reuse.
Yet it feels like there's no good way of sharing the HTML, CSS and JavaScript that go together to implement a particular piece of functionality. For instance, the usual way of creating a web widget using JQuery is to create a JQuery plugin, but there's no natural way of using such a JQuery plugin from Knockout. Over the past few days, I've tried an experiment in creating web widgets that can be written and consumed independently of technology.
First of all, I've defined a widget as being a function that accepts a single options argument. That options argument must contain an element property, which is the element that will be transformed into the widget (for instance, we might turn an <input> element into a date picker). The options argument can also contain any number of other options for that widget. The interface is kept simple so it's easy to implement, while still being sufficiently general. It's not exactly something to write home about, but the value is in choosing a fixed interface.
Now that we've defined the notion of web widget, we'll want to start consuming and creating widgets. For instance, we can create a widget that will turn its message option to uppercase wrapped in <strong> tags:
function shoutingWidget(options) {
var element = options.element;
var contents = options.message.toUpperCase();
// Assuming that we've defined htmlEscape elsewhere
element.innerHTML = "<strong>" + htmlEscape(contents) + "</strong>";
}
We can use it like so:
shoutingWidget({
element: document.getElementById("example"),
message: "Hello!"
});
which will transform the following HTML:
<span id="example"></span>
into:
<span id="example"><strong>HELLO!</strong></span>
However, most of the time, I'm not writing web code using raw JavaScript. So, for any given web framework/library, we can start to answer two questions:
- What's the easiest way we can consume a widget?
- What's the easiest way we can create a widget?
In particular, when a widget is used, we shouldn't care about the underlying implementation. Whether it was created using jQuery or Knockout or something else, we should be able to use it with the same interface.
Let's see how this works with Knockout. To create a web widget, I call the function knockoutWidgets.widget() with an object with an init function, and I get back a widget (which is just a function). The init function is called with the options object each time the widget is rendered. The init function should return the view model and template for that widget. For instance, to implement the previous example using Knockout:
var shoutingWidget = knockoutWidgets.widget({
init: function(options) {
var contents = options.message.toUpperCase();
return {
viewModel: {contents: contents},
template: '<strong data-bind="text: contents"></strong>'
}
}
});
To consume widgets from Knockout, we have to explicitly specify dependencies. By avoiding putting all widgets into a single namespace, we avoid collisions without using long, unwieldy names. For instance, to create an emphatic greeter widget that transforms:
<span id="example"></span>
into:
<span id="example">Hello <strong>BOB</strong>!</span>
we can write:
var emphaticGreeterWidget = knockoutWidgets.widget({
init: function(options) {
return {
viewModel: {name: options.name},
template: 'Hello <span data-bind="widget: \'shout\', widgetOptions: {message: name}"></span>!'
}
},
dependencies: {
shout: shoutingWidget
}
});
emphaticGreeterWidget({
element: document.getElementById("example"),
name: "Bob"
});
Importantly, although we've created the widget using Knockout, any code that supports our general notion of a web widget should be able to use it. Similarly, emphaticGreeterWidget can use shoutingWidget regardless of whether it was written using Knockout, raw JavaScript, or something else altogether.
Although I've successfully used this style with Knockout for some small bits of work, there are still two rather major unsolved problems.
The first problem: how should data binding be handled? All the above examples have data flowing in one direction: into the widget. What if we want data to flow in both directions, such as a date picker widget?
The second problem: should content within widgets be allowed? Our shouting widget had the message passed in via the options argument, but it could have been specified in the body of the element that the widget was applied to. Using raw JavaScript, that means a definition that looks something like:
function shoutingWidget(options) {
var element = options.element;
var message = "message" in options ? options.message : element.textContent;
var contents = message.toUpperCase();
// Assuming that we've defined htmlEscape elsewhere
element.innerHTML = "<strong>" + htmlEscape(contents) + "</strong>";
}
If we allow content within widgets, then we have to work out how the widget interacts with the content and the web library in use. For instance, if we're using Knockout, do we apply the bindings before or after the widget is executed? How should the widget detect changes when its children change as a result of those Knockout bindings?
Also notably absent from the examples was any mention of CSS, despite my earlier mention. The reason: it hasn't been needed in my small experiments so far, so I haven't thought that much about it! It's something that will need dealing with at some point though.
Thoughts on the overall idea or those specific problems are welcome! You can take a look at the code on GitHub.
Topics: HTML, JavaScript
Sunday 9 September 2012 20:47
Note: this post assumes you already have some familiarity with
applicative functors
In this post, I'll show how to implement applicative functors in JavaScript,
specifically for options, and then show an alternative formulation that's
arguably better suited to languages that generally have uncurried functions
(that is, languages that tend to have functions that accept multiple arguments
rather than a single argument).
First of all, let's implement the option type (otherwise known as the maybe
type) in JavaScript as a functor:
var none = {
map: function(func) {
return none;
},
bind: function(func) {
return none;
},
toString: function() {
return "none";
}
};
function some(value) {
return {
map: function(func) {
return some(func(value));
},
bind: function(func) {
return func(value);
},
toString: function() {
return "some(" + value + ")";
}
};
}
var functor = {
map: function(func, option) {
return option.map(func)
},
unit: some,
applyFunctor: function(funcOption, argOption) {
return funcOption.bind(function(func) {
return argOption.map(func);
});
}
};
We can then use option values as applicative functors. Let's try our
implementation out to make sure it behaves as we expect:
var four = some(4);
var six = some(6);
function add(first, second) {
return first + second;
};
function curry(func, numberOfArguments) {
return function(value) {
if (numberOfArguments === 1) {
return func(value);
} else {
return curry(func.bind(null, value), numberOfArguments - 1);
}
};
}
functor.applyFunctor(functor.map(curry(add, 2), four), six);
// => some(10)
functor.applyFunctor(functor.map(curry(add, 2), none), six);
// => none
functor.applyFunctor(functor.map(curry(add, 2), four), none);
// => none
Note that the use of the functor required us to curry the add
function. This isn't a problem in functional languages such as Haskell, since
functions tend to be curried by default. However, in languages that usually
define functions to have multiple arguments (uncurried languages, for short), such as JavaScript, things
get a little untidy.
My understanding of applicative functors is that they allow functors, or
rather map, to be generalised to functions that accept more than
one argument, such as add. Therefore, in an uncurried language,
we might imagine the following cleaner API:
functor.applyFunctorUncurried(add, four, six);
// => some(10)
functor.applyFunctorUncurried(add, none, six);
// => none
functor.applyFunctorUncurried(add, four, none);
// => none
And such an API turns out to be not too hard to implement:
functor.applyFunctorUncurried = function(func) {
var args = Array.prototype.slice.call(arguments, 1);
return args.reduce(
functor.applyFunctor,
functor.unit(curry(func, args.length))
);
}
Interestingly, the implementation of applyFunctorUncurried is most
easily expressed in terms of the original applyFunctor. I've found
cases like this explain why functional languages tend to favour curried
functions: it often makes the implementation of higher-order functions
such as applyFunctor much more straightforward.
This raises an interesting question: are these two formulations of
applyFunctor of equal power? That is, is it possible to implement
each in terms of the other? It's straightforward to see that we can implement
applyFunctorUncurried in terms of applyFunctor since
it's precisely the implementation above. What about implementing applyFunctor
in terms of applyFunctorUncurried? This turns out to be
pretty straightforward too:
function applyFunctor(funcFunctor, argFunctor) {
return functor.applyFunctorUncurried(apply, funcFunctor, argFunctor);
}
function apply(func, value) {
return func(value);
}
Please let me know if you spot mistakes in any of the above -- I've not
exactly been rigorous in proof!
I'd be curious to know if there are any languages that include the
alternative formulation of applyFunctor, and whether there are
common cases where the original formulation is preferable even in uncurried
languages.
Topics: Functional programming, Language design, JavaScript
Saturday 9 June 2012 21:49
HTML has the <noscript> tag for when you want an element to be displayed if
and only if JavaScript is disabled, but what if you want the opposite? How do
you display an element if and only JavaScript is enabled? I came
across a
rather tidy solution on StackOverflow. In the <head>,
we add the following:
<noscript>
<style>
.iff-javascript-enabled {
display: none;
}
</style>
</noscript>
We then add the iff-javascript-enabled class to the appropriate
elements:
<noscript><p>JavaScript is disabled</p></noscript>
<p class="iff-javascript-enabled">JavaScript is enabled</p>
The advantage of this solution over others is that there's no delay. Most other
solutions hide the relevant elements by default, and then use JavaScript to show
them, but this means that the elements are hidden until that piece of
JavaScript fires. However, in some cases this is desirable. For instance, suppose an
element does nothing until some JavaScript hooks up an onclick handler. Showing
that element before the onclick handler is added might be frustrating since
clicking the element would do nothing.
Still, there's a simplicity to this solution that I quite enjoy.
Topics: HTML, CSS, JavaScript
Saturday 22 October 2011 09:20
When talking about node.js, I usually hear people give two reasons why they love it. The first is that it uses an event-driven model for concurrency, rather than using threads and blocking function calls. The second is that node.js allows you to use the same language, JavaScript, on both the browser and the server. You can then share logic that might otherwise be duplicated, such as validation of user input. Yet people often dismiss the latter point, saying that when they do web development, the amount of logic that ends up being duplicated is neglible, since the code on the browser and on the server address different concerns.
My question is: have we got this the wrong way round? Does code on the browser and server tend to address separate concerns precisely because sharing logic between them is hard? Once we start using the same language on both sides, we might start to see new ideas that this brings to the table. With modern web applications, we see more and more code that we might have previously expected to see on the server being brought into the browser. If we can easily move code between the browser and server, then we start to have an enourmous amount of flexibility: we can easily change our minds about where some particular code should be executed both when building our application, and at run-time.
Topics: JavaScript, Software design