Pull API / Wildcard Support

[becomingbabyman]

Re entity.get(“*”) can you talk a bit more about your use case? I ask because there are a lot of ways to go about implementing this. The underlying datalog DB does support patterns similar to this, but they have different tradeoffs when connecting them to React and doing the live updating. At the moment we treat entity.get(“specificAttribute”) as a whitelist, so we only cache data and rerender components when those specific attributes change. If debugging is the issue we just released custom chrome formatters so you can log out entities and inspect all their attributes in the console. We’re also working on a chrome extension to read and eventually write to the database from a GUI. If it’s something more like GraphQL that you want, we’re talking about exposing the pull syntax which is essentially GraphQL. I’m hesitant to just expose an entity.get(“*”) function since that would have severe performance costs in the context of React if used naively, and it’s ripe for naive use since it’s probably the first thing a new developer would try.
@smothers

re: entity.get("*"), this is roughly what I'm trying to do.

const onDragEnd = (event) => {
  if (event.condition) {
    transact([{
      entity: {
        name: baseEntity.get("name"),
        component: baseEntity.get("component"),
        width: baseEntity.get("width"),
        height: baseEntity.get("height"),
        ownerId: baseEntity.get("ownerId"),
        // +maybe some other props I don't know about? and those could vary depending on the entity too.
      }
    }])
  }
}

So again this is just querying the database directly, no need to subscribe to anything. but on the other hand if it is only exposed when querying the database directly, that could feel a bit inconsistent?

I'm actually not sure yet I will need it to be this dynamic, so hardcoding the props is okay in the meantime. but it was something I thought would be there and went looking for in the docs.

Cheers.

Originally posted by @MioQuispe in #80 (comment)

[becomingbabyman]

@MioQuispe I think exposing the pull API would give you what you want.

E.g.

const id = 123
const [client] = useClient()
client.pull('*', id) // => { a1: 'v1', a2: 'v2, ... } 

Additionally, if we want to make pulls reactive we can also expose the API over a hook directly

const id = 123
const [data] = usePull('*', id)
data // => { a1: 'v1', a2: 'v2, ... } 

To better understand which APIs we should prioritize can you talk more about your use case? Why do you want to copy all attributes of one entity into another entity instead of referencing the original entity?

[MioQuispe]

@MioQuispe I think exposing the pull API would give you what you want.

E.g.

const id = 123
const [client] = useClient()
client.pull('*', id) // => { a1: 'v1', a2: 'v2, ... } 

Additionally, if we want to make pulls reactive we can also expose the API over a hook directly

const id = 123
const [data] = usePull('*', id)
data // => { a1: 'v1', a2: 'v2, ... } 

To better understand which APIs we should prioritize can you talk more about your use case? Why do you want to copy all attributes of one entity into another entity instead of referencing the original entity?

Cool! Yeah that would solve it. I don't actually need the reactivity here.
Im just trying to clone an entity (except for the id) to create a new one essentially. Maybe I should look them up from a schema tbh, but I havent thought everything through yet.

[becomingbabyman]

Hey @MioQuispe. I looked into this and it involves converting from EDN (the Clojure data format) to JSON. This is a feature we'd like to add, but it's a bit more complicated than just exposing one of the DB APIs. At the moment we make a bunch of assumptions when going from JSON → EDN and never go from EDN → JSON. Going in reverse would require precisely tracking all the assumptions and mapping them to the reverse transformation. Since this is not high on our priority list it will probably be a while before we get to it.