4 ms·

No, you can't. You can open local files but not save them to desired locations, only download them as usual browser files. There are polyfills that mostly don't

by bitL 7y ago

No, you can't. You can open local files but not save them to desired locations, only download them as usual browser files. There are polyfills that mostly don't work; each browser has a different broken API for local file access and methods are often deprecated/removed.

shawnz 7y ago
Your browser provides its own UI for choosing the location to save downloaded files. This might not be ideal if you want to build your own file manager view into your app, but I don't think it's fair to say that your app is less capable just because it doesn't have that.
- bitL 7y ago
  An example - you are using some web IDE (imagine a self-hosted version of VSCode). You have a few local files open in your browser, editing the code. Now you want to save them - you'd have to "redownload" them to save them. That's a highly suboptimal UX.
  - shawnz 7y ago
    If you are actively working on the files, then you could just save them to the app's local storage. There is not necessarily a need to save them back to the same place you imported them from. When you are ready to export the project then you could have the app generate a zip file, or just push it directly to git or another app and skip the filesystem altogether. Obviously this is not a great workflow for certain things like system administration tools that are specifically designed to work with the local machine's filesystem, but that's not really a good use case for PWAs in the first place.
    - bitL 7y ago
      Local storage is obviously not an option - imagine your project has a few gigabytes. Coding example was just to illustrate the problem quickly for everybody to understand what the issue is. Forcing user to generate/download ZIP at some well-defined points in time is a horrible UX idea; in addition it leads to desynced content of files and local storage. Browser's local storage can also disappear if SQLite gets corrupted, making it a nice SPOF for all PWAs that are installed. Imagine not losing data just for one app, but for all of them.

by bitL 7y ago

shawnz 7y ago

Your browser provides its own UI for choosing the location to save downloaded files. This might not be ideal if you want to build your own file manager view into your app, but I don't think it's fair to say that your app is less capable just because it doesn't have that.

bitL 7y ago
An example - you are using some web IDE (imagine a self-hosted version of VSCode). You have a few local files open in your browser, editing the code. Now you want to save them - you'd have to "redownload" them to save them. That's a highly suboptimal UX.
- shawnz 7y ago
  If you are actively working on the files, then you could just save them to the app's local storage. There is not necessarily a need to save them back to the same place you imported them from. When you are ready to export the project then you could have the app generate a zip file, or just push it directly to git or another app and skip the filesystem altogether. Obviously this is not a great workflow for certain things like system administration tools that are specifically designed to work with the local machine's filesystem, but that's not really a good use case for PWAs in the first place.
  - bitL 7y ago
    Local storage is obviously not an option - imagine your project has a few gigabytes. Coding example was just to illustrate the problem quickly for everybody to understand what the issue is. Forcing user to generate/download ZIP at some well-defined points in time is a horrible UX idea; in addition it leads to desynced content of files and local storage. Browser's local storage can also disappear if SQLite gets corrupted, making it a nice SPOF for all PWAs that are installed. Imagine not losing data just for one app, but for all of them.