[Memo] `parentId` could be hidden from the user-facing API

[probablycorey]

This might require a bit of discussion since I might not fully understand the API.

createDirectory and rename have a parentId argument. This works fine, but it requires path parsing and a call to lookup the fileId on the user side. Would it make more sense to pass a path (instead of a name), parse the path, and lookup the file's parentId on the Rust side?

[as-cii]

We assumed that you would have the file ids at your disposal during rendering your tree interface, since they are available on the entries. Are you performing renames in other situations where you don't have the file id readily available? It seems like the id-based approach is more general. It covers situations where you have a file id, such as during a drag and drop, while still allowing a lookup on the path in other cases. Are you hitting any cases where the id based approach saves effort, or are you always using paths?

[probablycorey]

We assumed that you would have the file ids at your disposal during rendering your tree interface, since they are available on the entries.

We don't do this now, but that makes a lot of sense. We use paths like ids now, but I'll try thinking about passing FileEntry objects around instead.

[nathansobo]

We've actually decided to go ahead and hide file ids from the public API. Buffer ids will continue to exist, but file operations will be mediated through paths.