v3 and subsequent releases

[n1crack]

Let's talk about what we're thinking about for v3.0 and subsequent releases. We'd like to thank @abichinger for most of the features below.

And thank you all for your support ❤️ .

v3.0

• TypeScript support - @abichinger
• Cut/Copy/Paste support - @abichinger
• Custom Icons -@abichinger
• Add more drop zones: pinned folders and tree view - @abichinger
• virtual columns - performance improvement for file display
• double-click customization

v3.1

• direct AWS S3 upload [needs backend support] - Refactor Upload Code
• signed URL support for file display [needs backend support]
• custom theme palettes

v3.2

• Make target folder input as editable in move modal
• Add Move option in the context menu so items can be move/copy with a mobile phone
• Add an option(checkbox) in the modal to create a copy in the target directory instead moving.
• transfer items between filesystem adapters

v3.3

• improve selection filter - only directories/files
• improve selection filter by mime type
• search settings - limit on search results / deep search option

v4.0

• OpenAPI compatibility.

[n1crack]

I’ve also been thinking about an offline view mode, and the possibility of passing the entire folder structure as a prop — that could really help reduce the number of server calls.

Using something like TanStack Query could be a great fit for handling these scenarios (caching, syncing, background updates, etc.).

And maybe even a plugin system could open the door for more flexible extensions and community-driven features. 🚀

[abichinger]

Nice roadmap! (Shouldn't it be v3?)

Here are two breaking changes I would like to add:

1. move/copy API: Rename the parameter item to target
   https://github.com/abichinger/vuefinder/blob/24c813f0ab8314f783dffa3cbce31c0b49920ccb/src/components/modals/ModalTransfer.vue#L87
2. index API: Return a list of storage objects (name, type, size, free, used, ...)

--- a/src/composables/useData.js
+++ b/src/composables/useData.js
@@ -21,10 +21,8 @@ export default function (initialAdapter, initialPath) {
     // fetched items
     const data = reactive({
         adapter: adapter,
-        /** @type {string[]} */
+        /** @type {import("../types.ts").StorageInfo[]} */
         storages: [],
-        /** @type {Record<string, import('../types.ts').StorageInfo>} */
-        storage_info: {},
         dirname: path,
         /** @type {import('../types.ts').DirEntry[]} */
         files: []

I’ve been thinking again about the breaking changes. Strictly speaking, they only affect the backend (the API of the Vuefinder component has not changed). That means if you apply SemVer, you wouldn’t actually need to make a major version bump for the frontend. On the other hand, it’s probably not a good idea if someone updates the frontend and suddenly it doesn’t work anymore because their backend is outdated. I’m wondering what’s the best way to handle this?

If you want, I can take care of adding Copy/Cut/Paste to the context menu.

[n1crack]

Yea :) a little confused. Fixed the number.

I think we should match the versions with backend. And check it if it is supported. (For example if we are using 4.x then backend version should also be 4.x)

I'm happy with the current api and not a fan to change it frequently. But we need a solid api design. And the api should have versions. v1- v2 etc. you are right, frontend changes shouldn't affect the current environment.

Maybe we provide features by versions, and disable if it is not available? We support both v1 and v2 for example. v2 has copy paste endpoints. If the user has v1 endpoint, then the user can't see the copy/paste at all.

[n1crack]

I know there are a lot of maybes. But in the end, It will be awesome :)

I am using react these days, and have an idea of making this package framework agnostic. I know it will be a lot of work but not impossible.

[n1crack]

#106