docs: Add some examples of how you might use leaf

[mikebryant]

Adding some ideas/examples on how things could be used

[zicklag]

Awesome, thanks!

[thepaperpilot]

You suggest potentially having multiple Feed components. Does this mean Feed components would have name and description data inside them, since they can't just use their own NameAndDescription components on the user entity? Or should there be a Feeds component that links to a subtree like recipes? In fact, I kinda imagine all the schemas we write that could even feasibly have other components alongside them, should have a pluralized version that can link to a subtree.

[zicklag]

That's a good point, if there are multiples of something, like feeds in this case, then it'd probably be good to use multiple entities for it in many cases.

That makes sure, for example, that the feed can have an Image assigned, to it, etc.

Side note: If that holds up as a rule of thumb, it'd be good to list basic guidelines like that in this doc, too.

[mikebryant]

You suggest potentially having multiple Feed components. Does this mean Feed components would have name and description data inside them, since they can't just use their own NameAndDescription components on the user entity?

So, I'm imagining that Feed is basically a link that points to say, /social/feed. The Entity at /social/feed describes the feed itself, and all the entities at /social/feed/bar123 are what's on part of the feed.

Or you could have, on your profile, a Feed that points to /social/main, and another that points to /social/niche-interest Each of those entities then has the description

[zicklag]

Oh, yeah, that works, perfect. :+1:

[thepaperpilot]

I'd like to note that the "Add a pluralized version that links to a tree" would probably mostly be used for entities describing something - as opposed to actions (like replying), where you could just add another action. e.g. you don't reply to a message with a link to a subtree of replies, you just reply multiple times.

Perhaps you could also generalize the pluralized version, so you don't actually need to define a plural component schema for every "pluralizable" component. Instead you could just have, say, a EntitiesOfType component that defines the subtree as well as the common component between them. Although tbh that almost feels redundant, since you could just look at the components on each entity already. Honestly I kinda wonder if we need to have components pointing at the subtrees at all - perhaps if you're looking for a user's recipes, you just look at all entities under that user for any with the recipe component? Sure it could take longer to traverse, but it would generalize to any component the user doesn't make an index / subtree for, and it would catch any that are not in the expected location.

[mikebryant]

I think what I'm imagining here isn't that Feed links to a subtree where you'll find other Feeds, as it were. You'd expect say, Notes, Articles, I've followed Bob type things underneath it. The things under it wouldn't all be the same type, they're all "things that might appear in a Feed", and could conceivably not have a common set of Components.

perhaps if you're looking for a user's recipes, you just look at all entities under that user for any with the recipe component? Sure it could take longer to traverse, but it would generalize to any component the user doesn't make an index / subtree for, and it would catch any that are not in the expected location.

I guess if you want to do that you can still just traverse the whole thing? :) But I could imagine say, I want to have a gallery of photos - but I don't want every single photo to appear on the timeline, only ones I want to highlight? And have people have to go specifically look at the gallery if they want to browse everything