This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-25
Channels
- # 100-days-of-code (6)
- # announcements (4)
- # aws (2)
- # beginners (151)
- # boot (1)
- # calva (1)
- # cider (19)
- # clara (47)
- # cljdoc (9)
- # cljs-dev (25)
- # clojars (18)
- # clojure (151)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-dev (17)
- # clojure-italy (42)
- # clojure-nl (34)
- # clojure-spec (67)
- # clojure-uk (125)
- # clojurescript (163)
- # core-async (106)
- # cursive (19)
- # data-science (11)
- # datomic (9)
- # duct (2)
- # figwheel (1)
- # figwheel-main (6)
- # fulcro (97)
- # graphql (9)
- # instaparse (4)
- # jobs (6)
- # jobs-discuss (21)
- # leiningen (62)
- # mount (23)
- # off-topic (16)
- # re-frame (15)
- # reagent (16)
- # reitit (5)
- # remote-jobs (1)
- # ring-swagger (9)
- # shadow-cljs (176)
- # tools-deps (102)
- # unrepl (3)
@hmaurer for the first question you can do this
(ns app.intro
(:require [fulcro.client.cards :refer [defcard-fulcro]]
[app.ui.root :as root]))
(defcard-fulcro sample-app
root/Root
{}
{:inspect-data true})
for mutation logging i believe fulcro inspect is the answer
@pvillegas12 @currentoor Been playing a bit with shadow-cljs + fulcro on nodejs. More of a *integration-ish* testing. But you can do in the browser tests or nodejs tests something like:
@U3LP7DWPR oh yeah that is pretty cool
thanks for sharing!
(let [started-callback (fn [{:keys [reconciler]}]
(prim/transact! reconciler `[(my-mutation)]))
fulcro-client (fc/new-fulcro-client
:initial-state (atom {:your-test-state true})
:started-callback started-callback)
mounted-app (fc/mount* fulcro-client root/Root nil)
reconciler (:reconciler mounted-app)
state (prim/state reconciler)]
(assert
(get-in state [:your path])
{:expected true}))
basically create a headless fulcro app, with the mutation in started-callback, then just check the state after the mutation.
should be pretty fast on nodejs, haven't done any performance testing for this approach. But you do get a lot with little work, and it masks the internals nicely. If you mock the networking think you could also get full stack integration testing with df/load & ptransact! using this approach.
Starting out with Fulcro but ran into a snag. I'm pretty sure it's related to the warning about ident's and link queries (http://book.fulcrologic.com/#_a_warning_about_ident_and_link_queries) ... I've got a join that seems to work fine based on the root component's query and initial state (both are fine), but upon actual rendering the join component's props are nil. It's exactly as described in the link I gave, but all my components do have idents and initial-state's that are being used throughout the tree, so as far as I understand it should have a presence in the db to prevent this problem from occuring. I'm at a loss right now ...
link_queries are usually for special cases most of the times you should have components with ident.
A little messy (sorry!) but here goes: https://pastebin.com/cnWVuRLi ...
the state is structured as {:figures [[:figure/by-id xxx]], :figures/by-id {xxx {:db/id xxx :figure/layers [[:high-res-images/by-id yyy]], :high-res-images/by-id {yyy :{}} ... which seems to be fine, grabbing the initial state of the root component shows everything as I expect, but when I render ui-pixi-layer it's props are nil 😞
@claesenm you mean this (js/console.log "pixilayer propz" props)
but the normalized initial state looks exactly the way I like, so the ident's seem to hold up there
try seeing what layers
is here (map ui-pixi-layer layers)
it might not be a collection and instead a single value
it is a single-valued list in my test case, but normalizing a mock state also normalizes properly there
{:image/file-name "ITO.tif"
:canvas/width 500
:canvas/height 300
:viewport/x-start 0.5
:viewport/y-end 0.6
:image/base-url ""
:image/uuid "123"
:db/id 1
:image/degrees 0
:viewport/x-end 0.6
:viewport/y-start 0.5
:layer/type :high-res-image}
@claesenm your problem might be here
(merge {:layer/type type :db/id id}
(prim/get-initial-state HighResImage {:db/id id})))
and
:query (fn [] {:high-res-image/by-id (prim/get-query HighResImage)
:blurb [:rubadubdub]})
the key has to align correctly
yeah, does the merge generate what you expect?
normally, to have normalization, you would have something like
:query [{:high-res-image (prim/get-query HighResImage)}]
that is, in the db, you have {:high-res-image [:high-res-image/by-id 1]}
why would it have the same ident as the HighResImage
component?
I'm not sure what would make a useful ident for a union component, the docs about unions omit them so I wasn't sure
This might be a moment of profound insight ... I thought I needed to place idents on all components
(defsc PersonPlaceOrThingUnion [this props]
{:ident (fn []
(cond
(contains? props :name) [:person/by-id (:id props)]
(contains? props :location) [:place/by-id (:id props)]
:else [:thing/by-id (:id props)]))}
...)
I think the ident and query are fine
Is this working for you
(do (js/console.log "Rendering pixi layer" props)
(ui-util/conform-or-throw ::pixi-layer props "Invalid pixi layer in render")
(case (:layer/type props)
:high-res-image ui-high-res-image
) props)
@claesenm?the () seem a bit off
You're right, those are definitely wrong. Not sure how that managed to slip by unnoticed!
that is responsible for rendering the res-image, does it show something?
still getting the same problem of nil props in the render of PixiLayer unfortunately
what line are you using for debugging?
Is it (js/console.log "layers" layers) ;; this is empty :-(
? the one that is showing you nil
props
it's not nil
there, actually it's [{}]
... but everything downstream receives no props
the root props while rendering also show :figure/layers [{}]
, which I don't understand because the initial state looks fine as it normalized to what I expect
it's like that bit of state just gets eaten during render, while it is fine prior to that
the pixi canvas has :figure/layers but in the initial state seems like just 1 entity... but in the render you do map
yeah that was wrong, I fixed that now but the problem persists ... collecting the state now
Usually when I get into stuff like this I take if from scratch based on a working example and update if (the code you shared has to many working parts to debug from pastebin)
Noticed that in the book there's this example, that seems to do exactly what you want http://book.fulcrologic.com/#_demo_using_unions_as_a_ui_type_selector
I've currently moved this aside for a while but I am going to come back to it in a few days ... The example is indeed equivalent to what I'm trying to do. The weird thing is, I've never had problems with unions in Om Next, but now it turns out surprisingly tricky. I'm sure it's going to end up being some small detail, so I will try to bottom-up from the example you provided. In any case, I really appreciate your help and input, and hopefully I can fix this soon 🙂
you're welcome. Yep takes a bit to get used-to, both for writing and debugging. After a while it gets really easy. Gave up on om-next pretty fast, writing parsers for getting stuff out of the state....is just to much work for me, that approach seems quite brittle. prone to regression bugs. Think the design in fulcro with read-parser and conventions is as good as can be (one you get used to them)
Initial state: https://pastebin.com/KNnqK1B8 Normalized initial state: https://pastebin.com/M0mnf3hH
I made a mistake copying the :figures/by-id in the normalized state to pastebin, but it has the right structure
@tony.kay just found a (very minor) typo in the book: LocaleSelector
vs LocaleSwitcher
at http://book.fulcrologic.com/#_a_warning_about_ident_and_link_queries (end of section)
@hmaurer I think he would prefer a PR for minor typos
@currentoor is the book in the main repo?
yes, it’s one big ascii doc file
this file
you could probably edit it in github
but it’s a very large file so it might a little slow
thanks! 😄
React folks are so weird https://reactjs.org/docs/hooks-intro.html but it sounds kinda interesting
its all dependent on ReactCurrentOwner.currentDispatcher
which is basically a binding
in CLJS terms
I wish they just stops complecting these things into the core, I think this one could be a separated library
@wilkerlucio yeah for sure
can't be a separate lib since it directly integrates into the react render reconciler