Fork me on GitHub
#fulcro
<
2020-06-18
>
murtaza5206:06:27

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 ?

murtaza5215:06:10

sorry I had missed it

3
tony.kay14:06:07

Did you see thheller’s comment?

Björn Ebbinghaus16:06:27

Yes. It is already fixed

zilti10:06:30

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

👍 3
myguidingstar17:06:25

@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."

myguidingstar17:06:06

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

zhuxun217:06:03

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

zhuxun217:06:38

Sound small, but not for something this infrastrutral

myguidingstar17:06:41

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

myguidingstar17:06:58

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."

zhuxun217:06:16

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

myguidingstar17:06:56

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

zhuxun217:06:46

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

myguidingstar17:06:48

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

zhuxun217:06:37

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

zhuxun217:06:17

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

zhuxun217:06:15

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

zhuxun217:06:16

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

zhuxun217:06:11

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

👍 3
JAtkins17:06:13

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.

JAtkins17:06:01

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

zhuxun217:06:37

@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

JAtkins17:06:46

I do agree though - it is easier to read. Not drastically, but enough to see the difference. Mostly good for newcomers I imagine.

JAtkins17:06:05

Maybe for dynamic manipulation of queries as well.

zhuxun217:06:30

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

myguidingstar17:06:01

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

zhuxun218:06:18

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.

zhuxun218:06:13

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

zhuxun218:06:57

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

souenzzo18:06:08

it's pc/data->shape we can turn that into a eql lib and put it on "docs playground", both on fulcro docs and pathom docs

👍 3
zhuxun218:06:41

@souenzzo Beautiful. Thanks!

JAtkins18:06:50

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

zhuxun218:06:32

Yes! That's what I meant when I said having the symbol "_" referrable :slightly_smiling_face:

zhuxun218:06:22

The downside is of course you can't use it in any context where "" as been registered (like in a defsc where is bound to this, etc.)

zhuxun218:06:27

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]}]

zhuxun218:06:03

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

zhuxun218:06:16

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 😄

zhuxun218:06:10

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

zhuxun218:06:26

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

zhuxun218:06:26

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)