Fork me on GitHub
#re-frame
<
2016-08-19
>
superstructor03:08:44

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 ?

superstructor03:08:08

note that project is very much a work in progress, codes not properly tested or fully working yet.

mikethompson03:08:07

I'd imagine anything cookie related should be in the one cookie library

mikethompson03:08:00

I can't see a problem with providing effects and coeffects in the one library.

superstructor03:08:29

Ok cool so would the -fx naming suffix still be appropriate and idiomatic for re-frame library naming ?

mikethompson03:08:03

I think -fx is fine. To me it indicates Effectful stuff.

mikethompson03:08:39

But that's just me. I might be too close to all this to see clearly

mikethompson03:08:01

So your judgement might be better 🙂

superstructor03:08:12

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 ?

mikethompson03:08:43

Probably safer to only need to require one

mikethompson03:08:43

Best to avoid any subtlies

mikethompson03:08:09

If it is subtle for you, the author, then it will be completely invisible for anyone else

superstructor03:08:43

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.

mikethompson03:08:59

That's REALLY cool

mikethompson03:08:13

It will be exciting to see this all coming together

superstructor03:08:19

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.

martinklepsch07:08:42

The new /docs/ look amazing, looking forward to reading them!

ikitommi08:08:58

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.

ikitommi08:08:46

we are doing end-to-end interceptor apps, would be easier to reuse code between frontend & backend.

mikethompson08:08:30

I'm going away for the weekend.

mikethompson08:08:34

Back in 2 days 🙂

ikitommi09:08:18

oh, but congrats!!

ikitommi09:08:23

we can now map the interceptors between, as they are just data.

martinklepsch12:08:24

With the current interceptors design I'm still wondering: how can you create multiple effects of the same type/id?

lwhorton14:08:25

not sure I understand what you mean @martinklepsch?

mbertheau14:08:00

@lwhorton: What if you have a handler that needs an effect two times with different parameters each time?

polymeris20:08:22

Hi. What's the proper way to test functions that should dispatch events? The wiki does not talk about that case, as far as I can tell. I suppose one could do it using a combination of with-redefs to mock the handler and cljs.test/async. Any other suggestions?

polymeris20:08:06

Nvm... seems that with-redefs doesnt play nice with async calls 😕

polymeris21:08:49

wait...can I just overwrite the handler re-registering it?