Fork me on GitHub
#fulcro
<
2020-10-09
>
zilti13:10:48

Is there a relatively straightforward way for :will-enter to pass data to the component?

fjolne19:10:13

(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

zilti19:10:22

Hmm, I guess that'd get overwritten by :initial-state?

tony.kay19:10:49

route parameters sent to change-route will show up in will-enter

tony.kay19:10:33

from there you could do a deferred route and transact it in

fjolne09:10:11

@U2APCNHCN 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

zilti09:10:57

Oh, I see! Yes, that makes sense, I think I will use swap! inside route-deferred then in that case. Thanks!

👍 1
zilti09:10:08

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]})]))))
And all I get is an empty form together with an ERROR [com.fulcrologic.fulcro.algorithms.form-state:?] - FORM NOT NORMALIZED

tony.kay12:10:43

@U2APCNHCN 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)

zilti12:10:46

Okay. But where do I get the component from? Since I'm in :will-enter there's no component yet, right?

zilti12:10:42

I replaced the swap! statement with

(fa.merge/merge-component!
                                                app CompanyRegistrationForm
                                                (company-registration-form-prefill params))
But that still gives me the "FORM NOT NORMALIZED" error

zilti13:10:28

In this specific case, I want to pass URL parameters to the component

Otis van Duijnen Montijn14:10:01

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...

exit215:10:17

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

exit215:10:29

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?

tony.kay16:10:50

@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.

exit217:10:09

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)

tony.kay17:10:16

your ident on a component like that should likely be (fn [_] [:component/id :listing]), not a shorthand

holyjak17:10:56

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...?

tony.kay17:10:54

@U0522TWDA 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

tony.kay17:10:33

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

tony.kay17:10:40

the other two notations are shorthand that always try to get ID using something from state

holyjak19:10:03

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?

holyjak19:10:11

@U010LFZGFEG 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

exit219:10:30

there will be many listings at some point, just working out the basics right now

exit219:10:42

I got it working... I can share it when I get back to my computer

🎉 1
exit220:10:46

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

exit220:10:15

I assuming root/something query is reserved for queries w/in the Root component

holyjak10:10:05

no, I do not think it is "reserved" in any way

holyjak10:10:09

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...

👍 1
exit213:10:02

@U0522TWDA 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 😄