expand should only expand?

[AlabasterAxe]

I'm running into an issue where I'd like to expand newly added elements but preserve the expansion status of existing elements. The current behavior of expand to collapse if returning false is making this difficult to implement. Ideally, expand would only ever expand or do nothing. I think it would be reasonable to have an alternate collapse function that has the opposite behavior.

[josdejong]

Thanks for your suggestion Matthew. It is a good idea to rethink the current expand function. It is quite powerful, but maybe too powerful, probably making it confusing to use. And it is still too limited like for the case you explain.

Before we do, it will be good to have a clear idea of the typical use cases. Here a start:

1. expand everything
2. expand everything that matches a predicate, collapse everything else (like expand everything up to 2 levels deep)
3. expand everything that matches a predicate, but keep nodes expanded that are already expanded
4. expand all parent nodes of a single path
5. expand all nested children of a single path
6. collapse everything
7. collapse everything that matches a predicate, leave non-matching cases unchanged
8. collapse all nested children of a single path

Anything to add to this list?

One approach may be to create multiple methods to cater for these use cases. An other approach is to extend the current callback function of the method expand to pass the current state (collapsed/expanded) of a node too, so you can keep already expanded nodes expanded if you want. Or ad an other flag to expand to specify whether to collapse non-matching paths or not.

[AlabasterAxe]

I can't think of anything else to add to that list. 👍

An other approach is to extend the current callback function of the method expand to pass the current state (collapsed/expanded) of a node too, so you can keep already expanded nodes expanded if you want.

I love this idea. It feels super powerful. When I was trying to implement this I actually suspected that the current state of the corresponding node may be provided as a second parameter to the callback already so this API feels natural to me. Also importantly, it should be completely backwards compatible with the existing API.

A couple other ideas that occurred to me (not all of which I think are good ideas, to be clear :) )

• accept undefined from the callback which would mean that the expansion state would not be affected
• convert the response to an enum which would be expand, collapse, none (or smth similar)

Ultimately I think the additional parameter to the callback is the best option.

[josdejong]

Yeah, thinking about it more I like it too. I like both passing of the current state as well as being able to return true (expand), false (collapse), or undefined (leave as is). Strictly speaking that is not a breaking change.

With those extensions of expand, I think it is possible to built utility functions on top of it to cater for every of the cases mentioned above, if there is need for that.

[josdejong]

I've implemented an API for this with an explicit .expand() and .collapse() method, see #458 (not yet published, will become available in v1.0.0)

[josdejong]

I've just published v1.0.0 containing the new expand and collapse methods.