How does 'tree' work?

[nullpaper]

Great library, I'm surprised it's so unknown because it's really good. Thanks for sharing it!

I was looking through the code and saw you're taking a different approach to creating stores in your /tree dir. I assume this is the bit inspired by MST. I tried messing around with this but didn't get very far.

How do you intend for the experimental tree stores to work exactly? It's really intriguing. Keen to learn more!

[onurkerimov]

Hey @nullpaper! Thank you for your interest and kind words. I'm glad that you've found it good!

@xoid/tree was meant to be the experimental "tree of atoms" version of xoid. It was intended to be a version which use function doesn't exist, and not needed. Here's a demonstration:

With xoid:

import { create, use } from 'xoid'
const MyAtom = create({ deeply: { nested: { value: 5 } } }) // AtomTree<...>

const PartialAtom = use(MyAtom, s => s.deeply.nested) // Atom<{ value: number }>

With @xoid/tree:

import { tree } from '@xoid/tree'
const MyAtom = tree({ deeply: { nested: { value: 5 } } }) // Atom<...>

const PartialAtom = MyAtom.deeply.nested // Atom<{ value: number }>

This was actually the initial API design of the main package, however after experimenting for a while, I decided not to follow this path. I noticed that it's currently impossible to achieve type safety for object keys like arguments, length, caller, callee, prototype due to TypeScript's restrictions. TypeScript treats objects as prototypeless entities, however there's no way to have a prototypeless function (in design time). When something is "callable", typescript directly assumes it has length: number and so on.

So the @xoid/tree package is not actively being maintained at the moment but I may revisit it in the future. You're right that it was inspired by MST, also the @xoid/model package (which is again, deprecated) was meant to be used in tandem with it.

Thanks!