Fork me on GitHub

@tony.kay does fulcro automatically consider size-2 tuples as idents when using links? It appears that when i use a link in a query, i get a bunch of nils instead of a raw vector of tuples that i expect.


@levitanong I'd have to see an example


@tony.kay will do, will come up with a minimal case within the next few days.


Fulcro 2.4.0 is officially released. Includes new alpha.dom with hiccup style concision, localized-dom with fulcro-css integration, and some bug fixes to the alpha i18n. NOTE: You must exclude fulcro-css from your deps, since it is included now.


The new dom stuff is totally awesome will upgrade tommorow I need dis!


How does the localized DOM works btw if you refer to a class that has not been defined?


@mitchelkuijpers The localized stuff just uses the rules. The overhead of verifying you used something that is defined isn’t worth it…so, use it, and it’ll generate a name

Spencer Apple23:03:13

Hey I was just curious, if I wanted to create a datomic entity and reference that entity from a different entity, do I have to do that in the same server mutation? Assume timeframe/new and dashboard/new each create datomic entities that correspond to the parameters passed down in the mutations. I have been trying to do something along these lines:

(let [timeframe-id (prim/tempid)
      dash-id      (prim/tempid)
      timeframe    {:db/id timeframe-id
                    :timeframe/other-field 1}
      dash         {:db/id dash-id
                    :dashboard/timeframe timeframe-id}]
  (prim/transact! this `[(timeframe/new ~timeframe)
                         (dashboard/new ~dash)]))

Spencer Apple23:03:39

I think the issue is in the second mutation when creating the entity fails because the tempid doesn't exist in datomic

Spencer Apple23:03:22

I thought though according to that fulcro would resolve the tempids between mutation executions


Just pushed another update to the Developer’s Guide with better documentation on co-located CSS and the new localized DOM:


@splayemu The documentation is correct, but your example sent one transaction, not two.


the tempid resolution happens between transactions, not calls in a transaction


If you want auto-resolution (which happens in the client), then you’d have to split them into two calls to transact!, which would be two round trips. I would suggest that you instead make a composite mutation when there are these kinds of local data depenencies and use it instead so the server can resolve it all at once (e.g. send both timeframe and dash as parameters to a single mutation).


From my perspective, it looks like a “dash” always has a timeframe. I’d model it that way:

(transact! this `[(create-dashboard {:db/id ~dash-id :dashboard/timeframe {:db/id ~timeframe-id :timeframe/other-field 1}})])

Spencer Apple23:03:39

@tony.kay Thanks for getting back to me, I think in the long run I will put them into the same server side mutation. I split up the transact!s for my personal understanding, but the auto-resolution still isn't happening. I don't have any client side state storing the tempid, but that doesn't matter right? It will also auto-resolve the tempids in the transaction pipeline?