Fork me on GitHub

@tony.kay I am using pathom/new-parser to create a parser, does it add the env plugin by default or do I need to add it explicitly ?


(pathom/new-parser config 
    [(attr/pathom-plugin all-attributes)
     (form/pathom-plugin save/middleware delete/middleware)
     (datomic/pathom-plugin (fn [env] {:production (:main datomic-connections)}))
     (blob/pathom-plugin bs/temporary-blob-store {:files         bs/file-blob-store
                                                  :avatar-images bs/image-blob-store})]
     (blob/resolvers all-attributes)


I assume you are referring to com.wsscode.pathom.core/env-plugin or com.wsscode.pathom.core/env-wrap-plugin, however to use both of these I will have to provide static values. I need something where I can access the :pathom/context in each invocation of the parser.


If you’re looking to see something throughout the call of all resolvers, then adding to env is the approach. If it is something that came from the client but was targeted at a single resolver (i.e. parameters on a query prop) then copying it over to the env map at the plugin layer will ensure you see it everywhere.


can you point me to an example on how to copy it at the plugin layer. Bcoz as I understand I dont have access to the params at the plugin layer.

Jakub Holý (HolyJak)09:05:40

The pathom context is in the existing env, likely under the :ast key. Just print it out and explore


I saw this on twitter, and it is a worthwhile read: I think this is a great reminder that not every problem is a nail to be hit with your hammer. 🙂

✔️ 4

I’ve been seeing things like this being mentioned as “another” way,


I’ve read this a couple of days ago, and while he does have a point, I think he’s missing a crucial benefit of react-like models: ease of reasoning.


To be honest I'm not certain that there isn't a way to maintain ease of reasoning while still using the above the approach? But there's a definite benefit in that we already know how to do that with the react-like models.


Oh, I’m not implying that I think SPA’s are fundamentally flawed somehow. I think that’s where things should go. That said, React isn’t the only way to do it, and the vanilla js-land way of doing it has gotten really twisted in certain ways. Personally I agree with the whole server-side rendering complaint. I’ve never personally found it at all sane to do that. If Om Next didn’t have the code for it already, it wouldn’t be in Fulcro. But I am glad to have isomorphic operation. That turns out to be an interesting case where the ability to run things in the JVM does come in handy. Also, I agree that building your common business website as an SPA instead of just using a website builder is usually a mild form of insanity. But, if what you’re building is a thing that should behave more like a desktop application for the web, then an SPA makes a lot of sense. What I liked about the article was that it is challenging us to think about what we use our tools for…I’ve seen it over and over again that people will choose a tool “because the know it” or “because it looks cool” and not really think through the long-term implications.


Does RAD generate mutations for crud for the different entities, I am looking for simple crud mutations, given an :id, the entity is deleted, or a new entity is created etc


How do I trigger a generated mutation from the parser. I have included the save-middlewarewhich in turn uses the (datomic/wrap-datomic-save). This uses the ::form/paramsto save any deltas in datomic. How do I call it from the repl -

(parser {::form/params
           {::form/delta {:farm/id #uuid "5eb40c62-164d-481a-bb53-463e1e3d8ad2"
                          :farm/name "New Farm"}}}
The above does not yield any result.

Jakub Holý (HolyJak)17:05:34

There must be an example in the RAD demo?


going through the rad demo codebase, lets see what I can find