Mismatches between ES code and TS typings

[NicoleRauch]

Hi all,

I've just started exploring whether react-virtualized-tree might be a viable solution for my project, and so far it looks really good! Thanks for providing it :-)

But I'm working with TypeScript and so I bumped into some mismatches between the actual code and the typings. I hope you can get me sorted here.

1. ExpandableRenderProps is the type of the props that the Expandable renderer receives. The Expandable component clearly makes use of the children prop (see lines 16 and 38) but the type does not contain children. Is this an error in the typings? Or am I misunderstanding something here?

2. The onChange() handler of the Expandable renderer is supposed to receive a NodeAction as per the TS types, but it is always invoked with the full tree. I'd be very interested in getting a NodeAction for reasons of post-processing (so I am not forced to reverse-engineer the new tree to figure out what changed), but from looking at the code of Expandable.js it is not clear to me where I can get that from. Can you please point me in the right direction here?

Thank you,
Nicole

[diogofcunha]

Hi Nicole.

Sorry for taking a week to reply. This is a challenging issue and I could not give a proper explanation on my mobile.

1. I did not include children on the type definition because generally when you use this interfaces to create a react component (React.Component, React.SFC, ...) children is automatically added to the props via extension. In some use cases this interfaces may not be used inside react component, I will add children as an optional prop.

2. The type definition for onChange is correct, and by design I'm glad to announce that you have several escape hatches where you can override the default change handler for any type

Why Renderer and tree onChanges are different

My 2 main goals when developing this project were:

1. Allow maximum extensibility without creating a beast like interface
2. It needs to be easy for someone to create a tree "out of the box"

Merging the two points I made a few design choices:

1. Make almost 0 ui assumptions
2. Allow the core of this library to stay as small as possible, this means not having 10000x renderers and restrain peoples usage
3. The tree only acts as an entry point for data:
   • normalizes data for render
   • implements a set of default operations to make users life easier

In order to implement the set of default operations the grid needs to handle changes in the nodes, that is achieve using IOC (render prop onChange), this render prop is a function that deals with the NodeAction and as you can see in the examples is always injected as a prop in the renderers (here). You can find the source of the injected function in here

As from personal experience I knew that although this simple handling cover 80% of the use cases but not the remaining, I built some escape paths.

You have 2 options for you requirements:

1. In your Tree render method, instead of inject the tree's own onChange logic to the Renderer, inject your own.
2. Override the logic as needed (can find an example in here)

Hope this helps.

If you do have any more implementation questions fell free to join our gitter room