(dev feature req) something like `api.file_list`, but simply easier, in plugin `api` about hfs HOT 10 CLOSED

I think it's safe for the moment to api.require file_list, but later we may discuss a different approach after I study a bit in details how you are doing it.

It should be possible to write like this

for await (const chunk of readable)
    console.log(chunk);

Anyway, I noticed the wrapping is not useful anymore, as the calling function (apiMiddleware) is already(again) able to receive the generator, so I'll let it do it and remove it from file_list.

from hfs.

i think the for await will work for both the Readable and the AsyncGenerator, so your code should be unaffected by the next change

from hfs.

what is your approach, are you building the dom inside the browser or are you sending the html like hfs2 ?

from hfs.

since you are going to use file_list, know that I'm considering renaming "entry" key to "add", to mimic/comply the "list" protocol I defined for other parts.
We can do it with next release, so you can then forget about it.

from hfs.

Well, this is my dirty piece of present code:

    async *nextEntry(ctx: KoaContext) {
        let generator: FileListEntryGeneratorReadable | null = await HFS.file_list({
            path: ctx.path,
            omit: 'c',
            sse: true
        }, ctx).catch(() => null);
        if (generator === null) return null;
        let end = new Promise(resolve =>
            generator?.once?.('end', () => resolve(false))
        );
        let entry: FileListEntry | null;
        while (
            await Promise.race([
                new Promise(resolve =>
                    generator?.once?.('readable', () => resolve(true))
                ),
                end,
            ])
        ) {
            while ((entry = generator?.read()?.entry)) yield entry;
        }
        return null;
    }
    async handle(ctx: KoaContext) {
        if (!this.template) return;
        let body = ctx.body = new PassThrough();
        ctx.status = 200;
        ctx.type = 'text/plain; charset=utf-8';
        for await (let entry of this.nextEntry(ctx)) {
            entry && body.write([entry.n].join('\t') + '\n');
        }
        body.end();
        return true;
    }

Note: Type notations are my custom

At the moment I tried to iterate the returned Readable but failed.
TypeError: gen is not async iterable
gen is really the Readable returned by await HFS.file_list(...), similar as in above code.

For my plugin, the approach is to send generated HTML (or whatever), like HFS 2.
So it almost replaces default frontend, and may take control of many other things, too.

Anyway I'm looking forward to the changes. Thank you!

from hfs.

this job new Promise(resolve => generator?.once?.('readable', () => resolve(true))),
you can import { once } from 'events' and it does the same job, but like this once(generator, 'readable') (events is a standard module).
Nice, isn't it?

About the Readable and for-loop, i just made a test, and where it says

          if (res instanceof Readable) // Readable, we'll go SSE-mode
            return res.pipe(createSSE(ctx))

I tried for await (const x of res) console.log(x) and it worked, it printed {entry} objects. Maybe you did something wrong.

from hfs.

I checked and found that file_list being resolved to ApiError in one case, and it caused a failure.
So it actually worked, let me switch to it 😁

Whenever I try a Node stuff it always frustrates me. I try to use less of Node.
And now that this job is not needed anymore...

from hfs.

I checked ability of PassThrough and it can have memory leaks.
And as said by its api doc the best for me is still Readable. It's overall ok, after test.

That means I have to use it... 🙃

from hfs.

if i can help you with node's stuff i'll be glad to, but i'm no expert.
Do you think current situation is good enough then?

from hfs.

I think it's going well now... :)

btw thanks to frontend code I know there's Intl.Collator to do good sorting on file list, by either browser or server...

from hfs.