Fork me on GitHub
#pathom
<
2019-01-28
>
hmaurer00:01:20

@wilkerlucio totally unrelated to the discussion happening on #fulcro but since we had a chat the other day about the differences with GraphQL: you can provide some data about a node that “doesn’t exist” in any persistence layer and derive more data

hmaurer00:01:22

this seems super handy

hmaurer00:01:04

i.e. when creating a new entity you can query and display derived data, even though the entity hasn’t yet been persisted in the database. This, afaik, isn’t possible with GraphQL

wilkerlucio01:01:55

@hmaurer correct, this is mostly a result of the mindset, there is no real "entity", its just labeled data aggregated in maps, its just available or not, if is you can move on

wilkerlucio01:01:00

but you noted an interesting property that are not obvious and its good to call it out, thanks for the reminder 🙂

hmaurer14:01:57

Hello @wilkerlucio ! If you remember, a couple of days ago I asked you a question after watching your Conj 2018 talk. I had found your SpaceX <-> Youtube example very cool but wondered how one would deal with multiple properties all pointing to youtube videos (i.e. :spacex/launch-video, :spacex/interview-video, etc). The solution for a single property was to use an alias, but there didn’t seem to be an obvious, clean solution to using multiple properties, other than extending the API or structuring it differently. I have had a bit more time to think about it since then, which is why I am writing this now 🙂 As far as I understand, aliases work by, well, aliasing a field in the current “context” (is that the right term). So with your youtube example above, you could alias :spacex/launch-video to :youtube/url, and then youtube resolvers could go from :youtube/url to more information, such as the video title, etc. Now, here’s my issue with this. Let’s say you are in the context of a “space launch” (to stay on the spacex example). This space launch has a :spacex/interview-video property, which contains a youtube URL. You want to fetch more data about that video, so you alias it to :youtube/url and then query for :youtube/name. Now you have a :youtube/name property on the space launch context. But that property isn’t a property of the space launch, it’s a property of the interview. It seems like the property is now on the wrong node. And this creates the further issue that you can’t both get the youtube video name for the interview AND the launch video. Wouldn’t it make more sense to have a sort of join/alias hybrid? Let’s say I would write {{:spacex/interview-video :youtube/url} [:youtube/name]} (made up syntax). This would create a new “context” with :youtube/url within that new context set to the value of :spacex/interview-video. You could then continue to explore the graph from there. Right now I only thought about the one-property use-case, but perhaps it would make sense to be able to pull as many properties as you wish from the parent into this new context.

hmaurer14:01:17

What do you think? Would this make sense? Or am I ranting while missing an obvious issue?

hmaurer15:01:19

TL;DR; with my limited understanding of Pathom using an alias for the spacex example you gave feels like a hack; you end up with properties on wrong entity/node.

wilkerlucio17:01:58

@hmaurer yes, if you have multiple connections then having a join for each makes more sense, that was mostly a case that I wanted to show people whats possible when there is no ambiguity, but in the spacex case, since a video might have more than one relationship to a video, its better to make each a separated join to remove ambiguity

hmaurer19:01:40

@wilkerlucio what I am wondering is whether you could have this ability at query time, instead of having to extend the API, if that makes sense

wilkerlucio19:01:16

I don't think its a good idea to do it at query time, starts to add a lot of complexity while we already have something that works and its consistent, I believe you can do something like this yourself writing plugins, but I don't see that been a core feature at this stage

👌 5
wilkerlucio19:01:29

I like to avoid adding features as much as possible at this stage, keeping it simple will make it evolve better, so unless we found some situation that really can't be accommodated then would be a time to think more about it 😉

👍 5