[lionkor]

The performance is quite bad. There are some basics missing or broken.

- no caching for file previews

- no sorting by date in the file picker

- no sorting by size in the file picker

- no sorting by file type in the file picker

- no search in the file picker

- cant enter a folder in the detail view (only expand) in the file picker

- cant go to page (by page number) in the document viewer

- after clicking a button in the document viewer, focus is lost on the document and arrow keys, space, pgup/pgdown dont work until the document is clicked again

- cant select text in the document viewer, unless I search first, in which case it then works

This is after looking at the file picker and document viewer less than 3 minutes(!!!). I gave up after that. Getting 80% of a file picker is easy, getting the last 20% done, so that it's on par with existing software, is not.

Very very odd to have things look this polished, yet be this terrible functionality- and performance-wise. These are not random quirky new ideas I'm having, these have been basics that work in every single file picker and document viewer since the early days of UI, before the web.

[gobdovan]

Yeah, it also seems it's made in React & Next. From experience, you'll have a hard time choosing a worse technology for low-level, interaction-heavy UI. You need direct control over focus, keyboard handling, scrolling and so on. You also need to leverage hardware accelerated rendering too, which is clunky with 3rd party React libraries.

What's more, even if state management should technically be easier with the amount of state libraries, you'll realise sooner or later that the established ones are cleverly immutable where you really just want them to be performant.

I am not saying that it's React at fault for the symptoms you see here, but I would expect any such library made in it to hit exactly these kind of edge cases.

[rrr_oh_man]

> From experience, you'll have a hard time choosing a worse technology for low-level, interaction-heavy UI.

Can you elaborate on that? What else would you recommend?

[gobdovan]

Yes! First, you need to get the DOM-level behaviour right (dragging, resizing, cursor focus). That could mean you may use or build primitives like with interact.js, CodeMirror/Monaco (realistically just use, not build), Fancytree. I really like Muuri for layouts. Usually there's also subtle interaction physics going on when building such libs in unexpected places (such as resizing and drag N drop speed curves), which you should tweak to your taste.

For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.

If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.

I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)

For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.

All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.

[kbyatnal]

Your issues are mostly with the file picker, which is a brand new component that was just added yesterday in response to a feature request after launch: https://x.com/andrewlu0/status/2064726998186971400?s=46

It has some rough edges as a result, but your suggestions are very valid. We’ll make those improvements (we’re also taking PRs!).

[lionkor]

Nice! That explains it to a degree. I would suggest taking someone who is really annoying about details, from your team, and having them just use the components as they are. Just click around and mess with them for a while -- in my experience this is how you get that final 20% of polish.

[kbyatnal]

agreed! dogfooding is the best — we'll integrate this into our core product, which will force us to improve it very quickly

[andrewlu0]

added some basic filtering/sort/search support, lmk what you think!

[e12e]

Since there was a recent thread on react compiler[r] - I wonder if adding/pushing the code through react compiler would help? (Assuming it's not already being used)

[r] Thread was about rewrite in rust, but it made me have a look at the purpose/claims made by the project - and fine-grained, automated memoization for speed seems central.

[andrewlu0]

Hey! Very valid feedback - working on improving the file system component and overall site performance today