This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # bangalore-clj (1)
- # beginners (89)
- # boot (16)
- # braveandtrue (4)
- # cider (1)
- # cljs-dev (6)
- # cljsrn (90)
- # clojure (132)
- # clojure-austin (1)
- # clojure-dusseldorf (4)
- # clojure-italy (12)
- # clojure-portugal (2)
- # clojure-spec (13)
- # clojure-uk (41)
- # clojurescript (142)
- # code-reviews (19)
- # conf-proposals (1)
- # datascript (6)
- # datomic (7)
- # graphql (12)
- # jobs-discuss (3)
- # keechma (23)
- # leiningen (3)
- # lumo (22)
- # off-topic (7)
- # om (21)
- # onyx (8)
- # parinfer (46)
- # pedestal (3)
- # perun (3)
- # re-frame (10)
- # reagent (30)
- # ring (1)
- # rum (2)
- # spacemacs (1)
- # sql (2)
- # testing (17)
- # yada (32)
there's no doc around it, also I saw some where in SSE doc which mentioned it does not
Aleph supports websockets. They are not HTTP but an 'upgrade' protocol. Hence yada doesn't say much. See Aleph's docs
https://datatracker.ietf.org/doc/draft-west-first-party-cookies/ better link on SameSite attribute. Looks like Mozilla were involved :thinking_face:. Don't know enough about IETF process to make judgement on it's viability as a standard. The expiration of nearly a year puts me off though.
https://bugzilla.mozilla.org/show_bug.cgi?id=795346 being pushed for impl...
yada.resources.classpath-resource/new-classpath-resource, it works fine with
bidi.ring/make-handler routes, however once I switch to
bidi.ring/make-handler routes handler (with a handler function which can return
yada.yada/handler classpath-resource, it doesn't work.
It it something to do with bidi's special protocols not working when using
make-handler with a handler function?
Here's what I got to work: http://sprunge.us/PRdE Why would I have to have the handler twice? Perhaps the first one only does the bidi protocol stuff?
Admitedly my handler function could just act as an identity for cond :default.
Just seems strange that the classpath resource needs to be in the routes and not just the handler.
yada.bidi has been brought in. My confusion was that
yada.resources.classpath-resource wouldn't work when I gave it in the handler function.
Even with a
[true :public] entry in routes and a
:default (new-classpath-resource...) in the handler, it wouldn't work.
/api it sends a 200 and an api resposne, and for misc other matching routes, which are defined elsewhere, it'll do some SSR stuff.
The whole issue is that those other misc routes need to be defined elsewhere and included here.
It's more that, I've never seen a cond in use. Oh, it's because you're using :keywords
Oh, basically it's just pairs of if-else's. Each lines starts with a conditional check, then the second expression is what should be done if that conditional is true.
I should be clearer. I've never actually needed to use a cond for this sort of purpose. Normally I have bidi resolve to a handler directly.