-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix unused options in readdir system VFS adapter #164
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please amend the commit message so that it says:
Fix unused options in readdir system VFS adapter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just about to merge all your changes, and then it suddenly dawned on me:
The internal client options are now sent over to the server... which I feel like should be filtered.
A good example of a scenario like this is the following:
Lines 70 to 75 in 385b38f
const handleDirectoryList = (path, options) => result => | |
Promise.resolve(result.map(stat => createFileIter(stat))) | |
.then(result => transformReaddir(pathToObject(path), result, { | |
showHiddenFiles: options.showHiddenFiles !== false, | |
filter: options.filter | |
})); |
So before we can finally publish all the changes this needs to be addressed 🤓
Actually, this brings up another interesting point! Should the client or the server be responsible for handling these options when you're using a "pagination" system like this. Because the client sorting algorithm works like this:
Which would mean that in some cases you might see this: 👎 Hm... with client sorting and paging, this looks strange
👌 This is it usually looks when you only get "one page" with client sorting
👍 No sorting on the client side
The original design of readdir was to get "everything" at once, so we need to settle on something that does not "look wrong". I feel like the option to disable client sorting is a good choice, especially since most filesystems will sort alphabetically no mater the type (dir / file), which is a lot more "natural". As far as I see it, the best way to solve this is to add a new method to the adapter that can tell the client what it's supposed to do 🤔. const adapter = (core) => {
return {
capabilities: async (file /*optional*/) => ({ // As async and with file as arument to future-proof implementation
sort: true // Sorting is done on the adater side (aka "server")
}),
readdir: async ({path}, options) => {}
};
}; I hope that makes sense... it's very late for me here, and I've been busy with other projects all day 😅 Also, I had to edit this like a million times, so what you see in the email is not what I originally had in mind.... Maybe we can just merge everything as-is then tackle this afterwards? |
I see. As an another example, by opening a Open Dialog , since its options.filter has function typeof (which is not considered), it is sent to the server as So do you believe that filtering should be done in |
So as I understand, you mean since most filesystems retuen the whole list in an alphabetic order, we can also make sure that every single page is already sorted (even beside other pages as a whole) if BTW, I did not understand what and why is the |
In my case, the list returned by my storage API is ordered alphabetically, but files with uppercase letters precede the ones with lowercase letters.
|
This fits under the scenario I described. This will create a client-side option.
Probably in the vfs abstraction per-function:
Because I wanted to make sure that this function can return capabilities based on files, not just global settings. Think for example if in the future there needs to be a new check for readfile.
This is what I suspected. This is what most filesystems do, which is fine. |
I commited some changes, |
So to start working on this point, I think we should have some agreement:
capabilities: async (file /*optional*/) => ({ // As async and with file as arument to future-proof implementation
sort: true, // Sorting is done on the adater side (aka "server")
pagination: true // pagination is supported by this adapter
}),
I also think it's better to merge all these changes (after completing option filtering), and then work on this new point in two new PR (server and client) |
I think we'll take this in these steps:
Does this sound good ? I know it's been a long process so far, but I really wanna make sure we do this right 😊 Note to self: Since this is a semi-breaking change (both client and server** needs update together) I have to write some notices about this in the migration article in the online manual. Edit: I just realized that you did 2) here 🤦♂️ I'll review that. |
You are completely right, and I do wanna the same 👍
Sorry, since you said it is needed to be addressed before publishing, I did it here. So as you said after finishing these PR, maybe we can do sorting stuff in new one. |
Hi. |
Hm. I don't think there's anything to do in this branch. This branch actually contains more changes than I really feel comfortable with, hehe. I need to set off a day where I look over all this work again and then finally do a merge. Thankfully you don't need me to do that in order for you to continue the work on the pagination in the file manager :D |
You probably already know this -- and might even be using this right now: you can just use your forks with your changes in your installation: https://manual.os-js.org/guide/modules/ |
Yes, but as I need to make pagination changes in the same fork package (osjs-client), I think it causes problem. |
Just a small reminder. I would appreciate if you'd have another look at this when #182 is merged :) |
This change sends options correctly in readdir request.
Relevant: