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)

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})

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 https://www.youtube.com/watch?v=MnvtPzEH-d8&list=PLZdCLR02grLqSy15ALLAZDU6LGpAJDrAQ

The Maximal Graph…a must-see

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.

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?

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.

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.

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

https://vvvvalvalval.github.io/posts/2018-07-23-datascript-as-a-lingua-franca-for-domain-modeling.html

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

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

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

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