Clojurians Log v2
fulcro
Is there a relatively straightforward way for :will-enter to pass data to the component?
@zilti sorry for late response; :initial-state applies only once, on the app startup, to form the initial state, so it won’t affect any changes done in :will-enter; i assumed you asked whether there’s something easier than making a custom mutation and transacting it from dr/route-deferred, which is always an option; swap! should also be done in dr/route-deferred callback fn
Oh, I see! Yes, that makes sense, I think I will use swap! inside route-deferred then in that case. Thanks!
Well, that did not work... I tried it like this:
:will-enter (fn [app params]
(dr/route-deferred [:component/id ::CompanyRegistrationForm]
(fn []
(swap! (::app/state-atom app)
assoc-in [:component/id ::CompanyRegistrationForm]
(company-registration-form-prefill params))
(comp/transact!
app
[(dr/target-ready {:target [:component/id ::CompanyRegistrationForm]})]))))ERROR [com.fulcrologic.fulcro.algorithms.form-state:?] - FORM NOT NORMALIZED
@zilti you still have to make a normalized db. I would never swap! on state atom in UI code. ever. It’s just bad practice, and is what mutations are for. Write a mutation that sets the thing up correctly and use that instead. The error is because you’re trying to swap a tree into place where you should have normalized stuff. You could use merge-component! instead of a transaction (which will also normalize the data properly), but beware that will overwrite the entire form with the new data (which may be ok)
Okay. But where do I get the component from? Since I'm in :will-enter there's no component yet, right?
I replaced the swap! statement with
(fa.merge/merge-component!
app CompanyRegistrationForm
(company-registration-form-prefill params))In this specific case, I want to pass URL parameters to the component
Does anyone know if it's possible to somehow print the inactive states of a UI state machine that's in a running application? Only the active state gets stored in the database...
This approach used to work with FC2 (I think). But I can’t seem to get it working w/ FC3 and the new router. Any ideas? https://gist.github.com/njj/8aab3a5208d8a9bb7ebaec388ea6803d
core.cljs:159 ERROR [com.fulcrologic.fulcro.routing.dynamic-routing:185] - com.fulcrologic.fulcro.routing.dynamic-routing/target-ready should route to [:component/id :listing] but there is no data in the DB for the ident. Perhaps you supplied a wrong ident?@njj you did not compose the route in question to root with respect to initial state (or didn’t place the target in state if this was a later stage route). It’s telling you exactly what is wrong: That component has no data in the database.
no, I do not think it is "reserved" in any way
Good, yes, I suspected that a proper :target was missing from the load. I would call the attribute perhaps :listing/current or active or st. along the lines...
@holyjak thats my thoughts as well, basically there are many listings but the user can select which one they are working on - I was thinking of making the component :component/id :listing-details then doing just :listing for the active one, and then :siblings for the others. Naming is hard 😄
It is :)
I see… I’ve made it one step further where I can now see the data loading into listing/id by changing the component in the df/load to be ListingForm and adding {:root/listing {}} to the initial-state but now I’m getting the classic ident ([:listing/id nil]) has a nil second element warning - should my query be something different for Listing? (also I’ve updated my gist for reference)
your ident on a component like that should likely be (fn [_] [:component/id :listing]), not a shorthand
Look at the data in the DB, is anything missing? E.g. :component/id :listing :root/listing? It looks wrong but I cannot point at where exactly :) Where/when do you get the error? Is it because props passed to Listing Form are nil or...?
@holyjak the indicator here is that he’s getting nil for the id, indicating he’s using :ident [:component/id :listing] instead of what I said…there is no :component/id prop in his initial state
but he’s got a singleton from the naming, which does not need to have an id in props…that’s just pointless overhead. But you have to use a lambda to get a constant for an ident
the other two notations are shorthand that always try to get ID using something from state
I got confused b/c the Listing component already has :ident (fn [_] [:component/id :listing]). But you were perhaps speaking about the child component Listing Form, that currently has the shorthand :listing/id, right?
(swap! (::app/state-atom app) assoc-in [:comp/id :smth :ui.route/data] data) as long as you don’t need re-render or transaction semantics i believe it’s safe to do whatever you need with the state
@njustice It's weird to me to have the singleton component Listing with a non-static route and loading a single non-static child. I'd merge the 2 components into one with the shorthand :listing/id ident and the :will-enter loading its Id-dependent data
Hmm, I guess that'd get overwritten by :initial-state?
there will be many listings at some point, just working out the basics right now
I got it working... I can share it when I get back to my computer
route parameters sent to change-route will show up in will-enter
from there you could do a deferred route and transact it in
@holyjak heres the updated the gist https://gist.github.com/njj/8aab3a5208d8a9bb7ebaec388ea6803d
although… now I see that making it root/ is kind of weird so I’ll mostly like they change it to to something like active-listing
I assuming root/something query is reserved for queries w/in the Root component