in the fulcro-rad-demo readme it says - clj -A:dev:f3-dev:rad-dev:datomic , however there is no alias named f3-devand rad-dev in the deps.edn, maybe I am missing something, or is it just an old reference ?

@tony.kay Do you want to have a look at https://github.com/awkay/workspaces/pull/3 ?

Well, that worked like a charm with the floating root with hooks from the multi-root-card example, @tony.kay 🙂

@zhuxun2 You said "If I were to write a function to retrive all root level keys given a EQL (which should have been trivial), the implementation would be a few lines unnecessarily longer since I need to consider those ref-type attributes."

I think EQL is not meant to be processed directly, maybe you can instead process the AST version of the EQL query

@myguidingstar I agree that you normally wouldn't do that in your app code, but what about tooling? In particular, editor plugins?

Sound small, but not for something this infrastrutral

by AST, I mean EQL's AST that you get by calling (p/query->ast [:your {:eql [:query]}), not Clojure syntax AST managed by Clojure reader

also: "If I am using Emacs to manually write a test example given an EQL, I am doing lots of unnecessary work changing brackets into braces and splicing sexp's."

I know what you meant. 🙂 My point is not that the current syntax is impossible to work with, but that it's not optimal and intuitive. Others confirmed that this was more due to historical incidence

maybe the helper function pc/data->shape can help you with that?

My point was that the current syntax seems to be arbitrarily one of the sub-optimal syntaxes, and they chose this one mostly due to Datomic pull syntax

I'm just trying to find some workarounds for your pain points

Thanks for that 🙂 I am actually more trying to understand "why is it that way" rather than "how to fix it".

I can definitely work with the current syntax no problem, just a few more keystrokes and a bit more mind gymnastics which I will get used to anyway

I was just afraid that I missed something intrinsically nice about this syntax, and that's why they chose it, but I guess that's just not the case

I am familiar with the fact that underlying EQL, it's all represented interally as AST anyways and you could really use any facade for it

@souenzzo In #datomic brought up the similar point in my repost thread

It's pretty easy to make this in fulcro I imagine. I don't see much use for the alternate syntax, but maybe I just haven't seen the killer example. If you want, you could write the parser and put that as a replacement hook in fulcro for local development.

Maybe even have it as a fulcro plugin for a wider audiance.

@jatkin True. It's not something I would do though. As the value proposition is not large enough to break the community standard. I'm sure at this point the datomic pull syntax has burnt into the datomic/pathom/fulcro eco-system and I'm really just going to confuse whoever reads my code if I insist doing that

@jatkin But yes, maybe as a experiment I should write a plugin, see if people like it

I see. I don't find any of your arguments invalid 😄 I think Clojure community have two alternatives to EQL: Qlkit and D2Q

https://github.com/forward-blockchain/qlkit https://github.com/vvvvalvalval/d2q

On a side-note, my map syntax is not without its drawbacks. The fact that it's using a symbol "" as a val placeholder means that the whole query has to be quoted (which in most places in my app doesn't matter but I imagine it's annoying sometimes). I could use the number literal "1" instead but that's less clean. I could also have they symbol "" referrable in my library but it would make the plugin less friendly to use and prevent the user from using their own "_" symbol.

Since clojure doesn't have "t", a single digit number might be the literal with the smallest profile

I think a better idea, which might be more practically useful for current fulcro users is a little helper function called example->eql that turns an example of a possible return value into its corresponding eql

You could just have a :refer [_] where (def _ nil || :ns-keyword/whatever) is available.

Using my previous example. It works like

(example->eql
    #:user{:id "xxx"
           :name "aaa"
           :email "bbb"
           :projects #:project{:id #uuid "xxx"
                               :name ""
                               :start-date #inst "xxx"
                               :end-date #inst "yyy"
                               :comleted? true}
           :contacts #:user{:id #uuid "xxx"}})
=>
    [:user/id
     :user/name
     :user/email
     {:user/projects [:project/id
                      :project/name
                      :project/start-date
                      :project/end-date
                      :project/completed?]}
     {:user/contacts [:user/id]}]

This way, you get most of the structural benefits of the map syntax (sans the cleanliness of "_"), while being minimally confusing to your colleagues

Having the example structure in the :query field of defsc makes it just a bit easier to visualize e.g. what ":projects" looks like when sent in as a prop. Not much, but just enough to make me happier one defsc at a time 😄

That being said, you normally don't do nested EQL in your defsc. But still, visualizing the exact shape of [:user/id {:user/projects (comp/get-query ProjectItem)}] has been a few seconds too long (and uncertain even after triple-checks) for a beginner like me

Compared to {:user/id "", :user/projects (comp/get-query ProjectItem)} in my map syntax

Ok, @souenzzo brought up the com.wsscode.pathom.connect/data->shape function and it seems to serve exactly the purpose of conversion I imagined. (I reposted it here in case anyone missed his post in my thread)