This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-02
Channels
- # beginners (29)
- # boot (65)
- # cider (12)
- # cljs-dev (8)
- # cljsjs (31)
- # clojars (5)
- # clojure (147)
- # clojure-austin (47)
- # clojure-berlin (1)
- # clojure-brasil (7)
- # clojure-russia (5)
- # clojure-spec (18)
- # clojure-uk (18)
- # clojurescript (113)
- # css (2)
- # cursive (7)
- # datascript (5)
- # datomic (2)
- # dirac (4)
- # events (3)
- # funcool (143)
- # hoplon (287)
- # jobs (2)
- # off-topic (4)
- # om (10)
- # om-next (5)
- # onyx (18)
- # protorepl (1)
- # re-frame (93)
- # reagent (34)
- # rum (41)
- # test-check (51)
- # untangled (15)
- # yada (18)
please RT to get the word out
nice, congrats @malcolmsparks
RE: yada/lean not having SSE support. Is that just because core.async is being kept out & the current SSE api revolves around it?
So I could still return an async response of some kind, using something manifold-compatible and include the data:
prefix (or use yada/async)
@dominicm - yes, it's to avoid the clojure.core.async dependency. The idea is that lean
shows you how to start from a bare-bones yada and build it up (lean actually brings in bidi and aleph).
yada/core only depends on a small set of dependencies (manifold, schema, byte-streams, clj-time, ring-core, hiccup)
It's really for advanced users, and specifically requested by @jeroenvandijk but others have also complained about the number of dependencies involved in the full 'batteries-included' yada - this provides another option
yada beginners and existing users can just continue as before and use [yada "1.2.0"]
- there should be no breakages for those who have only depended on the public API (in yada.yada).
I'll be more deliberate in future in steering people to use yada.yada rather than requiring functions from other yada namespaces - that said, the upgrade path for the majority of existing users should be seamless
I'm trying really hard nowadays not to break compatibility, there's a lot of features planned for 2017 and I'll try to bring all these in without introducing upgrade hurdles for existing users
The tricky one will be clojure.spec - this recent refactoring has one eye on that transition...
I was just contemplating how a clojure.spec integration could happen for query params more easily now.