Hi @lissitz, great contribution to the open source community.

I wonder, are you willing to accept PRs to this repo? I want to expose dispatch function to onExpand and onSelect in addition to onBlur for which you have already exposed dispatch.

The purpose is to be able to code accordion-like functionality, that collapses previously expanded branches when clicking on a new collapsed branch.

Is it possible to publish a new release to NPM?
I would like to use the treeview with react-18.

Describe the bug
I'm trying to use isBranch property inside flattenTree function but it's doesn't persist

To Reproduce
Steps to reproduce the behavior:
Try to execute a function with an object that has isBranch property

aria-selected and aria-multiselectable are used for all instances of the TreeView. This results in a reasonable screen reader UX for TreeView instances which do not involve checkboxes when nodes can only be selected. For TreeView instances which do include checkboxes, however, it creates a user experience which could be better.

Specifically, because of the aria-selected usage:

1. a checkbox node with indeterminate state (half selected) reads out "not selected".
2. the selected state of a selected node is not read out when you navigate to it (it only announces nodes that are not selected for some reason).

If aria-checked is used instead, the screen reader will read "checked" or "not checked" instead of "selected" or "not selected" which IMO more accurate describes the action executed. More importantly, the use of aria-checked successfully:

1. handles the indeterminate state (using aria-checked="mixed"), reading "<node name and level> checkbox half checked".
2. announces the selected state of a selected node when you navigate to it. (eg. "avocados checked one of five level two").

The section of this W3C article on making a treeview accessible which starts "The selection state of each selectable node is indicated with either aria-selected or aria-checked" provides describes that aria-selected or aria-checked can be used in tree views.

A way to handle this which seems advisable to me is to provide a prop for the TreeView component to allow consumers to indicate if the TreeView will be using checkboxes or not (perhaps nodeAction?: 'check' | 'select'). If a consumer indicates their TreeView instances uses checkboxes, the resulting HTML will use the aria-checked attributes; else, it will use the existing aria-selected and aria-multiselectable attributes. These changes have been submitted in PR #33.

The devDependency eslint-config-react-app was updated from 5.1.0 to 5.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-config-react-app is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hi I was wondering if someone can help me please?

In the w3 APG TreeView Pattern it says:

When a single-select tree receives focus:
If none of the nodes are selected before the tree receives focus, focus is set on the first node.
If a node is selected before the tree receives focus, focus is set on the selected node.

If I tab to the first tree item of the tree view I can see the tabindex attribute is set to 0. This is good.
If I tab again and it takes me away from the tree view component to the next interactive element. This is expected.

What I noticed is that when navigating away, the component sets the first tree item to tabindex="-1" which means if I press shift and tab I will no longer be able to navigate to the treeview first item (or any item).

The first node should be selected when I tab back to the component but this isn't the case.

The same thing happens when you select a node and tab away and tab back more than once.

Codesandbox Link

The devDependency @testing-library/dom was updated from 6.11.0 to 6.11.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@testing-library/dom is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Describe the bug
docs of onNodeSelect says onNodeSelect called when a node was manually selected/deselected but
updating selectedIds array fires onNodeSelect

I've created a sandbox as an example. button click fires react-router-dom's useNavigate hook, after the navigation selectedIds will be updated (as its state depends on query params) therefor onNodeSelect will be fired even though I haven't selected/deselected anything manually

To Reproduce
Steps to reproduce the behavior:

1. Visit sandbox
2. open the console to observe
3. Enter https://pmpsq8.csb.app/folders/2 in URL of the sandbox
4. Click(expand) Node modules
5. Click button which is at the top of the page
6. you will see that after the navigation onNodeSelect gets fired

Hi, is there a way to add more data to a node object?

As a maintainer, I'm logging this "feature request" because it's something my team plans on executing in the foreseeable future, but I want there to be visibility to the consumers of this library. Please provide feedback if you have any regarding this issue.

Core Principles
There are two principles for a tree component that must be upheld with regard to parent nodes to ensure good usability and accessibility. A parent node should:

1. always correctly inform the checked status of its children.
2. provide a convenient means for selecting/unselected children.

Problem Statement
Being able to disable a parent node and have its children not also be disabled automatically creates situation that doesn't make any sense and creates usability and accessibility issues

Details
Currently, only nodes passed in defaultDisabledIds will be disabled. This means that if a parent is disabled, its children will not automatically be disabled. eg:

In the example above, it doesn't make any logical sense to say "'Tea' should not be selectable, but all of its children should be."

More importantly, being able to select children of a disabled parent creates serious issues due to propagating selection to/through the disabled parent node. Currently, no selection (not even half-selection) is propagated to/through a disabled parent node when a child is selected. This causes usability and accessibility issues when the parent (or grandparent) is collapsed because a user can't tell what children are selected. If you argue "well then just propagate selection to/through the disabled parent node", that would create a situation where you could effectively select a disabled node by selecting all of its children which would be a huge issue.

For these reasons, children of a disabled parent node should be automatically disabled.

Note: For large trees - would be nice to have ability to scrollTo a specific node - see behavior from antD Tree -

https://ant.design/components/tree#tree-methods

Describe the solution you'd like
A method on the tree instance that allows developers to programmatically scroll to a specific node and align accordingly.

What value does this proposed solution bring to users?
When auto-selecting - like after a search - allows the tree to focus on the selected node
Displaying a large tree with selections - allows developers to focus on the actual selected value vs user having to manually find previously selected nodes.

Describe alternatives you've considered
Custom event to scroll using document.querySelector or scrollIntoView()

See screenshot, this is after installing with standard npm

Describe the bug
On Event, onSelect and onNodeSelect does not return the element that was selected, but returns the last selected parent element? Happy to make any changes but I'll likely need some direction if possible.

Code That Causes The Issue
Here is my implementation. I still unsure what would need to change upstream but I'll update the ticket as I learn more.

<TreeView
            className={"c-list--ul"}
            data={flattenedTreeItems}
            expandedIds={expandedIds}
            onExpand={allowMultipleExpanded ? null : oneNodeExpansion}
            onNodeSelect={ (event ) => { 
                console.log(event) // Here! event.element is always a parent element and not the element i would expect.
                //const { url, openNewTab } = event.element.metadata
                //if ( openNewTab ) window.open(url);
                //else window.location = url;
            }}
            nodeRenderer={({
                element,  
                isBranch,
                isExpanded,
                getNodeProps,
                level,
                handleExpand,
                treeState,
            }) => {

                const { name:text, metadata } = element
                const { icon, url, ...otherItemProps } = metadata

                    return (
                        <div    
                            {...getNodeProps({ onClick: handleExpand })}
                            className={"c-list__item"}
                            tabIndex={-1}
                        >
                            <Button
                                {...otherItemProps} 
                                {...other}
                                className={clsx(
                                    {
                                        ['c-btn--has-icon']: icon,
                                    },
                                )}
                             
                                href={url}
                                layout="block"
                                text={text}
                            ></Button>
                            {( isBranch && isExpanded ) && (
                                <Icon name='circle-minus' size='small' theme={active ? 'solid' : 'regular'} color={ active ? 'dark-blue': 'light-blue'} />
                            )}
                            {( isBranch && !isExpanded ) && (
                                <Icon name='plus-circle' size='small' theme={active ? 'solid' : 'regular'} color={ active ? 'dark-blue': 'light-blue'} />
                            )}
                        </div>
                    );
                
            }}
        />

To Reproduce
Steps to reproduce the behavior:

1. Populate tree with buttons
2. Tab past the first node
3. Select Enter
4. console.log of event shows that element is always the first element in the tree

Expected behavior
onSelect({element, isBranch, isExpanded, isSelected, isHalfSelected, isDisabled, treeState })
onNodeSelect({element, isBranch, isSelected, treeState })
I would expect element to return the attributes of the node that was selected/unselected

Desktop (please complete the following information):

• Browser: Chrome
• Version 117.0.5938.132 (Official Build) (x86_64)

Additional context
I'm utilizing this package to create an implementation for a site's side navigation where my node elements are buttons. In order for the buttons to work with keyboard controls, I need access to the element that was in focus on Enter. I have my implemenation published to our dev storybook, and its the sticky sidebar on the right. https://staging-camino.sandiego.edu/storybook/?path=/story/templates-detail--text

The devDependency eslint-plugin-react was updated from 7.18.0 to 7.18.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-react is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I have a concern and I would love to know if this is your expected behaviour (see video attached).

In the APG Tree View Design Pattern notes it says:

For a vertically oriented tree:

When a single-select tree receives focus:
If none of the nodes are selected before the tree receives focus, focus is set on the first node.
If a node is selected before the tree receives focus, focus is set on the selected node.

When a tree item receives focus using the keyboard it has a tabindex value of 0. Then every other field is set to tabindex -1. This is using roving tabindex I guess.

If I tab away from the tree view, the currently focused item will have a tabindex of 0. When I tab back into the tree view component that previous item will regain keyboard focus because it still has a tabindex of 0.

But should it? That item is not in a "selected" state. See the video, I did not select the item but it regained focus. Shouldn't item 0 (from default state) regain focus? or is this a behaviour you desire?

Describe the bug
The onNodeSelect callback should be invoked in the scenario where an already selected node is selected to go from a selected -> halfSelected state.

Code That Causes The Issue
See failing unit test in PR #118

Test in TestViewOnNodeSelect.test.tsx - "onNodeSelect should be called when node is deselected to a half-selected state"

To Reproduce
See failing unit test in PR

Expected behavior
See failing unit test in PR

Additional context
The use case here is when the selectedIds are controlled with custom logic determining the propagation, therefore the propagate props are disabled. In this scenario the lack of callback to onNodeSelect prevents the consumer from being notified of the interaction with the node.

It would be nice if the classNames set by baseClassNames could be controlled via props. So you could use e.g. the Bootstrap classes without writing custom CSS.

Getting this error while following the examples in a custom react build
Using example code to test

Describe the bug
There are some issues with using controlled state for expanded IDs. Consider this example where expanded state is controlled in the parent component (a practical example would be where state is persisted in local/session storage).

Code That Causes The Issue

const data = flattenTree({
  name: '',
  children: names,
})
const parentIds = useMemo(
  () =>
    data.reduce<NodeId[]>(
      (acc, node) => (node.children.length ? acc.concat(node.id) : acc),
      []
    ),
  [data]
)
const [expandedIds, setExpandedIds] = useSessionStorage(storageKey, parentIds)

<TreeView
  data={data}
  onExpand={({ element: { id }, isExpanded }) => {
    setExpandedIds((ids) =>
      produce(ids, (draft) => {
        if (!isExpanded) {
          remove(draft, (nodeId) => nodeId === id)
        } else {
          draft.push(id)
        }
      })
    )
  }}
  expandedIds={expandedIds}
  onNodeSelect={({ element }) => {
    // ...handle
  }}
  nodeRenderer={(props) => (
    <NodeRenderer {...props} itemProps={nodePropsMap[props.element.name]} />
  )}
  clickAction="EXCLUSIVE_SELECT"
  aria-label="Navigation"
  expandOnKeyboardSelect
/>

The values passed into expandedIds cause onExpand to be called on the initial render. This also causes the list items to be focused on the initial page load which is an accessibility issue.

To Reproduce
Use parent state to control the expanded IDs.

Expected behavior
Like with form inputs, I'd expect that controlled state to accept an initial value, and subsequent changes to the state from user input to call a callback, such as onExpand.

Desktop (please complete the following information):

• OS: macOS
• Browser: chrome
• Version: 114.0.5735.133 (Official Build) (arm64)

It would be great to be able to pass an object of properties to the node on its definition, in order to use it in the renderer. Something like this:

data: [
  name: 'aNode',
  data: {
    ...someProps
  }
}

Currently when I use flattenTree, its not possible to pass a different id to get the props from another place and the name is not a good aproach due to there it could be many nodes with the same name.

Thank you

Summary
Expanding/collapsing child deselects parent when propagateSelect is false.

Reproduction environment
https://codesandbox.io/s/hungry-keller-7dg0cb

Steps to recreate in example

1. Expand the "Drinks" node.
2. Select "Drinks" node.
3. Expand "Tea" node.

Expected outcome:
"Drinks" selected status does not change.

Actual outcome
"Drinks" is de-selected.

Additional notes
If propagateSelectUpwards is set to false this issue does not occur.

I do not like the fact that tickets are locked immediately. This is not only disrespectful, because you no longer allow feedback, but you also prevent a productive exchange within the community.

In any case, it makes the impression that feedback is unwanted and I think that should not be the case. I wanted to start a discussion on a topic that would also benefit the reach of this library and my ticket was locked after the first reply. I would have more to say about it and besides, the same question could come up to other developers.

I would love to use this library and would also be willing to contribute.

Thank you and keep up the good work.

Hi @lissitz. I noticed that there are no typescript types for this library in DefinitelyTyped and the library itself does not export any type information.

I'm one of those people who loves converting JS libraries to TypeScript.

Would you be interested in either:

1. A PR that provides types from within the library but keeps the library?
2. Or, a PR that converts the library to Typescript?

Option 2 is significantly easier for me and is more accurate from consumers since it doesn't allow the type definitions to drift away from the runtime types since they would be derived from the same source.

As a maintainer, I'm logging this "feature request" because it's something my team plans on executing in the foreseeable future, but I want there to be visibility to the consumers of this library. Please provide feedback if you have any regarding this issue.

Problem Statement
Disabling selection propagation upward and/or downward creates serious usability and accessibility issues.

Core Principles
There are two principles for a tree component that must be upheld with regard to parent nodes to ensure good usability and accessibility. A parent node should:

1. always correctly inform the checked status of its children.
2. provide a convenient means for selecting/unselected children.

Allowing selection propagation to be disabled in either direction goes against both of those principles.

Details
The usability and a11y issues are most easily seen when selection propagation is disabled in either direction and a parent node is collapsed. In this first example, if "Fruits" was collapsed, a user would believe no children were selected even though one or even all could be.

In this second example, if "Fruits" was collapsed, a user would believe all children would be selected even though none are.

From an accessibility standpoint, looking again at the first example, if a screen reader user focuses the "Fruits" checkbox, the screen reader would announced "Fruits not checked collapsed 1 of 3 level 1". This would have the user think "Since 'Fruits' is collapsed, that must mean it has children, but since it was announced as 'not checked', neither 'Fruits' nor any children are checked."

For these reasons, the ability to disable selection propagation should be removed.

Getting this error while following the examples in a custom react build

In some of the examples we have

onBlur={({ treeState, dispatch }) => {
  dispatch({
    type: "DESELECT",
    id: Array.from(treeState.selectedIds)[0],
  });
}}

This deselects the selected node when we focus away from the component. It also breaks the focus tabindex issue #48.
I suggest we remove this from all examples/docs.

Not expecting a fix, just a heads up for folks who encounter the same issue.

You may see something like:

TypeError: Cannot create property 'id' on number '2'

🚨 Be wary of shallow cloning, objects are copied by reference:

flattenTree({ name: '', children: [...data] }) // `children` arrays (and other objects) are still mutated!

✅ Consider something like lodash.cloneDeep:

flattenTree({ name: '', children: cloneDeep(data) }) // original `data` remains intact

Describe the bug
When trying to use controlled selectedIds to check checkboxes in the tree, every time you change the value of selectedIds the tree suddenly steals keyboard focus from whatever control on the page had it last.

Code That Causes The Issue
I believe this was introduced in 1f9b062 after dispatching controlledSelectMany for the parents if propagateSelect is enabled it will use the regular changeSelectMany, passing in id for lastInteractedWith, which causes focus to be stolen by the tree.

To Reproduce
You can see this in your "Checkbox with controlled selectedIds" example included with the project.

1. Type a node number into the textbox and press enter instead of clicking the submit button.
2. Focus leaves the text field and immediately jumps into the tree.

Expected behavior
The most obvious use for a controlled set of Ids would be if you were applying changes as the result of an action performed elsewhere on the page. I would not expect performing an action elsewhere to move my keyboard focus into the grid.

Desktop (please complete the following information):

• OS: N/A Desktop PC
• Browser Firefox, Chrome
• Version It doesn't matter

Additional context
I was looking to display some data in a tree and I found this control. It seems to fit that need perfectly, but the actual behavior when setting node selections currently makes it an awkward choice.

In the case where I want to use this I have a regular list of items at the top of the page and a tree with properties for those items on top. Switching the item in the list should update the tree to show the properties for the item selected. But if I use the arrow keys to try and navigate the list of items, every time I arrow down on the list and update the tree with the appropriate selections of checkboxes, the tree immediately steals focus making just general browsing of data a challenge. Additionally I have "Check" and "Uncheck all" buttons similar to the uncheck button on the sample page, clicking those buttons also steals focus and sends it to the tree. When someone is using the mouse this isn't a huge problem but it's annoying when you're trying to use the keyboard.

1f9b062 appears to be fixing some kind of problem with focus being lost, but could we fix this new problem just by setting lastInteractedWith to null if the grid does not have focus so that it does not steal focus? In my case, just changing lastInteractedWith to null on line 276 of index.tsx completely fixes the stolen focus problem, but I suspect it's breaking whatever that previous commit was trying to solve.

When I pull down the master branch and try to run npm i, I get the following error:

Not sure why this codebase does not have a package-lock.json checked in...

Is there a way to select any node through a function call where the parent nodes will automatically expand, and that node will be selected?

Something look like this: treeRef.dispatchAction({type: 'SELECT', id: 15});?

Describe the bug
This bug happens when the user wants to have all branches expanded and chooses to have a dynamic node adding/deleting system.
By adding two or more nested branches and then deleting them an error will occur : "Node with id=x doesn't exist in the tree"

As an example i have created a sandbox. Clicking the button "add node" will add a node as a child to a node that has been selected, clicking the button "delete" will delete node that has been selected (and all it's children).

To Reproduce
Steps to reproduce the behavior:

1. Go to this sandbox
2. Click on 'node 1'
3. Click on 'add node' button
4. Repeat until you have 3 levels of nested nodes (see screenshot)
5. Start deleting nodes from the lowest level up ('node 3', 'node 2', 'node 1')
6. See error

Expected behavior
It is expected that you get an error "Node with id=x doesn't exist in the tree"

Screenshot
This is the look of the tree at step number 4:

Desktop (please complete the following information):

• OS: [Windows 10]
• Browser [Firefox]
• Version [114.0.2]

I want to use this component in combination with a multiline textfield in a sub node.
But in the textfield when I press the enter key or space key, the onSelect event of the tree triggers this key press event.
Is there a way to turn off keyboard navigation completely in the tree?

There have been updates to the storybook monorepo:

• • The devDependency @storybook/addon-actions was updated from 5.2.8 to 5.3.0.

• The devDependency @storybook/addon-links was updated from 5.2.8 to 5.3.0.
• The devDependency @storybook/addons was updated from 5.2.8 to 5.3.0.
• The devDependency @storybook/react was updated from 5.2.8 to 5.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the storybook group definition.

storybook is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

it is posible to add additional data ? like i want to add object category_id

const data = [
{ category_id: null, name: "", children: [1, 4, 9, 10, 11], id: 0, parent: null },
{ category_id: 1, name: "src", children: [2, 3], id: 1, parent: 0 },
{ category_id: 2, name: "index.js", id: 2, parent: 1 },
{ category_id: 3, name: "styles.css", id: 3, parent: 1 },
{ category_id: 4, name: "node_modules", children: [5, 7], id: 4, parent: 0 },
{ category_id: 5, name: "react-accessible-treeview", children: [6], id: 5, parent: 4 },
{ category_id: 6, name: "bundle.js", id: 6, parent: 5 },
{ category_id: 7, name: "react", children: [8], id: 7, parent: 4 },
{ category_id: 8, name: "bundle.js", id: 8, parent: 7 },
{ category_id: 9, name: ".npmignore", id: 9, parent: 0 },
{ category_id: 10, name: "package.json", id: 10, parent: 0 },
{ category_id: 11, name: "webpack.config.js", id: 11, parent: 0 },
];

The indeterminate (half-selected) state is only being set for the parent. eg:

It should be set for all ancestors (assuming propagateSelectUpwards is true).

The main issue this causes is that you can't see if any children are selected when nodes are collapsed. eg:

First of all, thank you for the work!

I would like to implement this component in Mantine, for which I would need the ability to override the list component so that I can use a custom component for <ul>.

I wonder if this would be feasible?

The devDependency rollup was updated from 1.29.0 to 1.29.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

rollup is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency lint-staged was updated from 9.2.2 to 9.2.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

lint-staged is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

There have been updates to the babel7 monorepo:

• • The devDependency @babel/core was updated from 7.7.7 to 7.8.0.

• The devDependency @babel/plugin-proposal-object-rest-spread was updated from 7.7.7 to 7.8.0.
• The devDependency @babel/preset-env was updated from 7.7.7 to 7.8.0.
• The devDependency @babel/preset-react was updated from 7.7.4 to 7.8.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

This monorepo update includes releases of one or more dependencies which all belong to the babel7 group definition.

babel7 is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency eslint-plugin-import was updated from 2.20.0 to 2.20.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-import is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency react-icons was updated from 3.8.0 to 3.9.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

react-icons is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hi @lissitz, I'd like to formerly request (a) to be made admin of this repo and (b) to be given NPM publishing access. This is a continuing from the conversation in #23 (comment) where you said:

lissitz commented on Apr 1
Yes, I'm open to eventually adding you as a maintainer 🙂.

My team and I have made significant updates to this library and have motivation to continue maintaining it for the foreseeable future. But in order for us to do that, we need to be able to publish it whenever we have a business objective or a customer commitment. Having to rely on someone outside of our team causes us to miss those deadlines. For example, we have PRs that haven't been released in 20 days as of this writing.

So @lissitz, please choose whichever option is best for you. The options I see are as follows (in order of my preference):

1. Full transfer:
   • Transfer the NPM name to me: https://docs.npmjs.com/transferring-a-package-from-a-user-account-to-another-user-account
   • Transfer the Github repo to me: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
2. Additive:
   • You add me as an NPM owner. This has the negative consequence that one of us might release the library at the wrong time and cause race condition type of situations. But I'm sure we could make it work.
   • You add me as a Github admin for this repo so that I can update the protected branch status rules and move away from Travis (This saves you from having to grant me Travis access and it lets my team build the repo using Github Actions which we are highly skilled in).
3. We deprecate this library and fork:
   • I would create a fork of this library publish it myself on NPM as the owner as the sequel to this library
   • We'd add a deprecation warning so that anyone who installed this library were informed to use the new fork that I own
   • We'd update the readme to explain the where to go for the official fork

I want to emphasize that the choice is yours. I want this to feel like we're here to support you and to celebrate your wonderful accomplishments of creating (what I believe is) the only accessible tree view for React. Well done! You've done great work so now you should be able to rest on those laurels and let us take it into maintenance mode.

Is there a way to collapse or uncollapse all nodes and their descendants without setting the defaultExpandedIds prop?

Describe the solution you'd like
I want to pass some metadata to each node whilst creating the checkbox tree data.

type INode<T> = INode & {
    metadata: T
}

What value does this proposed solution bring to users?
The users will then be able to customize the outlook of each node, for example, if they want to add a number of children alongside the name they can pass that information to the parent nodes' metadata. Another example would be to be able to add tags, which can show as span elements alongside the element's name.

Describe alternatives you've considered
The alternative currently is to pass all this information somehow inside the name string and then parse that information in the nodeRenderer method. But that seems sub-optimal.

When using an external search bar, the focus gets eaten after changing the expandedIds to show the found items, I am sending an example

Is it possible to create a node?

Is it possible to add support to accept Data id String?

Thanks.

Describe the solution you'd like

As per my comment here, I think we can improve/expand on the metadata object that was recently added to tree nodes.

In general, metadata is used to provide additional static properties that can be used to provide unique rendering or functionality to the given node. In many (similar) libraries, we can also use this metadata object to pass mutable data between rerenders. With this in mind, the current scope of the metadata object is too limited. Therefore, I propose that we do 2 things:

1. Do not clone metadata in the flattenTree function
2. Allow any object (keys/properties) as metadata

1. Do not clone metadata

As a user, I would expect that metadata object that I pass into a node would be the same object before and after the flattenTree call. In most javascript/typescript libraries, it is generally expected that if you pass an object to a function, then that object is mutable. If you (the user) don't want your data to be mutable, then you (the user) should handle the immutability yourself.

Therefore, we should not be doing a shallow clone of the metadata object as this breaks the expected way in which javascript objects should be handled

2. Allow any object (in the types)

The only reason we currently only allow a non-nested object is so that flattenTree can do a shallow clone. However, users who build their INode trees manually, either through async data calls or through manual data mapping, do not use flattenTree and therefore should not be limited in how metadata is handled in their nodes.

If we are no longer cloning the metadata object (see my first point), then there is nothing stopping us from supporting any object as metadata. This would allow us to pass anything as metadata including nested objects, functions or even an instances of a class.

For example, you could pass a helper function to determine which color to use, rather than having to pass a hard-coded color to the metadata object:

const metadata = {
  defaultColor: 'red',
  getNodeColor: (rendererProps: INodeRendererProps): string => {
    return rendererProps.isSelected
      ? someComplexWayToCalculateColor()
      : renderProps.element.metadata.defaultColor;
  },
}

If there are changes to the interfaces, please describe them here:

1. Rename IFlatMetadata to IMetadata
2. Don't use the Record<> helper type. The metadata object is completely user controlled and operated on, we don't do anything with it except detecting if it exists. Therefore, the type of metadata should be unknown.

export type IMetadata = unknown;

We should also allow users to set the type of the metadata when defining the props of their tree. Therefore, we should add generics for metadata to any interface or function that contains a reference to the INode type so that user defined metadata correctly propagates to all internal functions. This includes:

ITreeViewProps
ITreeViewOnLoadDataProps
ITreeViewOnExpandProps
ITreeViewOnNodeSelectProps
ITreeViewOnSelectProps
INodeRendererProps
INodeProps
INodeGroupProps

usePreviousData
isBranchNode
getParent
getAncestors
getDescendants
getChildren
getSibling
getLastAccessible
getPreviousAccessible
getNextAccessible
propagateSelectChange
getAccessibleRange
propagatedIds
isBranchSelectedAndHasSelectedDescendants
isBranchNotSelectedAndHasAllSelectedDescendants
isBranchNotSelectedAndHasOnlySelectedChild
isBranchSelectedAndHasOnlySelectedChild
getTreeParent
getTreeNode
validateTreeViewData

Node
NodeGroup

Describe alternatives you've considered

I'm not sure this applicable here.

Additional context

I would be happy to submit a PR to handle this.