Open cinqmilleans opened 2 years ago
Could you point me a couple of examples where ViewModel and App are referenced in Storage?
FilesystemOperations depends on IShellPage to access the ItemViewModel, for example here:
FilesystemResult<BaseStorageFolder> destinationResult = await associatedInstance.FilesystemViewModel.GetFolderFromPathAsync(PathNormalization.GetParentDir(destination));
GetFolderFromPathAsync depends on the current page. This dependency must therefore be circumvented.
In FilesystemHelpers, we find for example:
App.JumpList.RemoveFolder(source.Path); // Remove items from jump list
Ah ok, I assumed this was just about the StorageFile/Folder implementations 👍
Edited to include my ideas for #8405 which was somewhat informed by @d2dyno1's code review suggestions a couple months ago.
Posting new operation status should be taken place in each rich command that executes operation. Below denotes how and what layers we should implement without detailed information such as method arguments and long comments.
Copies to clipboard with Copy type.
graph TD;
CommandManager.CopyItem;
Copies to clipboard with Move type.
graph TD;
CommandManager.CutItem;
Pastes to the current folder in Copy mode.
graph TD;
CommandManager.PasteItem-->IStorageOperationService.CopyAsync-->IModifiableStorable.CopyAsync
Pastes to the current folder in Cut mode.
graph TD;
CommandManager.PasteItem-->IStorageOperationService.MoveAsync-->IModifiableStorable.MoveAsync
Deletes permanently.
graph TD;
CommandManager.DeleteItem;
CommandManager.DeleteItem-->IStorageOperationService.DeleteAsync;
IStorageOperationService.DeleteAsync-->IModifiableStorable.DeleteAsync
Moves to Trash (Recycle Bin on Windows). Redirects to permanent deletion in some file systems that don’t support recycling.
graph TD;
CommandManager.RemoveItem-->IStorageOperationService.RemoveAsync-->IRemovableStorable.RemoveAsync
Performs Rapid Load - load of file names only to show on the UI rapidly.
graph TD;
ShellViewModel.QueryAllAsync-->IStorageQueryService.GetAllAsync-->IFolder.GetChildrenAsync
Performs Lazy Load - delayed load of basic properties to show file names rapidly.
graph TD;
ShellViewModel.EnumerateAllAsync-->IStorageEnumerationService.GetAllAsync;
Queries with queryable syntax, such as RegEx, AQS and SQL, either in deep(recursively) and in shallow.
graph TD;
AddressToolbarViewModel.SearchAsync-->IStorageQueryService.GetAllAsync-->IFolder.GetChildrenAsync
Queries properties of a storable . Since there're too many properties to retrieve on-loaded, this layer should be accessed on-demand, such as in Details Pane and in Properties window.
graph TD;
IStorageEnumerationService.GetAllAsync-->StandardStorageItem.GetProperties
graph TD;
DetailsPaneViewModel.LoadAsync-->StandardStorageItem.GetProperties
graph TD;
BasePropertiesViewModel.LoadAsync-->StandardStorageItem.GetProperties
Provides services for enumerations, searching and operations. Those services are intended to use without regarding file system capabilities.
Here’s abstracted services:
The app needs watchers to keep eye on file modifications from outside of the application.
Those properties are intended to use in Details pane and Properties window. Because they are very detailed, places where to be used is very limited but still necessary to keep better experience on Windows
IStorageQueryService
feels like an anti-pattern, and it's one I've been actively avoiding in my own apps for some time. Best to start with some given root folder.
~~Even it’s to support some type of query languages that are supported only on Windows such as AQS and Windows Search SQL via Win32API - Windows Search API v3? If we use extension methods the app has to cast to NativeStorageFolder in search control view model. I think wrapping with interface protects codebase from being modified unintentionally and I want to avoid view models think about platform capability and try to use abstracted interfaces for it.~~
You're totally true. When it comes to Storage Search, we might as well create an extension SearchAsync as IStorageQueryService.
Decoupling Items in the Filesystem Folder
This issue discusses the migration from Storage to the backend. This step is preliminary to the ListedItem refactor. With this discussion, we can parallelize the changes to save time. @lukeblevins @d2dyno1 @gave92
Objectives
Items in the Filesystem folder should be removed from unwanted dependencies.
We take the opportunity to rework the style to clarify the files. The order of the elements is completely random. PRs are already pending. We can also check what is should be public or not. It will also be necessary to manage nullables because the backend manages them differently.
Potential work item ideas
BaseStorageFolder|File
in the docsIStorageQueryService
with the member:bool IsAvailable(string directoryPath)
to easily verify support for the implementation's filesystem API on a provided location (this would be done before performing the query)IStorageEnumeratorService
which only handles instantiation of backend file or folder items from already retrieved paths or native filesystem API constructs (IStorageQueryService
will returnIList<string>
)IStorageEnumeratorService
. I like the concept choosing whether the items should have partial, full, or extended properties populated upon creation, but we could optionally go further and support a set of specific, core property system strings here.------ And even more coming soon ------