You, the enterprising programmer, know about parsing EXIF from photos in the browser and even how and why to power this parsing with web workers. “But,” you ask yourself, “how do I get those photos into the browser in the first place?”
The oldest and most low-tech solution is the venerable <input type="file" name="foo">. This plops the old standby file button on your page and POSTs the file’s contents to your server upon form submission.
To address many of this simple control’s limitations we debuted a Flash-based file uploader in 2008. This workhorse has been providing per-file upload statuses, batch file selection, and robust error handling for the last four years through Flash’s file system APIs.
These days we can thankfully do this work without plugins. Not only can we use XHR to POST files and provide all the other fancy info we’ve long needed Flash for, but now we can pair this with something much better than an <input>: drag and drop. This allows people drag files directly into a browser window from the iPhotos, Lightrooms, and Windows Explorers of the world.
Let’s take a look at how this works.
Foundations first
Workmen laying the cornerstone, construction of the McKim Building by Boston Public Library
Let’s begin with our simple fallback, a – yes – <input type="file">.
HTML: <input type="file" multiple accept="image/*,video/*">
JS: Y.all('input[type=file]').on('change', handleBrowse);
Here we start with an <input> that accepts multiple files and knows it only accepts images and videos. Then, we bind an event handler to its change event. That handler can be very simple:
function handleBrowse(e) {
// get the raw event from YUI
var rawEvt = e._event;
// pass the files handler into the loadFiles function
if (rawEvt.target && rawEvt.target.files) {
loadFiles(rawEvt.target.files);
}
}
A simple matter of handing the event object’s file array off to our universal function that adds files to our upload queue. Let’s take a look at this file loader:
function loadFiles(files) {
updateQueueLength(count);
for (var i = 0; i < files.length; i++) {
var file = files[i];
if (File && file instanceof File) {
enqueueFileAddition(file);
}
}
}
Looks clear – it’s just going over the file list and adding them to a queue. “But wait,” you wonder, “why all this queue nonsense? Why not just kick off an XHR for the file right now?” Indeed, we’ve stuck in a layer of abstraction here that seems unnecessary. And for now it is. But suppose our pretty synchronous world were soon to become a whole lot less synchronous – that could get real fun in a hurry. For now, we’ll put that idea aside and take a look at these two queue functions themselves:
function updateQueueLength(quantity) {
state.files.total += quantity;
}
function enqueueFileAddition(file) {
state.files.handles.push(file);
// If all the files we expect have shown up, then flush the queue.
if (state.files.handles.length === state.files.total) {
for (var i = 0, len = state.files.total; i < len; i++) {
addFile(state.files.handles[i]);
}
// reset the state of the world
state.files.handles = [];
state.files.total = 0;
}
}
Pretty straightforward. One function for leaving a note of how many files we expect, one function to add files and see if we have all the files we expect. If so, pass along everything we have to addFile() which sends the file into our whirlwind of XHRs heading off to the great pandas in the sky.
Droppin’ dragons
Droppin’ dragons by Phil Dokas
While all of that is well and good, it was all for a ho-hum <input> element! Let’s hook a modern browser’s drag and drop events into this system:
document.addEventListener('drop', function(e) {
if (e.dataTransfer && e.dataTransfer.files) {
loadFiles(e.dataTransfer.files);
}
});
The drag and drop API is a fairly complicated one, but it thankfully makes the task of reading files out of a drop event easy. Every drop will have a dataTransfer attribute and when there’s at least one file in the drag that member will itself have a files attribute.
In fact, when you’re only concerned about handling files dragged directly into the browser you could call it a day right here. The loadFiles() function we wrote earlier knows how to handle instances of the File class and that’s exactly what dataTransfer.files stores. Easy!
Put it up to eleven
While easy is a good thing, awesome is awesome. How could we make dragging files into a browser even better? Well, how about cutting down on the trouble of finding the folder with your photos somewhere on your desktop, opening it, and then dragging those files into the browser? What if we could just drag the folder in and call it a day?
Try to drag a folder into the browser with the current state of our code; what happens? Our code tells the browser to treat all dropped file system objects as files. So what ultimately happens for folders is a very elaborate “nothing”. To fix this, we need to tell the browser how to handle directories. In our case, we want it to recursively walk every directory it sees and pick out the photos from each.
From here on out we’re going to be treading over tumultuous land, rife with rapidly changing specs and swiftly updating browsers. This becomes immediately apparent in how we begin to add support for directories. We need to update our drop event handler like this:
document.addEventListener('drop', function(e) {
if (e.dataTransfer && e.dataTransfer.items) {
loadFiles(e.dataTransfer.items);
}
else if (e.dataTransfer && e.dataTransfer.files) {
loadFiles(e.dataTransfer.files);
}
});
Items? Files? The difference is purely a matter of one being the newer interface where development happens and the other being the legacy interface. This is spelled out a bit in the spec, but the short of it is that the files member will be kept around for backwards compatibility while newer abilities will be built in the items namespace. Our code above prefers to use the items attribute if available, while falling back to files for compatibility. The real fun is what comes next.
You see, the items namespace deals with Items, not Files. Items can be thought of as pointers to things in the file system. Thankfully, that includes the directories we’re after. But unfortunately, this is the file system and the file system is slow. And JavaScript is single-threaded. These two facts together are a recipe for latency. The File System API tackles this problem with the same solution as Node.js: asynchronicity. Most of the functions in the API accept a callback that will be invoked when the disk gets around to providing the requested files. So we’ll have to update our code to do two new things: 1) translate items into files and 2) handle synchronous and asynchronous APIs.
So what do these changes look like? Let’s turn back to loadFiles() and teach it how to handle these new types of files. Taking a look at the spec for the Item class, there appears to be a getAsFile() function and that sounds perfect.
function loadFiles(files) {
updateQueueLength(count);
for (var i = 0; i < files.length; i++) {
var file = files[i];
if (typeof file.getAsFile === 'function') {
enqueueFileAddition(file.getAsFile());
}
else if (File && file instanceof File) {
enqueueFileAddition(file);
}
}
}
Easy – but, there’s a problem. The getAsFile() function is very literal. It assumes the Item points to a file. But directories aren’t files and that means this method won’t meet our needs. Fortunately, there is a solution and that’s through yet another data type, the Entry. An Entry is much like a File, but it can also represent directories. As mentioned in this WHATWG wiki document, there is a proposed method, getAsEntry(), in the Item interface that allows you to grab an Entry for its file system object. It’s browser prefixed for now, so let’s add that in as well.
function loadFiles(files) {
updateQueueLength(count);
for (var i = 0; i < files.length; i++) {
var file = files[i];
var entry;
if (file.getAsEntry) {
entry = file.getAsEntry();
}
else if (file.webkitGetAsEntry) {
entry = file.webkitGetAsEntry();
}
else if (typeof file.getAsFile === 'function') {
enqueueFileAddition(file.getAsFile());
}
else if (File && file instanceof File) {
enqueueFileAddition(file);
}
}
}
So what we have now is a way of handling native files and a way of turning Items into Entries. Now we need to figure out if the Entry is a file or a directory and then handle that appropriately.
What we’ll do is queue up any File objects we run across and skip the loop ahead to the next object. But if we have an Item and successfully turn it into an Entry then we’ll try to resolve this down to a file or a directory.
function loadFiles(files) {
updateQueueLength(count);
for (var i = 0; i < files.length; i++) {
var file = files[i];
var entry, reader;
if (file.getAsEntry) {
entry = file.getAsEntry();
}
else if (file.webkitGetAsEntry) {
entry = file.webkitGetAsEntry();
}
else if (typeof file.getAsFile === 'function') {
enqueueFileAddition(file.getAsFile());
continue;
}
else if (File && file instanceof File) {
enqueueFileAddition(file);
continue;
}
if (!entry) {
updateQueueLength(-1);
}
else if (entry.isFile) {
entry.file(function(file) {
enqueueFileAddition(file);
}, function(err) {
console.warn(err);
});
}
else if (entry.isDirectory) {
reader = entry.createReader();
reader.readEntries(function(entries) {
loadFiles(entries);
updateQueueLength(-1);
}, function(err) {
console.warn(err);
});
}
}
}
The code is getting long, but we’re almost done. Let’s unpack this.
The first branch of our new Entry logic ensures that what was returned by webkitGetAsEntry()/getAsEntry() is something useful. When they error they return null and this will happen if an application provides data in the drop event that isn’t a file. To see this in action try dragging a few files in from Preview in Mac OS X – it’s odd behavior, but this adequately cleans it up.
Next we handle files. The Entry spec provides the brilliantly simple isFile and isDirectory attributes. These guarantee whether you have a FileEntry or a DirectoryEntry on your hands. These classes have useful – though as promised, asynchronous – methods and here we use FileEntry’s file() method and enqueue its returned file.
Finally, the unicorn we’re chasing – handling directories. This is a tad more complicated, but the idea is straightforward. We create a DirectoryReader which lets us read its contents through its readEntries() method which provides an array of Entries. And what do we do with these Entries? We recursively call our loadFiles() function with them! In this step we achieve recursively walking a branch of the file system and rooting out every available image. Finally, we decrement the count of expected files by 1 to indicate that this was a directory and it has now been suitably handled.
But there is one more thing.
In that final directory reading step we recursively called loadFiles() with an array of Entries. As of right now, this function only expects to handle Files and Items. Let’s patch up this oversight, add a final bit of error handling, and call it a day.
function loadFiles(files) {
updateQueueLength(count);
for (var i = 0; i < files.length; i++) {
var file = files[i];
var entry, reader;
if (file.isFile || file.isDirectory) {
entry = file;
}
else if (file.getAsEntry) {
entry = file.getAsEntry();
}
else if (file.webkitGetAsEntry) {
entry = file.webkitGetAsEntry();
}
else if (typeof file.getAsFile === 'function') {
enqueueFileAddition(file.getAsFile());
continue;
}
else if (File && file instanceof File) {
enqueueFileAddition(file);
continue;
}
else {
updateQueueLength(-1);
continue;
}
if (!entry) {
updateQueueLength(-1);
}
else if (entry.isFile) {
entry.file(function(file) {
enqueueFileAddition(file);
}, function(err) {
console.warn(err);
});
}
else if (entry.isDirectory) {
reader = entry.createReader();
reader.readEntries(function(entries) {
loadFiles(entries);
updateQueueLength(-1);
}, function(err) {
console.warn(err);
});
}
}
}
All we need to do to handle an Entry is to rely on the fact that Entries have those oh-so-helpful isFile and isDirectory attributes. If we see those we know we have an Entry of one type or another and we know how to work with them, so just skip on down to the FileEntry and DirectoryEntry handling code.
And that, finally, is it. There are many specs with very new data types at play here, but through this turmoil we can achieve some very nice results never before possible in browsers.
Further reading
- Exploring the Filesystem APIs, by Eric Bidelman, Google
- Drag and Drop a Folder onto Chrome Now Available, by Eiji Kitamura, Google
- WHATWG’s HTML Drag and Drop spec
- W3C’s File API spec
- W3C’s File API: Directories and System spec
Like this post? Have a love of online photography? Want to work with us? Flickr is hiring engineers, designers and product managers in our San Francisco office. Find out more at flickr.com/jobs.