Show Contents of Directory in DirListing widget


I am building an extension which should display the content of some directory (like FileBrowser) and I wanted to reuse the DirListing widget since this is exactly what I want. However, I cannot figure out how/where I can specify which directory should be displayed.

I am using a ReactWidget which renders some react component and in that component I want to display the DirListing widget. I can get it to render using a custom Renderer class but it does not show any files/directories only the header.

For example I have this React component:

export class ReactComponent extends React.Component<ComponentProps> {
    // initialization

    public componentDidMount() {
        let renderer = new ExistingNodeRenderer(this.dirListingNode);
        let model = new FilterFileBrowserModel({manager: this.docManager})
        this.dirListing = new DirListing({model, renderer})

    public render() {
        return <div ref={_element => this.dirListingNode = _element}></div>

How can I specify which directory should be displayed?
Or to rephrase: I have a path as a string (e.g. '~/test') and I want to display the content (files or subdirectories) of that path in the DirListing widget. How do I do that?


1 Like

FileBrowserModel has cd(newValue: string) method that could be useful. FilterFileBrowserModel is just a subclass of FileBrowserModel so it should work flawlessly. I think that you could do something like:'test')

However, I am not sure if absolute paths are supported (my hunch is that they are not).

Thanks that worked! I always tried to use paths or relative paths…

Do you know what I have to add to open the files displayed in the DirListing? When I try to open a txt file nothing happens.

1 Like

I don’t think there is an API exposed for opening files from DirListing, but there are two options I can easily think of:

  1. simulate a click on the rendered DOM node (which will either change the directory, or open the file) by internally calling handleOpen method (it is protected so cannot be used from the outside)
  2. directly call openOrReveal(path) of DocumentManager (I see that you already have this.docManager so that should be easy)

It is difficult to guess what might be not working in your implementation without seeing the code.

I was just wondering about this last night. In a number of cases, it would be very useful to have a Contents-over-comms, and indeed widgets might be the simplest place to land it.

On the kernel side, it’s possible that an AsyncLargeFileContentsManager would just work.

On the client side, such a widget could implement the IDrive which might just create an interface like:

This would get interesting in the context of jupyterlite, where we have some challenges spanning the filesystems of the static HTTP host, the in-browser contents, and the in-worker kernel… such a widget could “automagically” sync. And indeed, yjs-over-comm might provide similar advantages to getting things into the interactive computing scope of the kernel.