I was using defsc and it's initial-state function relies on having params passed in. However I have noticed that params passed into a router init state don't get passed on.

in fulcro.client.routing we have an emit-router function, which has this code: ` ~'static fulcro.client.core/InitialAppState ('initial-state ['clz 'params] {:id router-id :current-route (fulcro.client.core/get-initial-state ~union-sym {})}) `

dammit

anyway, it calls get-initial-state of the union with empty param map

instead of passing params

I consider this a bug

@roklenarcic I think you’re right. The default screen should be able to receive those params

were you expecting all screens to get them? Because I’m not sure that is possible (alternates are initialized outside of the tree)

beta11-SNAPSHOT on clojars with a fix.

Hrm. Dynamic routers may have a bug as well. @mitchelkuijpers are you using dynamic routers?

bummer, yeah. I’m certain there’s a nefarious little bug in there 😕

https://github.com/fulcrologic/fulcro/issues/36

I was playing with it, haven't finished it yet

The issue I just discovered will probably make it not work right in certain cases.

yeah, in all cases, actually. Under refresh it will the lose query change which will cause rendering issues on the routes that are not the default

anything that is working is a byproduct of cached things (or optimized UI refresh that skips the router)

It’s fixable…should have a fix later today. It will make it impossible to use dynamic routers with update-routing-links though I think

Also, if you want to be able to use the “support viewer”, dynamic queries are keyed by reconciler or component (in your app state) which are not serializable. That realization is what got me looking at dynamic routing and led to me discovering the other bug (the queries aren’t there with dynamic routers).

is there any tutorial around fulcro + devcards? I just haven't done in a while, just trying to remember if there is anything special I must do

There’s a namespace called fulcro.client.cards. The macro defcard-fulcro is what you want

if you want to run a full-stack app in a card. Otherwise, it’s just the regular stuff

It dynamically uses devcards, so you’ll have to add the dependency to your own project

Take a look at the demos build in fulcro itself, or in the template

(even the lein template has them)

👍

thanks

sure

@tony.kay minor thing, but I was trying to start a card by using the root initial state + params, like this:

(defcard-fulcro boletos-widget
  boleto/Root
  {}
  {:inspect-data true
   :fulcro {:initial-state (fulcro/get-initial-state boleto/Root "123")}})

but that doens't work, in the end I have this:

(defcard-fulcro boletos-widget
  boleto/Root
  (om/tree->db boleto/Root (fulcro/get-initial-state boleto/Root "123") true)
  {:inspect-data true
   :fulcro {}})

not a big deal, but I think would be easier if fulcro initial-state was considered (so the user don't have to normalise the database)

feel free to submit a PR 🙂

I just thought it would be confusing to have two places to specify card state

maybe we can normalize the value passed to the card state

Um…if your app HAS initial state, it should just get used

do you know if we have this change of catching it on this case?

yeah, I agree, it's just that on this case I want to parameterize my initial state

hm. I see.

maybe it's such an edge case that it doesn't worth the effort, but I can send the PR to accept the initial-state

I think people looking into that would be ones trying to do the parameterizing thing

you might find that tough

thinking…you have to use the atom of that card, because the devcard watches it, I thjink

humm, yeah, not sure how hard would that be

maybe that isn’t true. I just don’t remember

dont worry, I can look into that 😉

k

Maybe just an additional fulcro argument for the param to initial app state?

that would make it usable for other things as well…maybe you have a root that behaves differently in idfferent situations that could be manipulated by that

I’d like that better

the devcards would still have to hack it around, but it would be a consistent option from the user’s perspective then

:initial-state-params

On another note: Ug. I’m remembering why I wanted to avoid dynamic queries 😕

So, I’d love to know who is using dynamic queries in their applications (e.g. om.next/set-query!). The ideas around them are interesting and sound, but the implementation causes a number of complexities. We’re getting close to Fulcro 1.0 release, and I’m thinking 2.0 might need to be an actual fork of the core om next primitives, but simplified. There’s a lot of complexity and overhead in dynamic queries as designed. Om Next also does not seem to be getting much in the way of attention (many out-standing PRs). The history system is inadequate (at present) for the error handling story I’d like to make standard. I’m kind of loathe to drop direct use of Om Next because we’ll drift apart in terms of interchangeable libraries (like fulcro-css), but I’m frustrated at not having more direct control of the significant internals.

it might worth to try to talk to David about Om.next, I see they are very focused on the npm stuff right now, but that can chance once it gets out, and Om.next still a solid starting point, and already has a more broad community, I'm not if splitting out of that would be that good

Yes, I’ve done that. It’ll be a tough call, but it would help to know if dynamic queries are much in use in our subset of the community.

sure, makes sense

Pushed beta11-SNAPSHOT to clojars. Dynamic router bug fixed.