Web Storage APIs

FileSystem Access API

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web Storage APIs

Check out a free preview of the full Web Storage APIs course

The "FileSystem Access API" Lesson is part of the full, Web Storage APIs course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses properties of the FileSystem Access API, including reading and writing files in the filesystem of the user's device, requiring user's permission, Chromium and desktop only, asynchronous API, and doesn't count towards the quota. Opening a file and writing to an opened file are also covered in this segment.


Transcript from the "FileSystem Access API" Lesson

>> So, far we've been seeing the basics of web storage, Index TV, and data storage. But we mentioned four APIs that today are available for us. So the last one is the file system API that technically is known as file System access API, okay? So with file system access API, we can read and write files in the real file system in user's device.

There are some limitations for example you won't be able to read the private user folder, okay, in Unix based systems or Windows. So to avoid problems, security issues, it's limited in that sort of weird secure situations, but despite that, the user can open a folder, the user can open a file.

It requires user's permission, okay? In fact, it first required the user to pick a folder or a file from a dialog, okay? And after the user has picked that file or folder from a dialog, you can request more permissions and that will be like a normal permission like, hey, you already granted permission to read that folder, now do you wanna give written permission so the user can write?

It's chromium-only right now with the only exception of Safari supporting this, but for a private origin system. Remember the Photoshop example I gave you before? So Photoshop needs a temporary storage with files that is out of the RAM. So far implement this API, but not with a real file system.

So it's not implementing the file picker. So you can request access to a private or machine file system, and then you can write files, you can read files but the user will never see the files in the hard drive, okay? It's like an isolated private storage that only origin can see.

It's an asynchronous API as any modern API we don't need to prop it, okay? It's ready to use. It doesn't count for the quota, with the exception of Safari, okay? Because with the origin private file system, it's like an index.db at the end, okay? But I'm talking about the file system access API, the standard one, the normal one, the one that we have in Chromium doesn't count for the quarter because the user will save the file, okay, in the file system.

And by the way, this API today is chromium only, and desktop only. Not just chromium only. So it's not working on Android, yet, okay? So why this API up here? Let's see, one of the main use cases for this is our friend VS code. Do you know that VS code is a web app?

But it's using electron or so it's actually wrapped in a native app. Well, but then be as co creative in a web version. Not sure if we have seen that one. It's VS code or Dev, okay? VS code or Dev is VS code running in your browser, okay?

But, yeah, if it's running your browser It needs to open a folder and the folder will be not in the cloud but in your computer. So how can you use your IDE directly from the browser? Well when you open a folder this is the dialog you see, okay, for example I can go and open from data storage coffee masters, okay, and this is what you're going to see.

I say, use hey, do you wanna let this decide to view the files in that folder until you close all tabs for this site? And if I say yes, okay, now I can work directly in the browser with VS code, that was one of the main use cases, initial use cases for this API.

It's like, hey, why do we need to wrap VS code in a native container? Can we just run it in the browser? Well, the problem was we didn't have a way to do this, the file system, okay? So that was this in action. On Android, it's still also not like a use case.

So it seems like it's low priority because it didn't find like a real use case where this makes sense on mobile. So now, VS code can actually be a PWA. In fact it is. I can install VS code in my Mac as a PWA, and now I have two VS Codes, I can bring both to the same group here in my Mac and which one is the original one?

And which one is a PWA? Well, I should use the same font size on both. You don't know. Well, maybe you can realize, because this one has this, the menu, it's here and not at the top, because there is no API to actually yet to actually define the native OS menu, okay?

But then it's the same, and actually it's the same code base. So maybe you're thinking, but the 81 is faster. Nope, it is the same code base, okay? So now I actually have two Visual Studio Codes. They have different icons. [LAUGH] But one is the native, in quotes version and the other one is the PWA, and look at this I didn't grant the permission to the PWA to this folder, why?

Because it's a shared storage and permissions are also shared so a browser tab Where PWA has the same web client. Remember this morning we were talking about when do you share storage when this is a case where the share is a storage, okay? And it was at this point.

Mind blowing, right? So now I need to probably uninstall this one because every time I will get confused on which one am I using right but yeah, how do you how do you tell this is a PWA because you will see a different menu here, okay? So from here you can see that it's a URL and I can open this in Chrome.

We can open this back in Chrome. And what you won't see is like more integration with us but in this case there are no such integration but now on PWA there is a new API is called Custom overlays controls that will let the PWA render content directly in the title bar.

So now it can put the menu instead of here, if VS Code wants, it can put the menu directly at the top. Okay, make sense? So this is a quick use case to understand the file system API really, really quickly. So we mentioned it doesn't count for the quota because it's using your real file system and as I mentioned before, there is an extension to the API known as Origin Private File System that is currently only implemented in Safari.

And chrome is experimenting with it on the fly, but it's like it's not there yet. Okay, so Safari has the API, but only for these private file system. Okay, make sense? To be honest, the API is actually pretty straightforward. It's not really a big deal. So, the first step is to have the user select a file okay and you have the Show Open File Picker and there is an open folder picker as well that's the one that VS Code was using or for example to make an app that makes content offline.

I don't know, you want to make an e-book reader or something like that, well you can let the user pick a folder, okay, it will be your folder but remember that folder is public in the file system. So if you go to the Finder or the Windows Explorer the folder will be there okay, with all the files, the user can put files remove files from outside Europe how in mind that right so far is the only exception to that.

Then when you have that handle, you can get the file object or if it's a directory, a folder, you will get another kind of handler. It's a directory handler and then you can loop through all the files, you can create files. And to read the files, it's pretty simple.

You take that object and you call one of the processors available. So we have a slice so you can actually, instead of getting all the final ones, you can catch up on a slice of it, and then continue reading it and stream an array buffer so that's to read the binary file or text.

There is no JSON. Most people expect JSON to be there as with responses, but he's not there so you just need to take the text and then parse it. Okay that's how to open a file. How to write to an open file so if you already open the file then you can request written permission and over that handle over this one without handle, you create the writable and then you write the contents of the file to the stream, and you close the file.

So not a big deal. We are going to test this with our project in a second. And also you can directly write to a new file, in this case you don't use the handle of an open file, you use another file picker that is called, Show/Save File Picker, and then the user can pick one file to overwrite, or the user can type in the name of a new file.

And you can provide some metadata, for example, the type of file and description. You can provide a file name, such as the file name, but the user is in charge of the end. The only way that you have to have full control of a folder and write your own files with your own names is when the user granted you permission for the whole folder.

For VS Code for example. Which one is the native one? [LAUGH] I think the native one is this one because of the icon. So here I can create a new file, okay, and you can see hey because this is the first time that I'm trying to change the file hey do you wanna give this file permission for editing files.

Okay yeah, but if you if you saw here, Chrome didn't actually show me a picker for the file name. It was the JavaScript code that saved that file after I've got permission to save files, okay? So if I want to save another one, Now it's saving. Okay, make sense?

And now I don't need to give permission twice, it's the same. If I have permission to write, okay, you have permission to write the folder, do whatever you want. You can delete files with JavaScript, etc.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now