This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-01
Channels
- # bangalore-clj (1)
- # beginners (16)
- # bigdata (1)
- # boot (16)
- # cljs-dev (79)
- # cljsjs (37)
- # cljsrn (62)
- # clojars (1)
- # clojure (260)
- # clojure-austin (3)
- # clojure-dev (3)
- # clojure-dusseldorf (3)
- # clojure-italy (1)
- # clojure-russia (32)
- # clojure-serbia (2)
- # clojure-spec (8)
- # clojure-uk (146)
- # clojure-ukraine (16)
- # clojurescript (66)
- # cursive (27)
- # datomic (57)
- # dirac (124)
- # emacs (10)
- # hoplon (12)
- # juxt (6)
- # keechma (6)
- # lein-figwheel (18)
- # leiningen (6)
- # lumo (51)
- # off-topic (1)
- # om (66)
- # onyx (41)
- # perun (1)
- # play-clj (1)
- # protorepl (9)
- # re-frame (20)
- # reagent (11)
- # ring (4)
- # ring-swagger (10)
- # rum (22)
- # specter (8)
- # sql (2)
- # test-check (5)
- # untangled (27)
- # yada (29)
[true (yada/as-resource nil)]
gives me 404 status with default error page, [true (yada/as-resource (io/resource "asciinema/errors/404.html"))]
gives me my custom error page but the status is 200
to get status 404 with custom page should I use sth like [true (yada/resource {:properties {:exists? false} :responses {404 {:response (fn [] ...)}}})]
?
Not really. Ring middleware is synchronous
But you write something that wraps in a chain
But that's really what interceptors are doing
hmm, but I wouldn't be modifying the existing response (which could be manifold deferred in other cases indeed) , as in this case the whole response is nil
I know that ring middleware is not really compatible with yada in most cases (when it modifies the response), but in this case should be fine imo
Except for error scenarios
if you're happy that there's no change of any deferreds coming out of your yada interceptor chain, then it is safe
ah, I see
so you're trying to do
[true (yada/as-resource nil)]
but with a custom 404?in which case, you can return a custom 404 page in your response function
so the middleware wrapping option would be when I don't have [true ...]
in my bidi tree at all
(fn [ctx] (assoc (:response ctx) :status 404 :body "..."})
that will override the status to 404
you can write that resource once and use as a backstop in your bidi tree
I'm doing similary, yeah (I created my wrapper for yada/resource
), but what I'm trying to solve now is the 404 on the routes level
so either [true (yada/resource {:produces "text/html" :response (fn [ctx] (assoc (:response ctx) :status 404 :body "..."})})]
or wrapping bidi tree (coerced to handler) with a middleware which checks whether response is nil
and then returns custom 404 error response
sounds fine to me
btw, if I want to report exceptions to external service (Bugsnag) I can safely do that from :logger
fn, right?
I think others are doing something similar