This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-05
Channels
- # beginners (135)
- # cider (30)
- # clara (66)
- # cljs-dev (18)
- # cljsrn (6)
- # clojure (115)
- # clojure-austin (1)
- # clojure-dev (10)
- # clojure-italy (7)
- # clojure-nl (1)
- # clojure-spec (18)
- # clojure-uk (26)
- # clojurescript (76)
- # cursive (2)
- # datomic (4)
- # devops (1)
- # emacs (19)
- # fulcro (159)
- # garden (3)
- # klipse (5)
- # leiningen (5)
- # off-topic (61)
- # om (7)
- # pedestal (6)
- # re-frame (17)
- # reagent (73)
- # ring-swagger (6)
- # rum (5)
- # shadow-cljs (60)
- # spacemacs (31)
- # specter (4)
- # vim (8)
- # yada (1)
@wilkerlucio trying out the latest fulcro-inspect. It seems to work for me, except i’m getting odd multimethod errors about :com.wsscode.pathom.connect/indexes
. Fulcro-inspect appears to be attempting to use my custom remotes with some query keyed by that keyword above.
i believe it’s hitting all my remotes
@levitanong yes, on initialisation it tries to pull the pathom indexes, but I'm considering remove this auto-load, you are the second person having issues with that
I had the assumption that peoples parsers would just ignore unknown keys, but seems like it's not the case
yeah, I'll try to make a new release today fixing that, another big one is that I want try an hybrid encoding mode
instead of trying to "fix" the transit compilation by walking, I wanna see if I can just encode via EDN when transit fails
and see how that goes, so both can be a release soon (maybe later today)
@levitanong is that blocking you from using it? or just an annoying error?
Just an annoying error as far as I can tell. Sorry, I was asleep. Timezones and all. Haha
@tony.kay we’re nearly onto fulcro, I saw you’ve been answering nicks questions thanks a lot for the help, i got pulled in for a couple remainder issues,
#(transact! T [(listing-details/upload-images {:parentId _id
T = the UI component here , it’s not a reconciler, or null.
And yet the handler
(defmethod fulcro.client.mutations/mutate :default [env k params]
the env has NIL for key :component
it’s worth mentioning that it’s not that the key no longer exists in env, it’s present, but just NIL
Hey @jasonjckn. I just found a bug yesterday where lazy seqs are not getting forced
not ringing a bell…pretty sure component is still added to env internally…let me dbl check
it's strange, I use those in Fulcro Inspect, and I'm seeing the component information present on results
should be pretty easy to reproduce , :component
is nil for all mutations I see getting hit
@jasonjckn are you using fulcro inspect?
if you do, you can try checking if the component shows up in the transaction history
just did a js/console.log
(defmethod fulcro.client.mutations/mutate :default [env k params]
(js/console.log "fulcro.mutate")
(js/console.log env)
https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/primitives.cljc#L2409
is not :action
missing there?
Your file was uploaded — it's safe and sound in Slack. Unfortunately your workspace doesn't have any storage space left. To get more space, you can upgrade to a paid account or delete some of your older files
https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/primitives.cljc#L2487
because technically then that component isn’t in any indexes, and isn’t safe to use for certain ops I think.
basically transact! walks up the tree looking for a stateful component to run the tx against…:component will be set to the first component above it that has a query
right…what I just said…I think has-query?
might have been recursive in the past…e.g. me nor any parent has a query
so, “which” component was “transacted against” is a good question in terms of purpose…the transactions are related to state, which only ends up in the UI via queries.
seems like you could reason :component being the parent component, or the one it was transacted on
same logic…so, IF there is no query on the component, it looks to me like Om Next/Untangled/Fulcro will all make :component
nil
When I ported that I was looking for max compatibility. I could be convinced that the logic is wrong, since it looks weird to me
I think the logic is just wrong…Also, I tend to agree with you: it seems harmless to pass the component into mutation, even if it has no query
oh…re-rendering logic: The transact wants to refresh the component whose data changed…which MUST be a component (in Fulcro) with a query and ident
but you would not want to queue a stateless component, since there is no way to refresh it in isolation
but it looks like the logic in place is meant to scan for the parent, so I think either should work
@jasonjckn Try 2.5.8-SNAPSHOT
it isn’t the parent component that will get passed in…it will be the correct one. The parent logic is for tx intercepters, which are not even documented
the parent traversal wan’t changing :component
, it is propagating messages to components that are parents that implement that protocol
sadly i’m running into a bunch of issues trying to move from 2.4.4 to 2.5.x , not sure I can test right now on 2.5.8-SNAPSHOT, but this patch gets my thumbs up
I think there’s more stringent checks on defui in 2.5.x
(shouldComponentUpdate [T next-props next-state next-context]
is failing to compile
this was an experimental feature in react v15.x trying to check the status of this in react v16.x
React previously shipped with an experimental context API. The old API will be supported in all 16.x releases, but applications using it should migrate to the new version
well the feature itself sort of works like clojure’s bindings and dynamic vars except instead of call stacks it’s child-parent components, and props instead of vars
and all child nodes, e.g. bootstrap submit button, text fields, etc can see this context
well there’s a new conetxt api in react v16 with different signature than the legacy api
so I get why you don’t want to support this, it’s non trivial to change this part of our app right now
Caused by: java.lang.AssertionError: Assert failed: Invalid signature for shouldComponentUpdate got [T next-props next-state next-context], need [this next-props next-state]
(= (count sig') (count sig))
at fulcro.client.primitives$validate_sig.invokeStatic(primitives.cljc:218)
at fulcro.client.primitives$validate_sig.invoke(primitives.cljc:216)
at fulcro.client.primitives$reshape$reshape_STAR___15608.invoke(primitives.cljc:424)
at clojure.core$map$fn__5587.invoke(core.clj:2745)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:528)
in the interim I may just add queries everywhere that’s affected by this, but will be happy to upgrade when we can
OH…I know why it is validating now…I made it possible to override shouldComponentUpdate
you could override it before, but the latest versions give you next-props
and next-state
of Fulcro…not low-level React
@jasonjckn an easiler workaround is to call transact*
directly