telamonian / tree-finder Goto Github PK

Versatile tree-viewer/filebrowser widget, built on top of regular-table

License: BSD 3-Clause "New" or "Revised" License

TypeScript 76.90% CSS 6.38% JavaScript 8.63% Less 8.08%

filesystem javascript typescript regular-table custom-elements filebrowser file-browser

tree-finder's Introduction

tree-finder

A Javascript library for the browser, tree-finder exports a custom element named <tree-finder>, which can be used to easily render filebrowers or other hierarchical trees. Only visible cells are rendered.

Features

Examples - try `<tree-finder>` out live


basic

Installation

Include via a CDN like JSDelivr:

  <script src="https://cdn.jsdelivr.net/npm/tree-finder/dist/tree-finder.js"></script>
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/tree-finder/dist/tree-finder.css">
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/tree-finder/dist/theme/material.css">

Or, add to your project via yarn:

yarn add tree-finder

... then import into your asset bundle.

import "tree-finder";
import "tree-finder/style/theme/material.css";

Development

First, ensure that you have nodejs >= 12.0.0 and yarn >= v1.2.0 installed
Clone this repo
Build and run the "simple" example
```
cd examples/simple
yarn
yarn start
```

yarn start will launch a dev server. Open the url it supplies in any browser in order to view the example. While the dev server is running, any changes you make to the source code (ie any .ts or .less files) will trigger a rebuild, and the example will automatically reload in your browser.

tree-finder's People

Contributors

Stargazers

Watchers

Forkers

jd41 reoono vidartf tree-finder

tree-finder's Issues

upgrade webpack 4.x -> 5.x

get all those good-good new webpack 5.x features. Hopefully 5.x is mature enough now that this won't be too painful

improve mockcontents

split mockcontents into a separate package in this "monorepo"
make mockcontents consistent as well as random

What I mean by random and consistent is that it should produce different values on each refresh (random), but now that re-opening dirs is a thing that can happen (thanks to the now functional breadcrumbs implementation), we'll also want the dirs to always contains the same values on reopen (consistent)

make filter widget optional

add an option to toggle the version of the filter widget that adds a <tree-finder-filters> elem independent of the <tree-finder-grid> elem
add an option to toggle the version of the filter widget that adds filter <input>s directly inline with the <tree-finder-grid>'s column headers

fixup inline filter input size/spacing on grow/shring

For the column-header inline filter inputs

their left side should be "anchored"
the gap in between the filters should be fixed and not change as the column/filter input widths grow/shrink

Currently neither of these things is true

add README

add breadcrumbs

Standardize the interface and behavior of command-related `Subject` instances

Currently, all of the commands (open, cut, paste, etc) are associated with an rxjs Subject instance. The exact implementation is (as of v0.0.12) a bit all over the place. Let's standardize the implementation. One possible plan:

All command-related Subjects live in ClipboardModel (might need a rename)
Both internal tree-finder code and 3rd party integration code should follow the same patterns for interacting with the commands
- To trigger the command, supply the value on which the command should act via next
  - eg fooSub.next(somerow)
- To participate in the implementation of the command, subscribe via a callback
  - eg fooSub.subscribe(row => {/*whatever*/})

Pros:

very flexible

Cons:

3rd party code that subscribes to a Subject will also be responsible for proper cleanup:

// subscribe
const mysubscription = fooSub.subscribe(somecallback);

// later, clean up
mysubscription.unsubscribe()

style column headers using css-grid layout

apparently I can fix a lot of the lingering issue with eg the sort header icons this way

move filter inputs to be inline with the grid's column headers

Right now, the <tree-finder-filters> element can provide one filter input per column, and is working well. However, it still has some issues around syncing the input box widths with the grid column widths. To solve these problems once and for all, it would be nice to instead move the actual <input> elems to be inline with the grid's column headers. This will also have the nice side effect of making the filter boxes smoothly animate growing larger/smaller when you click and drag on a column resizer.

add callbacks

callbacks for drag n drop, open, various other actions

add api to support external code acting on selections

Development workflow doesn't work for me

When I try to follow the development instructions in README.md and yarn start the simple example, I get the error

"Error: Can't resolve '~tree-finder/dist/tree-finder.css' in '/home/ubuntu/tree-finder/examples/simple/style' ".

upgrade regular-table dependency to v0.2.1

Add 3rd party hook for tree-finder open

Add a way for 3rd party apps to hook into the open action of tree-finder

Add 3rd party hook for delete action

Add a way for 3rd party apps to hook into the delete action

TypeError: this.table_model is undefined

The error message TypeError: this.table_model is undefined appears in the Console under some circumstances when using jupyter-fs.

A reproducible example can be found here: jpmorganchase/jupyter-fs#129

tree-finder/packages/tree-finder/src/element/grid.ts

Line 32 in 1a1d481

    
           const [thead, tbody] = [(this as any).table_model.header.table, (this as any).table_model.body.table] as HTMLTableSectionElement[];

Add 3rd party hook for rename action

Add third party hook into rename action that activates the renamer component on a given row/content

Add 3rd party hook for refresh action

Add third party hook into refresh action that either invalidates all cached contents or a specific list of Content dirs.

Finish setting up the webpack build of tree-finder's dist

Make the webpack build of tree-finder's dist bundle jump through all of the remaining nasty hoops, including

output each theme css file separately and into a separate dist/theme dir
minify all css when NODE_ENV is set to "production"
handle css modules
handle normal less and less modules

Add 3rd party hook for clipboard functions

Add a way for 3rd party apps to hook into the clipboard actions, including cut, copy, paste

add drag n drop

Add 3rd party hook for tree-finder drag-n-drop

Add a way for 3rd party apps to hook into the drag-n-drop actions

Fix breadcrumbs created when opening dir in expanded tree

Currently, exactly one new crumb will be created when a dir is opened, regardless of depth of dir in any expanded tree. Instead, the count of new crumbs should equal 1 plus the depth of the dir in the currently displayed tree

add filter

The first pass at this will consist of one big input box that sits between the breadcrumbs and the top of the grid, and which will serve to filter on the file paths

rename panel element <tree-finder> -> <tree-finder-panel>

I'm finding it somewhat confusing that the panel element is now called <tree-finder>. I'm going to rename it to <tree-finder-panel>

add row selection model

test integration with 3rd party app: jupyter-fs

The tree-finder UI is starting to mature and is now mostly feature complete.

The next thing to build in tree-finder will be support for commands (cut, copy, paste, open, etc). I think the easiest way to design these will be trial-by-fire: I'll take an app with an existing filebrowser UI, and existing backend implementations for commands, and try out the current tree-finder as a drop-in replacement.

The first target will be jupyter-fs

Add way to modify columns and retain filters

Currently if you want to modify the columns that are displayed, you need to update the colmnNames on the model, and then re-init the panel widget. This causes the filter inputs to be reset, and causes flicker when re-initing.

Ideally, we could change the columns, and retain the filters of any columns that remain visible (any filters on hidden columns will as a matter of necessity be cleared).

Add API support for file decorators, custom classes and extra columns

Following on the discussion on future adoption of tree-finder in JupyterLab, I wanted to bring up some use-cases that are not accommodated by the current file browser, but would be great to have in the bright future with tree-finder.

As discussed in jupyterlab/jupyterlab-git#124 (comment) jupyterlab-git would like to be able to add custom indicators for the files to highlight which files were modified, added, deleted or are ignored. The idea is to implement it as both:

an extra icon to the right or left of the filename (as in VSCode)
a text colour modification (as in PyCharm)

and let user choose which one to use. The text color modification would modify the filename display, so possibly could be implemented by allowing to update the classList of the file item. The extra icon could be implemented using a special column (it makes sense to sort by the git status).

An initial work using the current JupyterLab filebrowser was done on jupyterlab/jupyterlab-git#885:

but it was a bit hackish and would not work if multiple extensions wanted to modify the filebrowser items.

Another briefly explored idea was to add icon modifier:

This does not seem optimal for this use case, but might be handy for other uses.

It would be useful to make it available for both files and folder, and maybe even the breadcrumbs section, to accommodated designs by @weihwang such as jupyterlab/jupyterlab-git#124 (comment):

Finally, it was proposed that it might be handy for multiple extensions to add custom decorators for files, as in an example brought up by @fcollonval over at jupyterlab/jupyterlab-git#885 (comment):

This one comes from VSCode and shows both a number of diagnostic warnings (e.g. linter errors) and the git status. This would mean that both the LSP extension and the git extension would need to simultaneously be able to modify the file items.

Finally, it would be great to have a working mechanism for toggling these columns.

To summarise I would like to request (and help in implementing) a public API for following functionalities:

add/remove class for file/directory item
- if file icon is a separate element, then also add/remove class for file icon (to allow to add modifiers with CSS)
add/remove column for the browser
add/remove non-column decorator (this is distinct from a custom column in the way that it does not take a full column of width/space, and distinct from simple custom class in that it allows for more complex decoration and can be used for important information that would not meet accessibility criteria if only presented using a CSS class) for file/directory item
add/remove indicator for the breadcrumbs

Would all of the above be in scope for tree-finder? Is it possibly already capable of the above?

#9: breadcrumbs
#10: file filter