Fork me on GitHub
#fulcro
<
2017-09-29
>
roklenarcic13:09:56

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.

roklenarcic13:09:59

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

roklenarcic13:09:05

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

roklenarcic13:09:10

instead of passing params

roklenarcic13:09:19

I consider this a bug

tony.kay17:09:53

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

tony.kay17:09:40

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

tony.kay17:09:32

beta11-SNAPSHOT on clojars with a fix.

tony.kay18:09:59

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

tony.kay18:09:31

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

mitchelkuijpers18:09:52

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

tony.kay18:09:16

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

tony.kay18:09:41

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

tony.kay18:09:27

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

tony.kay18:09:24

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

tony.kay18:09:25

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

wilkerlucio19:09:26

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

tony.kay19:09:30

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

tony.kay19:09:47

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

tony.kay19:09:14

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

tony.kay19:09:03

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

tony.kay19:09:28

(even the lein template has them)

wilkerlucio19:09:16

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

wilkerlucio19:09:26

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

wilkerlucio19:09:34

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

wilkerlucio19:09:53

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)

tony.kay19:09:18

feel free to submit a PR 🙂

tony.kay19:09:06

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

wilkerlucio19:09:25

maybe we can normalize the value passed to the card state

tony.kay19:09:36

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

wilkerlucio19:09:38

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

wilkerlucio19:09:16

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

wilkerlucio19:09:27

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

wilkerlucio19:09:41

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

tony.kay19:09:51

you might find that tough

tony.kay19:09:12

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

wilkerlucio19:09:53

humm, yeah, not sure how hard would that be

tony.kay19:09:00

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

wilkerlucio19:09:12

dont worry, I can look into that 😉

tony.kay20:09:25

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

wilkerlucio20:09:07

an extra argument might be cool, because would cover other cases at well, I like the idea

tony.kay20:09:26

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

tony.kay20:09:37

I’d like that better

tony.kay20:09:14

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

tony.kay20:09:29

:initial-state-params

tony.kay20:09:47

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

tony.kay20:09:18

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.

wilkerlucio20:09:50

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

tony.kay22:09:36

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.

wilkerlucio22:09:49

sure, makes sense

tony.kay22:09:44

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