This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-17
Channels
- # aleph (4)
- # announcements (2)
- # babashka (85)
- # beginners (136)
- # calva (72)
- # clj-commons (32)
- # clj-kondo (7)
- # cljs-dev (3)
- # clojure (117)
- # clojure-europe (38)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-uk (4)
- # clojurescript (19)
- # conjure (38)
- # core-logic (2)
- # cursive (10)
- # datalevin (1)
- # datalog (1)
- # datomic (6)
- # events (2)
- # fulcro (16)
- # google-cloud (5)
- # graphql (10)
- # gratitude (3)
- # hugsql (3)
- # luminus (5)
- # membrane-term (12)
- # missionary (2)
- # nextjournal (5)
- # off-topic (3)
- # pedestal (2)
- # polylith (7)
- # portal (3)
- # re-frame (6)
- # reagent (26)
- # reclojure (8)
- # releases (3)
- # reveal (5)
- # shadow-cljs (14)
- # spacemacs (20)
- # sql (3)
- # tools-build (3)
- # web-security (9)
Given that Pathom3 natively supports Foriegn Resolvers, would there be interest in having a Pathom remote that just takes a pathom boundary interface? This way pathom resolvers on the client side could further modify/reshape/etc data returned from a foreign pathom system.
yup, that's right, this case is one that was my head for a long time 🙂
you can even push it a bit more, have one in the renderer frame, talking to another one in a web worker, and another being the server, this way you can also handle expensive computations on the client side that don't block the UI
@U066U8JQJ That was my idea, but it seems like it would be difficult to package a webworker as a CLJS library given the current CLJS build tools.
@U6NJBB596 its really not that hard, using shadow-cljs is very easy to make the worker in CLJS, I have done this here in an experiment
the annoying part is just writing the border parts, to make encoding/decoding in every edge, once that is set the rest flows fine
I was looking at the RAD template repo and there were a model and model-rad packages. These seem to be going out of their way to avoid require ing each other, which I found interesting because I had many many many problems with circular dependencies while using RAD, but is this feasible if your namespaces keywords are more complex? One model namespace define attributes like :account/email and the other one refers to the same attribute without requiring the other NS. But I used full namespaces (i.e. namespace for attribute keywords was the namespace they were defined in) and I had tons of problems with attributes in 2 namespaces referring to each other.
What’s the best practice here? Do I just resign to having short namespaces on attributes? I hate writing out :com.something.somethingelse/kw because I cannot have a require alias because of circular deps. Do I make a bunch of empty namespaces just to have short aliases for long ns names? Having collidable keyword namespaces like :account/email isn’t in line with the attribute and pathom idea where you have a web of globally recognizable attributes.
So, the template is using the structure that I use in my own projects. The demo is out of date with respeect to this and will lead you into circ problems.
So, newer Clojure is supporting aliasing for just aliasing sake, which will help with the “typing problem”.
In terms of putting things on the attributes: if you co-locate code on them, you are going to have to be careful. If you only put data on them, then you should not have problems in general. If you really want code on an attribute, then consider using a multimethod, since those can be declared in a ns by themselves, and then implemented elsewhere, allowing their use in the attributes without an issue.
From my perspective the model ns is about code the implements logic around the attributes. So, they should have access to the declarative data in attributes (can rquire model-rad), but of course not vice-versa. I put mutations, resolvers, and helpers in model.
I sometimes do create other “leaf” nses (e.g. lib-like code for things like formatters) to be used directly on attributes, but given that you can set style keywords and just install those into RAD itself, it dramatically reduces the need to put code on the attributes.
If you’re using those longer nses on your attributes, then you should rename that ns from model-rad to the namespace of your package: com.something.somethingelse so that you can treat the model nses as your source for aliasing. I’ve tended to use single-segment namespaces in my projects because I don’t expect collisions, but I perfectly understand a desire to be more rigorous. My projects at the moment do not really plan on using a federated public network of data.
Ah I haven’t realized this alias thing existed
that helps so much, not just in this but other projects as well