This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (7)
- # aws (5)
- # beginners (37)
- # boot (39)
- # cider (4)
- # clara (2)
- # cljs-dev (32)
- # cljsjs (1)
- # cljsrn (12)
- # clojure (235)
- # clojure-austin (3)
- # clojure-belgium (7)
- # clojure-berlin (11)
- # clojure-dev (36)
- # clojure-france (10)
- # clojure-japan (10)
- # clojure-poland (2)
- # clojure-russia (39)
- # clojure-uk (4)
- # clojurescript (81)
- # code-reviews (9)
- # core-async (6)
- # core-logic (1)
- # datomic (32)
- # editors (7)
- # emacs (1)
- # hoplon (191)
- # jobs-discuss (14)
- # juxt (4)
- # lein-figwheel (4)
- # leiningen (3)
- # off-topic (7)
- # om (49)
- # onyx (34)
- # other-lisps (1)
- # overtone (11)
- # parinfer (1)
- # proton (5)
- # re-frame (11)
- # reagent (12)
- # spacemacs (2)
- # untangled (90)
- # yada (15)
alternatively has anyone implemented login? specifically checking the session before each request gets dispatched to it’s handler?
we have, but its not open sourced yet, i would wait for a response from tony about the plan/schedule on that
@juliobarros, @adambros isn’t the typical instantiation of an untangled app to hide ring? One fires up an untangled-system with some params and that’s the entry point. I’m wondering if there’s a preferred way to use an authentication fn?
so i didnt write it, but the way it seems to work is by hooking into the untangled ring stack with stuff i wrote
@brianosaurus: I'm not an expert. I probably wouldn't say it was to hide ring. Just to simplify the server side parser. I'd be surprised if everything else wasn't exactly the same where you could design and customize as you like.
I mispoke, it’s not untangled-system but make-untangled-server…anyway. Curious what the preferred solution is.
@brianosaurus: I don't think there is a preferred way to handle authentication yet... We do a bit of a dance with OpenID connect to get creds in a cookie. Then we hook into the ring stack and use
request-transform to validate and place creds on the request. Those creds are then extracted and evaluated inside mutate fns. The authorization part is pretty nice, but authn setup may be different for the various authn providers.
I’m having trouble getting this join query to work. Been stuck for a while even though it seems so simple.
core.cljs:264 Uncaught Error: No protocol method IWithMeta.-with-meta defined for type cljs.core/Keyword: :main
yes, I mean, that's your initial app state there, and you've already manually normalized it?
in vanilla om, you'd pass
:state (atom app-state) :normalize true in that case, as of a somwhat recent release
looking at untangled's source I guess your best option will be to denormalize your initial app state
of course i wasn’t observant enough to notice the normalization comment and
@juliobarros: @brianosaurus Right: Not hiding it, just making it for you. As others pointed out: you can hook into the ring stack near the beginning (before the Om parsing bits) or late (as a default handler if nothing else handled it). That pretty much lets you customize the server any way you want as far as request handling. So, if you need to do various redirects...covered. Then, of course, there is the component injection into the parser (e.g. make an authorization component (Stuart Sierra component), add it to the components map on make server, and inject it into the parser environment...now you have access to it in you API handlers for making the authorization decisions on a request level.
@tom.kay thanks. That’s very helpful. I think it’s apropos to have access to auth handling on the request level since not every request requires someone to be auth’ed (the about page for example).
Yep. Authentication is usually more global (do I know you (or care)) whereas authorization is request specific.
@tony.kay: FWIW: We ended up putting unauthenticated handlers into extra-routes and we made the default mutate and read handlers authenticated. It’s simple and clear.
@tony.kay: Great presentation last night! Thinking further about the cache invalidation problem, if I understand correctly, falcor does have the server return either the values, or paths, that a mutation may have modified. See http://netflix.github.io/falcor/documentation/jsongraph.html#the-abstract-json-graph-operations you would still be doing cache invalidation "by hand" but at least it would be at the point of the mutation, and not "find every component that may be rendering something that I may have changed, and modify that component to know that if x changes y changes too" but I don't feel like I've fully grasped what you are doing yet.
@shofetim: Yes, that is what I was trying to describe. The server does return the keys that are affected. Untangled doesn't add/remove anything around that. It is Om next behavior.
@brianosaurus: Yeah, we're not doing anything complicated The intention is "as simple as possible while meeting all other criteria."
So in Om.next it would be the parser's job to take those keys and "do something" (<- user implements their own "something")
Your networking layer could play with them, if they are returned. To be honest, you'd have to ask on #C06DT2YSY
But look at it this way: when you are writing the UI, you know what you are putting on the screen
Most mutations: you already did an optmistic update, so you had the state before the server did. As long as there isn't an error, all is good
If there is an error, we support
(tx/fallback) in your original transaction, which can say what to do (e.g. undo the optimistic update)
(tx/fallback) isn't quite done yet...it is kinda half baked, and is missing a little bit of functionality (e.g. clearing the network queue is an important feature we don't have yet)
How many times have you written a real app where you didn't know pretty much exactly what was going to happen when you asked the server to do something?
so, i'm not too game to work on implementing a solution until I see the real concrete problem
That is the case I am trying solve actually. I have an app that has the user fill out a questionnaire (30-100 questions) answers are gathered up by the component, and then sent to the server. Saving the answers is no problem, that fits the pattern of small updates to records that I want the same thing to happen on the client and on the server. When the user is done with the questionnaire, they should see a list of matches (or update a list of matches, or update the scores they see on a list of matches). Only the server has logic to compare their answers against all possible matches and produce the new scores. Now I need to invalidate all or some of the matches currently on the client...
Then if it is a single transaction, use:
(om/transact! this '[(do-the-update) (app/load ...query w/parameters...)])
Ok, so what untangled does is if the component knows it is going to need a bunch of fresh state (matches in my description above) make a query that fetches that state, and use app-load as a callback to get it?
not a callback...it is a follow-on remote read. They are guaranteed to be done in order
app/load as a local mutation that modifies local state by loading it from the remote
so, we just cut the parser stuff out of the middle. Ask for exactly what you want. You can do the
:post-mutation, etc on