This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-19
Channels
- # admin-announcements (2)
- # beginners (25)
- # boot (93)
- # cider (2)
- # clara (2)
- # cljs-dev (63)
- # cljsjs (3)
- # cljsrn (38)
- # clojure (142)
- # clojure-austin (1)
- # clojure-brasil (2)
- # clojure-czech (1)
- # clojure-dev (7)
- # clojure-greece (1)
- # clojure-russia (170)
- # clojure-spec (11)
- # clojure-uk (65)
- # clojurescript (46)
- # clojurex (1)
- # code-reviews (3)
- # cursive (11)
- # datomic (35)
- # euroclojure (6)
- # events (2)
- # flambo (2)
- # hoplon (115)
- # instaparse (11)
- # jobs (21)
- # jobs-rus (3)
- # lambdaisland (2)
- # off-topic (17)
- # om (35)
- # onyx (161)
- # planck (1)
- # protorepl (7)
- # random (1)
- # re-frame (31)
- # reagent (19)
- # ring-swagger (21)
- # rum (5)
- # spacemacs (3)
- # specter (25)
- # test-check (20)
- # testing (7)
- # untangled (2)
- # yada (50)
when publishing related fx and cofx handlers, would you expect those to be provided in one project/jar @mikethompson ? E.g. https://github.com/SMX-LTD/re-frame-cookies-fx would provide a coeffect for getting cookies, and effects for setting or removing/expiring cookies. Or different projects ? Or just different namespaces for fx vs cofx ?
note that project is very much a work in progress, codes not properly tested or fully working yet.
I'd imagine anything cookie related should be in the one cookie library
I can't see a problem with providing effects and coeffects in the one library.
Ok cool so would the -fx
naming suffix still be appropriate and idiomatic for re-frame library naming ?
I think -fx is fine. To me it indicates Effectful stuff.
But that's just me. I might be too close to all this to see clearly
So your judgement might be better 🙂
Yep I can’t think of a better option either. Lastly, would you expect to have to require different namespaces for fx vs cofx, or just require one ns to get all of it ?
Probably safer to only need to require one
Best to avoid any subtlies
If it is subtle for you, the author, then it will be completely invisible for anyone else
Sounds reasonable :thumbsup: Thanks for the feedback. I’m currently working on testing and publishing the following: re-frame-cookies-fx
, re-frame-document-fx
(page title, mount root etc), re-frame-styles-fx
(inject css as an effect) and so forth.
That's REALLY cool
It will be exciting to see this all coming together
I’ve got permission to publish any cofx or fx handlers from our commercial app, as generally you wouldn’t expect it to be domain specific but generally useful tooling for any app.
The new /docs/ look amazing, looking forward to reading them!
hi. interceptors seem to have :before
and :after
. Would it be a possible to use the already familiar :enter
and :leave
instead? Many Clojure libs use that naming on the backend already.
we are doing end-to-end interceptor apps, would be easier to reuse code between frontend & backend.
v0.8.0 released about 5 mins ago https://github.com/Day8/re-frame/blob/master/CHANGES.md#080--20160819
I'm going away for the weekend.
Back in 2 days 🙂
@ikitommi sorry bad timing.
With the current interceptors design I'm still wondering: how can you create multiple effects of the same type/id?
not sure I understand what you mean @martinklepsch?
@lwhorton: What if you have a handler that needs an effect two times with different parameters each time?