This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-09
Channels
- # admin-announcements (5)
- # architecture (8)
- # beginners (7)
- # boot (41)
- # braveandtrue (1)
- # cider (77)
- # clara (3)
- # cljs-dev (56)
- # cljsjs (7)
- # cljsrn (7)
- # clojure (44)
- # clojure-austin (3)
- # clojure-brasil (1)
- # clojure-hk (3)
- # clojure-russia (137)
- # clojure-spec (14)
- # clojure-uk (44)
- # clojurescript (33)
- # cloverage (3)
- # core-async (10)
- # css (1)
- # cursive (16)
- # datomic (116)
- # devcards (14)
- # emacs (1)
- # events (1)
- # funcool (2)
- # functionalprogramming (1)
- # hammock-driven-dev (1)
- # jobs-rus (124)
- # lein-figwheel (1)
- # leiningen (1)
- # liberator (4)
- # melbourne (3)
- # mount (73)
- # off-topic (3)
- # om (4)
- # om-next (15)
- # onyx (38)
- # other-languages (4)
- # perun (2)
- # proton (36)
- # protorepl (2)
- # random (1)
- # re-frame (56)
- # reagent (7)
- # specter (4)
- # testing (1)
- # untangled (13)
- # yada (18)
One thing I've found with liberator is that it's much more flexible to just (def my-resource { ,,,, })
as a map and defer constructing the resource
until you wire it up with your routes etc... rather than use defresource
.
Curious if others have settled into this pattern too... and wondering whether the docs should downplay or perhaps even deprecate defresource
I use this all the time. defresource
was a bad idea in the end but defxxx
macros had been en vogue at that time.
Yeah I remember 🙂 and we've all been guilty of writing our own brittle variants of defxxx
...
It would be good for the docs to eventually emphasise the map/data nature of resources... .that's the new vogue right? 🙂
I think the current docs might encourage people to think of resources in the wrong way - a few weeks ago we went through a code base and removed all def
'd resources and only def'd the maps... so we could make things more flexible