This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-11
Channels
- # arachne (5)
- # beginners (28)
- # boot (59)
- # cider (10)
- # cljs-dev (10)
- # cljsrn (10)
- # clojure (58)
- # clojure-brasil (2)
- # clojure-czech (9)
- # clojure-miami (1)
- # clojure-poland (2)
- # clojure-russia (12)
- # clojure-spec (16)
- # clojure-sweden (1)
- # clojure-taiwan (1)
- # clojure-uk (77)
- # clojurebridge (3)
- # clojurescript (108)
- # cursive (5)
- # datomic (25)
- # defnpodcast (2)
- # editors (1)
- # events (1)
- # funcool (24)
- # hoplon (37)
- # instaparse (1)
- # lein-figwheel (7)
- # leiningen (7)
- # luminus (3)
- # off-topic (9)
- # om (90)
- # onyx (88)
- # proton (3)
- # protorepl (9)
- # re-frame (30)
- # reagent (23)
- # rethinkdb (2)
- # untangled (33)
- # vim (1)
- # yada (6)
Hello. Is it possible to mix om next in with an existing app. Something which might facilitate a gradual migration from a cursor based "om previous" approach.
@wilkerlucio: hah! solved your issue
so you need to (set! (. c -om$isComponent) false)
instead of gobj/set
everything should work then
tested under advanced
@anmonteiro: thank you very much, that works 🙂
@wilkerlucio: I didn’t check if you have to clone prototype or not though
you might want to check that
since prototype lookups are dynamic, you might be changing every prototype
I think that's not the case, because we are not changing the prototype there, just adding the om$isComponent
to the object itself, not the prototype
@wilkerlucio: ah right
my bad
but I got into a situation here were Om did tried to apply the hack a second time, and it failed
on my case, I check if the object implements my custom static method, otherwise I call the default get-query
, doing that on the hacked instance fails (that same previous problem, try to get the prototype where there isn't one)
my code ended up like this:
(let [comp' (r/route->component route)
comp (js/Object.create (.-prototype comp'))
_ (set! (.-om$isComponent comp) false)
comp (if (implements? r/IRouteMiddleware comp)
comp
comp')])
@wilkerlucio: so that works, yeah?
yes it does 🙂
cool!
still weird that advanced compilation elides static methods
@anmonteiro: yeah it’s weird, I wonder if there’s way to prevent that via some Closure thing
@dnolen: yeah I’d be interested in that, I’ll try to look it up in my spare time but I don’t have a lot of Closure experience
could you also shed some light on set!
vs goog.object/set
in advanced compilation?
set!
works for setting static properties known to Closure under all compilation modes including advanced
@dnolen: so for JS instances it’s no problem to use set!
and (.-prop obj)
?
gotcha, thanks
@dnolen: I still not clear on the distinction between gobj/set
vs set!
, do you know why the set!
worked while gobj/set
didn't on this case?
ah, got it, since the om$isComponent
is going to get munged, the set
calls needs to use the munged name, thanks
Shouldn't a component that is defined with (defui Mycomp ..
return true for (om/component? Mycomp)
or am I misunderstanding something?
@hlolli: om/component?
checks if it’s an instance
it will return false for component classes
ok, was trying to do om/update-state! outside defui macro. So insead of using this
like I always do, I was just checking if I could pass in the component name and mutate the component local state that way. Probably a bad idea.
@hlolli: definitely a bad idea because local state is specific to instances and there could be several instances of the same class
yes, when you say it, I see how ill tought this is. I will rather have a function return a value that I update in that instance. So its just me experimenting in the wrong direction. Thanks for pointing this out.
just pushed Compassus 0.2.1 to Clojars. Changelog here: https://github.com/anmonteiro/compassus/blob/master/CHANGELOG.md#021-2016-07-11
@anmonteiro: Happy celebrations on protugal btw :flag-pt:
Thanks, I suppose. I like watching the matches but I don’t go crazy about celebrating 🙂
when using the wildcard selector [*]
, given the join doesn't exists (blank data there), Om.next is returning the full database (as I was querying [*]
on root), is this the intended behaviour? I was expecting it to return nil
question about having two different remotes such as (A) authentication and (B) something that does remote computation only when we’re authenticated
I’d like to be able to “trigger” the running of (A) when (B) gets a 403 response by returning some novelty like {:authorized? false}
which on read would do {:authentication true}
to run (A) — but I notice the parser doesn’t care enough to rerun the read for the :authentication
remote after the novelty for (B) is merged in so authentication never happens
1) is this not the "right way" to do it, and if so
2) is there an example online of a more om.nexty way to do it
@calvis It might be easier to have auth handled separately, but you might be able to trigger the remote read by transacting on the reconciler when you get the 403 and include some key that will respond to the :authentication
remote.
so (B) would have to know about the reconciler? that’s not a piece of information I thread through right now
oh sorry I was conflating the two - the function responsible for calling the (B) remote would have to know about the reconciler
I did something similar by passing the channel for calling (A) to (B)’s sender fn but that felt a little out-of-band to me
I think I might try to merge some info in that would be read locally by a component and then in the componentWillReceiveProps
react lifecycle, check for the need to reauth
so I’m not going to get any help from om.next here? this seems like a pretty normal thing to want to do
So the response from (B) when merged by the sender cb would introduce novelty that would be read by some component and when it sees :authorized?
change to false would just transact! so the :authenticion
remote would be used.
Authentication seems like a remote mutation type thing, not really a read thing. So if you want to use the reconciler to perform that you might have to get some feedback first and then do a (om/transact! comp-or-reconciler '[(auth/login {})])
or something
@calvis: I think it should be easy enough to do that by overriding :merge
in the reconciler
your custom merge
function would:
1. call om/default-merge
for the default behavior
2. queue the keys you want for re-reading which would then trigger reads in the parser
so the keys are being reread, but only for their :value
s and not for the remotes, is that possible to trigger via merge? “pls read for all remotes as well”?
@calvis: ah right, makes sense they are being re-read only locally (as a post-remoting hook).
you can call om/gather-sends
in that custom merge
function
not sure if that would be exactly what you want, but it takes a vector of remotes as the 3rd argument, which gives you more control over which remotes to gather the sends for
i.e. you probably don’t want to read remote stuff from B since it’s what gave you the response already
I don’t think there’s any docs on gather-sends
but it’s part of the public API
@calvis: you’ll also need to call schedule-sends!
after calling gather-sends
it would be nice to have a way to just say “re-run all the remotes afterwards”, since that is the behavior I want in all cases with this app
@calvis: you can probably do that by overriding merge
, as I suggested
it’s why Om Next provides these extensions in the reconciler
that said, baking all these use cases into Om Next by default is out of the scope of what Om Next is aiming to be IMHO
Om Next's focus is on providing these building blocks which you can assemble into a more full-fledged application
that’s true, maybe it was just a documentation failing then in my case, I was kind of expecting everything to get rerun because nothing mentioned reads getting called multiple times once for each remote
it’s also what allows things like Untangled to exist
I haven’t used it myself but I’ve heard good things
if you haven’t heard about it: http://github.com/untangled-web
WRT documentation, it definitely needs to be improved. it’s also why Om Next is still alpha
question: Is it considered in-spec for a mutate handler to transact!
a new transaction when it's handling an existing transaction? Or should the transactions represent distinct & isolated user intents as much as possible?
@takeoutweight: I wouldn’t recommend doing that
you can always do things like: (om/transact! ‘[(some/action!) (other/action!)])
Makes sense. In our experiment the use case was having the second transaction conditionally depend on data computed when handling the first so issuing both transactions in the same transact!
wasn't quite right. But it sounds like keeping the UI logic factored in a a way that all the cascading operations can be kicked off by a single transaction would be the way to go.
@takeoutweight: for better or worse om.next is designed around a distaste for chain reactions
Is it normal to call om/set-query!
from within a transaction, or would you recommend that this be called directly next to (rather than triggered by) om/transact!
instead?
@danburton: would not do that in a mutation, I would do it next to