This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-11
Channels
- # beginners (2)
- # boot (97)
- # cider (58)
- # cljs-dev (10)
- # cljsrn (7)
- # clojure (79)
- # clojure-austin (4)
- # clojure-brasil (1)
- # clojure-france (1)
- # clojure-russia (42)
- # clojure-spec (12)
- # clojure-uk (22)
- # clojurescript (150)
- # clr (1)
- # conf-proposals (7)
- # core-matrix (2)
- # cursive (4)
- # datomic (9)
- # jobs (2)
- # klipse (28)
- # leiningen (3)
- # lumo (8)
- # nrepl (1)
- # off-topic (28)
- # om (18)
- # om-next (2)
- # perun (17)
- # planck (9)
- # rdf (1)
- # re-frame (18)
- # reagent (7)
- # ring (2)
- # rum (1)
- # specter (11)
- # test-check (3)
- # untangled (1)
- # yada (7)
After some bisecting - yeah, it was definitely the switch from alpha46 to alpha47 that changed this behavior in our app. Not sure if that's just because it's exposing a bug in our app (we had some other weird things the transition to 47 exposed with queries not composing up to the root in some cases, maybe this is like that)
Okay - it was because of ^:once - don't know how that never bit us before! Thanks for pointing me in the right direction @adambros. When I tried to fix it earlier with that I think I screwed up how I added it in the macro. (changed to ~(with-meta name {:once true})
instead of ^:once ~name
)
yeah i’ve run into that, really annoying
Is it possible to somehow "extend" an om component? Like using polymorphism to inherit some BaseComponent that was defined using defui ?
hi all, in om.next, is there a way to force a re-render of a component, bypassing the render queue? I ask because when using om.next with react-native, controlled TextInputs end up stuttering. I’ve been using react-set-state!
to get around this by bypassing om.next’s render loop altogether, but I’m wondering if there’s a better way.
@levitanong (.forceUpdate this)
could potentially work
this
being the component instance
@anmonteiro I tried it, but it didn’t work 😞 I’m guessing it tries to update before the parser can get around to it?
I’d try to run (.forceUpdate this)
inside the mutation, but i don’t think i have access to the component instance from a mutation fn
hrm, there's definitely a :component
key in the parser if you transact!
from a component
@anmonteiro will give that a go
@anmonteiro still no dice.
and i don’t suppose schedule-render!
would work 😛
@anmonteiro the closest thing i’ve seen is this issue in reagent: https://github.com/reagent-project/reagent/issues/119#issuecomment-141396203
and i’ve taken a look at their flush
: https://github.com/reagent-project/reagent/blob/v0.6.0/src/reagent/impl/batching.cljs#L91
At this point I can’t understand what’s going on anymore 😛
@levitanong I'm afraid I don't have substantial React Native experience to help you any further
thanks anyway, @anmonteiro 🙂
@levitanong (om/transact! ..) takes 2 args, one is a component and the rest can be mutates_and_keys_to_be_re-read ... I just figured that out yesterday, it may be germane to what you're doing.