expandedListItems and internal state

[efeminella]

The expandedListItems prop should allow for setting the initial expanded items within the list, after which, the Tree should be able to handle expanding / contracting items as expected.

For instance, a typical use-case would be to allows clients (User's of the API) to handle persist the expandedListItems at the application level in redux state (e.g. via refs to tree.state.expandedListItems on, say, componentWillUnmount), and be able to pass the persisted expanded list items as the initial expanded list items, and have the Tree function as expected from there on, and rinse and repeat.

Currently, in order to expand the tree to a given node(s), using expandedListItems requires User's to manage the state of the Tree's expanded / contracted nodes completely, which I can't imagine would be desirable.

[efeminella]

Just an FYI, as a work around to the above use-cases, one can simply set state on the Tree explicitly, rather than pass in expandedListItems as props.

class SomeTree extends Component {
  componentDidMount() {
    // set expandedListItems tree state from props; e.g. redux store, etc.
    this.tree.setState({expandedListItems: this.props.expandedItems});
  }
  componentWillUnmount() {
    // persist expanded items to state; e.g. redux store, etc.
    this.props.setExpandedItems(this.tree.state.expandedListItems);
  }
  render() {
    const {tree, select} = this.props;
    return (
      <MuiTreeList
        ref={el => { this.tree = el; }} /* ref to tree */
        listItems={tree}
        handleTouchTap={select}
        contentKey='name'
        listItemIsEnabled
        useFolderIcons
        />
    );
  }
  static propTypes = {
    tree          : array.isRequired,
    select        : func.isRequired,
    expandedItems : array
  }
}
export default SomeTree;

This approach will result in the desired behavior with no side-effects, but is not quite ideal as it results in mutating the Tree's internal state, and also requires implementing components as classes to implement life-cycle events, thus, stateless-functional components can not be used.