Fork me on GitHub
#om
<
2016-11-23
>
danielstockton07:11:28

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.

anmonteiro12:11:18

@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

danielstockton12:11:31

some of my routes have queries that require a user to be authenticated, i wanted to be able to redirect unauthenticated users to /login

danielstockton12:11:24

i also want to redirect similarly should i receive any 401 responses

danielstockton12:11:01

having login on a separate route solves my 'force a remote re-read' problem

anmonteiro12:11:40

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?

danielstockton12:11:46

set-route! needs a reconciler or component, i'm not sure how to pass this to the parser

anmonteiro12:11:15

Sorry I wasn't clear, I didn't mean you should set-route! from the parser

anmonteiro12:11:24

@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

anmonteiro12:11:34

and you can set-route! to the login page based on the result of transact! or set-route!

anmonteiro12:11:30

note that compassus.core/set-route! returns the result of transact! on purpose

anmonteiro12:11:23

you can even throw inside the parser and get at the error which is returned in the result of transact!

anmonteiro12:11:32

I think I have some test for that in Compassus

danielstockton12:11:16

which transact! are you referring to? its actually the result of a read that can return :auth-needed

danielstockton12:11:04

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

danielstockton12:11:32

do you see anything conceptually wrong with calling set-route! from in send, if I get a 401 response from some endpoint?

danielstockton12:11:00

this means that the user seems logged in but when actually making the request, it turns out they're not authorized for something

danielstockton12:11:37

in fact, ignore that, i think i'd prefer to show an error rather than redirect in this case

anmonteiro12:11:46

@danielstockton independently of what you want to do, I would set-route! in merge rather than in send

anmonteiro12:11:54

just separating concerns

danielstockton12:11:17

ok, makes sense, the status should be part of the data that is passed to the send callback

danielstockton12:11:44

thanks, think i can make some progress with this

danielstockton14:11:04

im seeing two identical remote sends happening in quick succession, are there any gotchas i should watch out for?

danielstockton15:11:43

actually, on one route im getting three

wilkerlucio18:11:22

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

wilkerlucio18:11:20

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

wilkerlucio18:11:09

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

anmonteiro18:11:47

@wilkerlucio maybe time to look into path optimization?

anmonteiro18:11:25

though it seems kinda strange that it would re-render so many times

wilkerlucio18:11:03

@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

wilkerlucio18:11:28

it might also be an issue with Untangled, maybe something on how the read is implemented, I have to double check on that

anmonteiro18:11:18

I don't understand what you mean by "rendering doesn't seems to be the problem"

anmonteiro18:11:34

given you have 13 re-renders of your app after a single transaction

wilkerlucio18:11:56

I mean that the slow part seems to happen before any render occurs

anmonteiro18:11:19

right, the slow part is computing the result from the query

anmonteiro18:11:30

but the weird thing is that it's reading so many times

anmonteiro18:11:47

and it's only reading because it's re-rendering

wilkerlucio18:11:58

with path optimizations on, when something changes, it re-computes the read for each component or once for everyone?

anmonteiro18:11:24

oh right, that may be what's going on

anmonteiro18:11:57

when something changes it'll just re-compute the query result for the specific ident that changed

wilkerlucio18:11:16

humm, yeah, that might be around it

wilkerlucio18:11:41

I'm wondering if we can be more efficient about it, because in recursive situations this seems to be wasteful

wilkerlucio18:11:32

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)

anmonteiro18:11:04

@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

anmonteiro18:11:04

specifically, provide your own custom implementation of :ref->components: https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L1881

anmonteiro18:11:20

and assemble your own indexer which you pass to the reconciler

wilkerlucio18:11:54

@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.