Closed zhoudxnz closed 7 years ago
The library should be tested to work with numbers too, there is not reason for a note to not be a number.
I had a deeper look at this and I decided I won't fix the issue as I don't think numbers should be used as object identifiers.
Here are the reasons why:
Object.keys
always returns an array of stringsTo me is seems that, although numbers are accepted in the syntax as keys identifiers, the standard library is pushing towards strings.
I'll be happy to revisit this decisions if further interest in this arises.
Fair enough. It is easy to work around anyway. I just have to add a prefix to force every node name to a string.
I ran into the same issue and came here to report it. This is a great library and clearing up this ambiguity would make it even better!
My nodes don't have natural names so using numbers for the keys makes the most sense. Why not use a ES6 Map
throughout and allow arbitrary types for all keys?
@kronick Good point.
That's can be the sweet spot. Have the ability to pass Map
to all the methods.
I did the following in my code and expected to get a path
[1, 2]
. But it returned null.Turned out it doesn't like me using numbers as the name of a node. It would be good if the library checks and raises an error, or make it work.