This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-23
Channels
- # admin-announcements (1)
- # arachne (3)
- # aws (1)
- # bangalore-clj (2)
- # beginners (209)
- # boot (81)
- # capetown (2)
- # cider (16)
- # clara (13)
- # cljsjs (16)
- # cljsrn (6)
- # clojure (217)
- # clojure-czech (1)
- # clojure-greece (4)
- # clojure-italy (3)
- # clojure-korea (3)
- # clojure-russia (3)
- # clojure-sg (3)
- # clojure-spec (104)
- # clojure-uk (23)
- # clojurescript (7)
- # component (7)
- # cursive (18)
- # datomic (12)
- # devcards (34)
- # dirac (17)
- # editors (3)
- # emacs (1)
- # events (1)
- # hoplon (62)
- # immutant (12)
- # incanter (1)
- # jobs (1)
- # klipse (2)
- # ldnclj (1)
- # luminus (1)
- # mount (1)
- # off-topic (8)
- # om (50)
- # onyx (46)
- # parinfer (5)
- # pedestal (4)
- # perun (2)
- # reagent (1)
- # rum (1)
- # schema (5)
- # specter (30)
- # untangled (5)
- # vim (46)
Is there a compassus hook that would allow me to change route when im not logged in? I currently have it working by calling set-route! :login
in the send function if authentication is required, but it causes a flash of content before it redirects. It would be great to be able to define this at the route level somehow.
@danielstockton hrm you need to describe the problem you're having in more detail, but you shouldn't be doing anything like that in the send
function
some of my routes have queries that require a user to be authenticated, i wanted to be able to redirect unauthenticated users to /login
i also want to redirect similarly should i receive any 401 responses
having login on a separate route solves my 'force a remote re-read' problem
OK so those are 2 different problems. let's start with the local redirection: is there a reason why you can't handle that in the parser?
set-route! needs a reconciler or component, i'm not sure how to pass this to the parser
or an app*
Sorry I wasn't clear, I didn't mean you should set-route!
from the parser
@danielstockton but rather: the way I would probably do it is: in the parser I would return :auth-needed
or something instead of the data if the user is not logged in
and you can set-route!
to the login page based on the result of transact!
or set-route!
note that compassus.core/set-route!
returns the result of transact!
on purpose
you can even throw
inside the parser and get at the error which is returned in the result of transact!
I think I have some test for that in Compassus
https://github.com/compassus/compassus/blob/master/src/test/compassus/tests.cljc#L460
which transact! are you referring to? its actually the result of a read that can return :auth-needed
i think i can call set-route! in each routes willMount then, if they receive some data that is :auth-needed instead of what was expected
do you see anything conceptually wrong with calling set-route! from in send, if I get a 401 response from some endpoint?
this means that the user seems logged in but when actually making the request, it turns out they're not authorized for something
in fact, ignore that, i think i'd prefer to show an error rather than redirect in this case
@danielstockton independently of what you want to do, I would set-route!
in merge
rather than in send
just separating concerns
ok, makes sense, the status should be part of the data that is passed to the send callback
thanks, think i can make some progress with this
im seeing two identical remote sends happening in quick succession, are there any gotchas i should watch out for?
actually, on one route im getting three
hello, I'm experiencing some performance issues with recursive queries, something seems off, after doing a simple transaction (just changing a string) this is getting on the console: https://www.dropbox.com/s/u5lzdtwxrk87ydp/Screenshot%202016-11-23%2015.13.00.png?dl=0
seems like it's triggering the read multiple times, I don't understand why. did someone found anything similar or have an idea about what might be going on? I believe it's related to recursive queries because removing that query part makes it work normal
ps: the recursive results are in the range of about 3 items, each going 3 4 levels deep (around 12 18 iterations total), so, not enough to justify this amount of lagging
@wilkerlucio maybe time to look into path optimization?
though it seems kinda strange that it would re-render so many times
@anmonteiro yeah, very weird, and rendering doens't seems to be the problem, removing the rendering part doesn't fix the slow part, removing the query does
it might also be an issue with Untangled, maybe something on how the read is implemented, I have to double check on that
I don't understand what you mean by "rendering doesn't seems to be the problem"
given you have 13 re-renders of your app after a single transaction
I mean that the slow part seems to happen before any render occurs
right, the slow part is computing the result from the query
but the weird thing is that it's reading so many times
and it's only reading because it's re-rendering
with path optimizations on, when something changes, it re-computes the read for each component or once for everyone?
oh right, that may be what's going on
when something changes it'll just re-compute the query result for the specific ident that changed
humm, yeah, that might be around it
I'm wondering if we can be more efficient about it, because in recursive situations this seems to be wasteful
imagine that now for each recursive item it is re-computing from the root, do you think would be possible to avoid that and process the recursion just once instead and re-use it? (since on this case, it would have to re-compute then anyway)
@wilkerlucio I think the only way to do that would be to extend some indexer functions to not return every mounted component that matches the recursive query
specifically, provide your own custom implementation of :ref->components
: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1881
and assemble your own indexer which you pass to the reconciler
@anmonteiro I'll dig deeper into the issue and try at least to confirm if our assumptions are right about the problem. I gotta bounce now, thanks for the clarifications.