Supporting windowing back to server-side

[zikaari]

Supporting windowing back to server-side

[zikaari]

This is actually pretty straightforward, but of course, it'll require some effort.

You see, what makes react-aspen so magical is actually aspen-tree-model. The heavy lifting happens in aspen-tree-model, this package just glues it up with react-window. Why am I telling you this? Because you can decouple aspen-tree-model and provide a custom implementation to react-aspen, as long as you implement the same interface.

Here's how you can make this work:

The following steps assume your backend is Node.js, and you can use WebSockets

1. Install aspen-tree-model on your server
2. For each incoming Socket, create a new TreeModel to track the state of the file tree. This TreeModel will be the real source of truth for the lifetime of this Socket connection
3. Expose the TreeModel API over WebSocket so it can be called by the client
4. Create a TreeModelClient class in your React app which implements the public API of real TreeModel.
5. Now as far as the model prop of the <FileTree /> component is concerned, it sees no difference, and that's how it gotta be.
6. All you need to do now is just relay the TreeModelClient method calls to the TreeModel active for that specific connection over WebSockets and return the result from the backend.

But before you dig in, here are some gotchas that you need to watch out for:

1. react-window is going to ask react-aspen for a renderable component at index i, and react-aspen is going to ask model.root for data at index i. The thing is, this cycle is not batched, it is instead run one-by-one. You'll have to have implement "batching" on your own such that when index i is requested, you'd know that the next index that is going to be requested is going to be i + 1 or i - 1, so instead of relaying these requests one-by-one over Socket, you can issue a batched query where you fetch i + 10 and i - 10 at once and then cache it for later use. And of course, flush the cache when you receive a filesystem change event.
2. File system events are going to be slightly tricky because if multiple of them are emitted within a short time period, you could end up in a race condition where the client receives them in a different order. So think about how you can handle that problem.
3. And last but not least, have a look at the entire Root class from aspen-core to see if this entire thing is feasible.

[zikaari]

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.

I can't imagine a way to make this strategy work due to the intrinsic nature of windowing libraries. They expect a "flat" world where first you give them the total number of items, and it'll ask you to render an item at a given index. But it's not straightforward to map an arbitrary index to a file system entry that'd be returned by getItems. Or put another way, it's not straightforward to map an index to a key nested deeply in an object.

The strategy I described in the comment above is all I can think of at this time.

[zikaari]

Closing due to inactivity