zikaari/aspen

Most advanced nested tree renderer for React apps

aspen's Issues

Find another filesystem watcher to recommend

@atom/watcher is unmaintained and only supports Electron 12. Electron is all the way up to major version 16 now. Perhaps you should recommend something else such as chokidar, or sane which supports multiple backends (incl. polling).

Allow getting current scroll

I'm trying to implement a drag and drop thing but in order to do that I need to calculate which item the cursor is dragging over. I can't do that without knowing the scroll position of the tree view, which right now requires poking at private fields that I honestly don't even really have access to (due to the FileTree itself being buried down a bit). Could you add an API for getting the current scroll position of the tree view?

container.firstElementChild!.firstElementChild!.scrollTop is kind of jank

is alive?

this project is alive?

Getting a FileEntry by path

In my file watcher I'm performing some extra operations on certain files (when they're in a special folder, I do some parsing on them and set metadata so that the rendered items can display this data). I can't seem to get a hold of the FileEntry corresponding to some path.

I need to do this to update metadata when renames happen. My application uses atomic writes so I need to re-do the detection and parsing logic when something is renamed.

model.root.inotify seems to know what to do with paths so how come I can't do the same?

Ability to set scroll offset without using the DOM directly

Related: #16

Aspen 2 release discussion

This thread will be used to track and discuss the next leap in super-performant tree rendering on planet Earth - Aspen 2.

The next version of Aspen has the following core goals:

• Even better performance
• More versatility, i.e not being limited to just "file trees"
• More lightweight, i.e removing as many dependencies as possible
• Codebase enhancements, i.e using functional components, and switching to a monorepo

The stepping-stone has already been set over at aspen-next branch in this repository. Everything you see there is subject to change as the project advances to the beta stage. Many features from current Aspen are yet to be ported over to Aspen 2, but the core framework has already been laid out. The breaking changes can be reviewed in the changelog, this will keep on evolving as the project advances.

You can subscribe to this issue by clicking Subscribe on the right to be notified on the progress of Aspen 2, including the beta release, and up to the final release.

cc @LoganDark @fintara @graup @rodgomesc @adamgruber @khushboovashi
Since you folks use react-aspen in production, your feedback is very important in the direction Aspen will follow.

ensureVisible inside useEffect and "two children with the same key"

Reproduction: https://codesandbox.io/s/sweet-mestorf-jcqoo?file=/src/App.js

In short, I have to track the path of the file that is currently selected. It can be changed externally (i.e. not from the tree), as in the example via next/prev buttons. I pass this state to the tree so that the folders expand when necessary via ensureVisible.

If you click "NEXT" several times, React will complain that there are "two children with the same key", and indeed, you can see how the labels mix up.

Any ideas?

Large data hangs the page and it crashes

Hi,
I created data that has one parent and 100 child nodes. This worked perfectly.
Then I created data with one parent and 50k nodes. This makes the page hang and then crashes.
largeData50k.txt
I have attached my file for your reference.

Question - load tree

any docs about how to load tree with a javascript object instead of using system patchs ?

like:

const data = {
  id: 'root',
  name: 'Parent',
  children: [
    {
      id: '1',
      name: 'Child - 1',
    },
    {
      id: '3',
      name: 'Child - 3',
      children: [
        {
          id: '4',
          name: 'Child - 4',
        },
      ],
    },
  ],
};

PromptHandle.ProxiedInput only supports className, style, and id props

This breaks style scoping, as the attributes which allow my styles to apply are not properly passed through to the input

Uncaught Error: orphaned/detached FileEntries don't have path (except Root)

Uncaught Error: orphaned/detached FileEntries don't have path (except Root)
    at FileEntry.get path [as path] (FileEntry.ts:78)
    at ItemRendererWrap.updateCachedItemPath (ItemRendererWrap.tsx:70)
    at ItemRendererWrap.componentDidUpdate (ItemRendererWrap.tsx:53)
    at commitLifeCycles (react-dom.development.js:20684)
    at commitLayoutEffects (react-dom.development.js:23426)
    at HTMLUnknownElement.callCallback (react-dom.development.js:3945)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:3994)
    at invokeGuardedCallback (react-dom.development.js:4056)
    at commitRootImpl (react-dom.development.js:23151)
    at unstable_runWithPriority (scheduler.development.js:468)
    at runWithPriority$1 (react-dom.development.js:11276)
    at commitRoot (react-dom.development.js:22990)
    at performSyncWorkOnRoot (react-dom.development.js:22329)
    at react-dom.development.js:11327
    at unstable_runWithPriority (scheduler.development.js:468)
    at runWithPriority$1 (react-dom.development.js:11276)
    at flushSyncCallbackQueueImpl (react-dom.development.js:11322)
    at flushSyncCallbackQueue (react-dom.development.js:11309)
    at scheduleUpdateOnFiber (react-dom.development.js:21893)
    at dispatchAction (react-dom.development.js:16139)

Looks like this happens when there is an extremely fast stream of inotify (hundreds of events per second).

Supporting windowing back to server-side

Currently, Aspen seems to require getItems() to return a list of all child items of a node.

If one node has hundreds of thousands of children, an extensive data structure must be retrieved (which could be over slow network connection), and kept in memory by browser’s renderer thread.

Perhaps this could be addressed with a different API, which doesn’t rely on getItems() returning item data, and instead does something similar to react-window: only request item counts necessary to know overall canvas size, and have item renderers within the current window do the rendering. Their React components can be given numerical item index, as well as indexes of the parents, and make async trips to fetch data as necessary.

Perhaps I’m missing something and the above is already possible, or is not considered a useful optimization (even though react-window does it).

Expand all initially?

Is it possible to have the tree fully expanded initially? Can you suggest how to implement expand all / collapse all functionality?

Improve NPM searchability

Right now, when searching for "react tree" on NPM, aspen-tree-model and aspen-decorations don't show up until page 5. However, react-aspen is still nowhere to be found until page 28!

This must have been the reason why I couldn't find it weeks and weeks ago when I searched heavily for a tree view package and could not find one for the life of me - aspen doesn't show up for tens of pages! Clearly this is not a great situation to be in, especially since it seems like an incredibly useful and performant library.

I was only able to find out about aspen after begging for a tree view library in the Reactiflux Discord server. Perhaps making it easier to search up will allow others to discover it more easily as well?

Looking for project maintainers/contributors

Aspen being an open-source project which is now being depended upon by some very important organizations, and individuals, it is important that I share the current state of where it stands and where it is headed.

As much as I'd love to continue giving Aspen a good amount of my spare time, it has become less and less feasible for me to do so over the past few months due to my focus shift on other areas of life - work, health, sports, art, etc.

I kicked off Aspen 2 couple of months ago, the progress of which can be followed here. The core foundation is already there in the aspen-next branch in this repository, and I'll make sure the basic low-level API is there in the coming few weeks to give Aspen 2 a good headstart. I'll explicitly announce that in the release discussion thread when that is done and it is ready to be extended to have advanced API be built on top off.

But that's where I need the community to jump in. The bitter truth is that Aspen 2 might never see the daylight if it continues to be just me running the project. As explained earlier, it has become less and less feasible for me to give my time.

In this thread, I hope to find at least 2 volunteers who can give some of their spare time to Aspen 2 and sail it towards a final release. This does not mean I'm stepping out of the project, it just means I'm seeking help to share the effort 🙏

Feel free to ask me any questions.

Covert this repo to a monorepo

Have all the core deps live in one place using lerna monorepo setup:

Core deps like:

• aspen-tree-model
• aspen-core
• aspen-decorations

Maybe also rename this repo from react-aspen to just aspen.