it is no longer feasible to build the blueprintjs css ourselves, so we
just use all of the default variable values and override things using
selectors instead.
This replaces the delete notification with a new alert dialog. This
makes for better keyboard interaction and forces the user to make a
decision before doing anything else.
Also fixes closing the editor before deleting the file.
This refactors the new file wizard to be more independent. Most of the
control is now done through the saga instead of splitting it between
react and the sagas.
Also fix a few issues while we are touching this:
- pressing enter now accepts the dialog
- newly created file is now activated in the editor
This separates the explorer files state from the fileStorage FileMetadata.
The latter contains extra info that the explorer doesn't need. This
will prevent rerendering each time the file contents change.
This splits the fileStorage archive into two sagas to separate concerns.
fileStorage now just gives a dump of the database and explorer deals
with the user interaction and zipping.
clearAllMocks() does not remove mock implementations, so we need to be
using restoreAllMocks() instead. Also ensure that it is called first
in case the other cleanup code needs to call a mocked function.
This breaks down reading and writing into low-level and high level sagas.
Opening now takes a lock on the file so that it can only have one writer
or have multiple readers. The low-level read and write sagas use the
file descriptor to determine if the file is still open before actually
performing the action.
Since we are using the web locks api, these locks should work across
browser tabs/windows.
The high-level read/write sagas perform the low-level open, read/write,
close operations in a single call.
The high-level delete and rename sagas are also updated to take locks
on the files while performing the respective operations and will fail
if the file is already being used somewhere else.
This changes how files work. There is now an open function that
translates a path to a file handle (id). Then this handle is used
to perform other actions on the file. The file contents are moved
to a separate table so that the actual file storage is independent
of the database (e.g. in the future, we may use File Access API).
We store a hash of the file contents in the metadata file so we can
detect file changes without having to compare file contents.
We also separate the change and add actions.
David Lechner