Electron, v3

Open in File System & Default Applications

Steve Kinney

Steve Kinney

Electron, v3

Check out a free preview of the full Electron, v3 course

The "Open in File System & Default Applications" Lesson is part of the full, Electron, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Steve demonstrates utilizing Electron's shell library to open a file in its default application and show the file in the operating system's file manager.


Transcript from the "Open in File System & Default Applications" Lesson

>> I'm trying to think if there's any major things that we need to do here. Or I think the last two things for the OS integration piece of this would be to get these two buttons working. Like I've said, reverting would just be asking for the last saved content and changing the DOM back.

So I'll kinda leave that for you all as well. But I think getting these two kinda show two more I think important pieces that you might use in your application rather than just more of the same. So why don't I do one of these, and then I'm gonna have you all do the other one, right?

And so there's this library, which we can argue and Electron maybe doesn't have the best name in the world, Called shell, right, cuz I guess, whatever. If we go look at the shell library, there's not a lot in here, but there's showItemInFolder, openPath, openExternal. You can actually legit trash an item in the file system, right?

So if I wanted to hit a Delete button, we could literally. And it will handle all the parts of moving it into the trash, operating system agnostic, right? So yes, you do need to think about the UX of the peculiarities of your OS. But in terms of the specifics of Linux versus Windows versus Mac OS, you don't have to think about any of that.

You just call it based on that kinda given behavior. So the ones that we care a lot about are openPath, which we'll go ahead and seek to open it in the desktop operating system's default manner. So for a markdown file, that is gonna be whatever you normally open markdown files in.

The other one that is super useful is showItemInFolder. If we go into VS Code, for instance, I right-click this, you'll see Reveal in Finder. Guess what method that's using. It's using the one that we have seen previously. So I'll do Reveal in Finder and you get to do open in default application, cool.

So I will say ipc, icp is something very different. We'll say show in file system, show-in-folder, I like it. And honestly, I know the current file. I don't really need anything else from that event to be clear. I can say if, I don't wanna do the get currentFile cuz that's going to ask me for the shows dialog if it's not there.

So we'll just say, if currentFile.filePath. And then we gotta pull in the shell module from Electron. Beyond that, we're just gonna say open the current file. I don't know what happens if you give it an empty string. We can find that out together in a little bit. But yeah, it will basically go ahead and proceed to show you where that is in the file system.

So all we need to do at this point is then, again, do the dance of making it available, right? So we can do show, what did I call it in my main process? I called it show-in-folder? All right, let's call that here as well. ShowInFolder, and that really doesn't need anything other than to do ipcRenderer.send show-in-folder, right?

And like I said, if you get tired of this, there are some ways to optimize this. You could, for instance, keep an array of the methods that you allow. And that way, you can only send stuff over those channels that will, again, allow lists and give you a certain amount of the security for a little bit more convenience.

The reason that I'm not choosing to do that is because I am using TypeScript. And I would like the type checking for the correct thing that each one, if it takes an HTML string, that's different than just having an allow list. I will show you a way to get around putting it in the type every time probably right after this cuz I'm getting really tired of doing this.

But to kind of just make the point real quick, we'll just showInFolder, and that doesn't really take anything, so it's pretty easy to add. There's an argument about why you would also choose to do this manually, which is there's something about your own sanity. It's tedious, but then you have to manually do it, right?

But I'll show you how to get around it if you wanna get around it as well, awesome. And like we said before, that one's exposed there. So we can actually now just go back into our renderer process and do Elements.ShowFileButton. And we'll just call it window.api.showInFolder, and I do need to restart the process.

I'm yelled at for something, but it looks like I fixed that since then. Cool, and so now, I probably need to enable that button. We'll do it in the DOM for a second. So go ahead and I think when I open a file, I probably need to also then choose to on the file opened.

But for the meantime, we'll cheat for a second. And go ahead and I should be able to click that. I opened that one in the default editor, so I did the opposite one. Let's see, I did openPath. I meant to do showItemInFolder, but I gave you the answer for the exercise.

So showItemInFolder versus openPath, we'll open it in the default one. It's what happens when you're talking and typing simultaneously, so showInFolder, at least get the right, Have a little bit of self respect, you know what I mean? And then let's actually go ahead and say while we're at it in the preload script.

Cuz now we have that onFileOpen, so we'll actually do this now in the renderer. So onFileOpen, we should be able to say Elements.ShowFileButton disabled is now false cuz we've opened one. And so now, it should be able to see that we can, Upon opening it, it's now enabled and then we see it in the file system.

So we get that OS integration there as well. So kinda gave you the answer, but just for practice for a second, why don't you spend three minutes just getting now the opposite one in place? The open in default application, which is openPath, and we'll kinda just do it together real quick.

And then, well, I think for the most part, wrap up this little application for a little bit. All right, [COUGH] so now we've got one of the buttons working. We're just trying to get the other one working. Luckily, it is a very similar pattern in both cases. So we'll start with over in here, we'll just say, ipcMain, and then we're gonna do open-in-default, default-application.

And that is again one little guard clause, not entirely sure what happens if you pass it an empty string. But we've got it in place, so we'll do the openPath, and that should get us most of the way there. ShowInDefaultApplication, and that doesn't really involve anything. And now we should be able to say, We'll open in the default, OpenInDefaultApplication, we'll listen for that, and we'll also send that same message, right?

And then the main process gets it. Everything works out great. We'll do the same. I might do at some point, probably not right now, is cuz when we save a file, there's also the fact that we now have a file. So I might just send a message being, hey, we currently have a file now, right, which will then activate all of these buttons.

But for now, we'll just do it here cuz I think it gets the point across as we go through. And real quickly, all we should need to do at that point was kinda get into the flow of it. That one, so we should ope a file. Now I can open that up, showInDefaultApplication is not a function.

Did I not put it on there or did I misspell it? I just added the type, I didn't actually, the error message is legit. Cool. All right, now open a file. Almost, let's see, we've got showInDefaultApplication, it says show-in-default-application. Did I open-in-default-application? One of these things is not like the other.

I think open-in-default-application is the better one, so I'm gonna go with that. We'll keep that the same, though. Actually, I'll make it consistent, we're worth it. The glory of TypeScript helping me. As long as I get the red squiggly lines to vanish, we should be good. All right, openInDefaultApplication then calls that openInDefaultApplication, openInDefaultApplication, open-in-default-application.

The security dance is fun, but arguably, the downside of losing the security dance, also fun. Open file. And now we can open in the default application. And again, we're kind of becoming a nice player. I would argue I was about to make the joke. Look, we're playing nice with all the other native applications as I in one Electron app hit openInDefaultApplication, which caused it to open up in another Electron app on my computer.

But I guess that's the value of the course, right?

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