Fork me on GitHub

Hi - new user getting to grips with Fulcro I've loaded up the latest version of the Fulcro Template and got it up and running with Intellij I've noticed that some of the functions from fulcro.ui-state-machines, e.g. begin! cannot be resolved by Intellij and are highlighted yellow e.g. uism/begin! cannot be resolved, but uism/begin can What I understand is that the "begin!" form is defined using a macro >defn which is itself defined in fulcrologic.guardrails.core So it appears that intellij (or Cursive?) cannot follow this relationship and thus says "unresolved" ..Is there anything I can do about this or do I just have to live with it for now until some future IDE update/fix is found? As far as I can tell the code still runs and operates so I'm also assuming this is just a visual inconvenience.. Thanks


Cursive can resolve macros for your like this:


Text version: Call the lightbulb menu with alt+enter on something that isn't resolved like >def or >defn (and also all the rad macros) and choose resolve .... as >

❤️ 1

Fantastic - that fixed it! I'd seen this trick in the Fulcro videos but didn't think to apply it to the source files.. :man-facepalming: Thank you for the clear and detailed response.


sure thing, have fun coding!


@pt.roterski a continuation to the from a few days ago... I'm noticing something a little odd. My project is based on the, except I've moved timezone setting out of the seed! function and into start, and added a boolean arg to start so seeding can be skipped. I also configured my [ :xtdb/index-store :kv-store :checkpointer] to create DB checkpoints and verified that to be working. See comment lines in snippet. In my own project I confirmed that all of the seeded data does exist in the database by running the query directly against the node using the xtdb api. Does this look like a bug to you? The parser only "sees" the ID fields from the models after a reset, although the data does exist in the DB.

Piotr Roterski14:11:39

Thanks for the report @UPWHQK562. Indeed something odd is happening with latest version and I’ll try to debug and fix when I get a chance (I’ll try today in the evening)

🙏 1
Piotr Roterski10:11:08

@UPWHQK562 I haven’t used xtdb checkpointing myself yet so I’m not sure if I would be able to help you with that, but would you mind sharing your xtdb config map? If you use in-memory storage for I’m guessing it might lead to some data loss on restart - doesn’t checkpointing restore only index store ? :thinking_face: You could try calling before and after restart to quickly glance if something changed there.

Piotr Roterski10:11:31 see this “important” section there that might explain confusing behavior: > The tx-log and document-store are considered ‘golden stores’. The query indices can, should you wish to, be thrown away and rebuilt from these golden stores. > > Ensure that you either persist both or neither of these golden stores. If not, XTDB will work fine until you restart the node, at which point some will evaporate, but others will remain. XTDB tends to get rather confused in this situation! > Likewise, if you persist the query indices, you’ll need to persist both the golden stores.


@pt.roterski You are correct. Thanks. I coincidentally switched over to using Postgres for the doc/tx stores yesterday, for performance reasons, and it appears the issue I reported above is corrected by that as well. That makes a lot of sense. Sorry! 😕 I'm still making sense of this modular DB landscape. I previously had configured just the index store to use something other than the in-memory store - trying to keep things as simple as possible so the learning scope is minimized - but this is checkpointing issue is where using persistent data stores became a necessity.

Piotr Roterski13:11:02

no worries 🙂 I’m glad that you managed to get this working and I’m happy to help (and coincidentally learn about checkpointing) 🙌


For what it's worth, the checkpointing config I'm using is the basic one suggested in the docs:

:xtdb/index-store {:kv-store {:xtdb/module "xtdb.rocksdb/->kv-store"
                                 :db-dir "/home/sheluchin/repos/proj/tmp/rocksdb/index-store/"
                                 :checkpointer {:xtdb/module "xtdb.checkpoint/->checkpointer"
                                                :store {:xtdb/module "xtdb.checkpoint/->filesystem-checkpoint-store"
                                                        :path "/home/sheluchin/repos/proj/.backups/xtdb/"}
                                                :approx-frequency "PT1H"}}}

👍 1

When using Pathom from CLJS, pretty much the only option is to set the correct mutation symbol, correct? Something like:

(ns app.mutations ...)

(defmutation fulcro-mut ...)

(pco/defmutation pathom-mut [...]
  {::pco/op-name `app.mutations/fulcro-mut}


yes, I usually like to separate the Pathom Mutation from the client mutation (separate namespaces) because I conceptually think of them as different layers


I do also rename most of my mutations, giving them more semantic names (similar to what we do for attribute keywords)


in this way, I usually end up with 3 different names: 1. the full name for the pathom mutation (eg: com.acme.graph.domain/some-mutation) 2. the full name for the fulcro mutation (eg: com.acme.ui.domain.some-view/some-mutation) 3. the semantic name for the mutation (eg: acme.domain/some-mutation) Then, in the remote part of the Fulcro mutation I make it rename to the semantic name before sending to the server

👍 2

just one tip, if you dont want the semantic naming, your example could be reduced to:


(ns app.mutations ...)

(defmutation fulcro-mut ...)

(pco/defmutation pathom-mut [...]
  {::pco/op-name `fulcro-mut}


(on the op-name you don't need to say the ns, since the backtick will expand the symbol to the current namespace)


Ah, gotcha, thanks 🙂 In some ways it would be easier to keep pathom mutations/resolvers together with the rest of the database code in the same file, so I'm leaning your way.


Though, not sure Tony would agree 🙂 > Pathom lets you override the symbol on the server (via a `::pc/sym` options) but it is still a good idea to use the same actual namespace (via clj/cljs pairs or just a CLJC file) to "co-locate" the mutations for easier code navigation.


its a stylist choice in the end, so use whatever feels better for you 🙂

👍 1

For me it's about ease of navigation. 100000 lines of code and you'll rather appreciate that you can just go to the ns of the symbol instead of having to remember some additional convention. Onboarding new people is also a concern if you stray from the "obvious"

👍 1