Fork me on GitHub

initial-state has to come down from the root. But when a component is created by a dynamic router there's no path down from the root. Is there a standard way to call the initial-state function from the router? Or should I be thinking about this another way?


Thinking about this, I think the idea would be to put the component somewhere in state, off some other component, even if it doesn't need to be anywhere (as it is working fine at the moment, and it is only referenced in the router).


Oh - it is loaded - so the post-mutation would be a good place to put the initial state - that should work...


And did work :)


you can also use pre-merge instead of the post-mutation, I highly recommened you check it, while initial-state just runs on app start, pre-merge runs every time the component is merged (that includes when its created due to data load)

✔️ 4

Same thing with fulcro-garden-css. If your CSS is behind a router, and that route isn’t active during generation, you’re not going to get the CSS.


If I write a new component and the CSS doesn't work then I put this as the attributes of the top level div


(inj/style-element {:component this
                    :react-key :root/global-property})


Can't wait to see Fulcro get mentioned in more than one talks in the Conj :D

fulcro 16
Piotr Roterski12:11:59

Tom’s Fulcro talk is scheduled for today but I’m not sure what other talk could mention Fulcro… please let us know here if you notice any 🙂 BTW videos from day 1 are up;list=PLZdCLR02grLqSy15ALLAZDU6LGpAJDrAQ


The Maximal Graph…a must-see

👀 8

I have :player/cards which I initialize with [{:id "h5"}] , resulting in an initial state like: :player/cards [[:card/id "h5"]]. I then try to add a card through a mutation:

(defmutation deal-card [{:deck/keys [id cards]}]
  (action [{:keys [state]}]
    (let [random-card (rand-nth cards)
          new-deck (remove-from-deck cards random-card)]
      (swap! state #(-> %
                        (assoc-in ,,, [:deck/id id
                                       :deck/cards] new-deck)
                        (update-in ,,, [:player/id 1
                                        :player/cards] (fn [x] (conj x random-card))))))))
Where random-card is something like {:card/id "s10"}. My issue is that this results in the first card being an ident vector while the second one is a map: [[:card/id "h5"] {:card/id "s10"}] . What gives? Is it because I should be using merge-component! or something? I'm fairly new to Clojure and Fulcro, this is just a learning project.

Björn Ebbinghaus14:11:50

Yes, you should use merge-component with targeting. I assume you want to remove the dealt card from the deck. There is a function for that. Try this:

[com.fulcrologic.fulcro.algorithms.merge :as merge]

(let [random-card {:card/id "s10"}]
  (swap! state
    #(-> %
       (merge/merge-component Card random-card :append [:player/id 1 :player/cards])
       (merge/remove-ident* (comp/get-ident Card random-card) [:deck/id id :deck/cards]))))


Sweet, thank you.

Björn Ebbinghaus14:11:01

Although.. When your random-card is already in the Database (Because it is in the deck). You don't need to merge the card..

(swap! state
  (fn [s]
    (let [random-card-ident (rand-nth (get-in s [:deck/id id :deck/cards]))]
      (-> s
        (targeting/integrate-ident* random-card-ident :append [:player/id 1 :player/cards])
        (merge/remove-ident* random-card-ident [:deck/id id :deck/cards])))))


Ah, I haven't got to targeting in the docs yet. I suppose this is the proper way to do it, but using merge would dedupe the operation anyway, producing the same result?

Björn Ebbinghaus14:11:47

Yes it would. It would merge the "new" card with the card already in the db.


Because you are in a mutation you are dealing with normalised data - not the place for maps! It is the place for idents. It is also not the place where you would be using merge-component! That function is for when you are in the UI layer and have denormalised data - basically a map - and want to put it into your app state, where of course it will be normalised: arranged in terms of idents.


Okay, so why is using assoc-in and update-in not correct in this case? I guess it doesn't perform some normalization logic? But several of the mutation examples in the docs use these functions.


They are correct to use. merge-component! is for the special case situation where you need to import some data into app state. I was answering your question about whether merge-component! should be used.


Then for my original question in this thread, why did I not get the desired result there? Why were the cards inconsistent types?


Getting {:card/id "s10"} rather than [:card/id "s10"] usually means you haven't defined an ident properly in the Card component. It will be something like that...


Yep, found it, that's what it was. Thanks very much for the help. Made some progress today.

Tamizhvendan S14:11:01

Hi @tony.kay, I just saw your video “Fulcro RAD Preview”. It is impressive and thanks a lot for your hard work on Fulcro!. I would like to know your opinion on using the library to define the domain models (metadata) instead of the one that you demonstrated in the video. Have you consider this library while developing yours? Are there any drawbacks?


Ah, when I started working on this (4 days ago) I remember that there was something like this out there, but could not remember the name…I knew someone would remember for me 😄 It would be awesome if I could leverage that for the schema/database stuff, and then just add extra attributes for the RAD stuff…will definitely take a look. Thanks!


Hm…unfortunately it looks very entity-centric. That line of thinking just isn’t as powerful as what I want to do…I’ll look deeper, but I have my doubts already.

Tamizhvendan S08:11:16

I agree. However the idea of “Query-able” definition of metadata in hodur is really worth pondering.

Tamizhvendan S08:11:18

Inspiration behind that idea.


I’ve read that, and that is what I’m doing….just not doing it with Hodur 🙂


If you see some advantage to putting it in Datascript that I’m not seeing, my ears are open, but open maps seem to work just fine, have no dependencies, are navigable, are plainly visible, can be composed into structures to make a “database” of record, can be easily serialized and processed, etc.


I’ll probably drop defattr and defentity in favor of just all maps with spec’d keys

Tamizhvendan S05:11:00

Yup. I do feel open map over DataScript would be a better option

Tamizhvendan S05:11:19

I am currently working on a project, where we are getting the entities & attributes from JDBC metadata API and decided to take the open map route

Tamizhvendan S05:11:00

It’s in a very early state, will share the results and its structure probably in a week


Make sure you watch “The Maximal Graph” By Wilker Silva at the conj. Talk is at 1pm today. A must-see.

👍 44
parrot 12