With the current hierchical datasource, a simple file system type use case can not be supported... or an email service with nested folders.  e.g. a folder might have subfolders OR files... or and email folder might have emails OR subfolders.  Its is rare that you would ever know how many nestings there are ahead of time.


If the Node object provided some form of a type field/string/object/function to describe the corresponding model that would be very valuable. the library could instantiate the appropriate type at run time. This would also be useful for templating where a simple switch statement could be used to present templates based on the type. I imagine there would be challenges with the datasource fetch as there could be multiple service endpoints a cross the children of a node based on the number of child types. You might consider solving this by changes children from an array to an array of arrays. And you could populated children with the number o possible types, each type having its own endpoint. Anyway it's a pretty common use case so please forward to product management for roadmap consideration. I'd probably consider that #1 on my list.