Fork me on GitHub
#re-frame
<
2017-08-04
>
mikethompson00:08:14

@ag A. If I understand you correctly, you are asking that (subscribe :query-id) be interpreted as (subscribe [:query-id]) B That would certainly be a win in some cases ... but it isn't a complete win because there are some annoying tradeoffs C. How should the following be interpreted (subscribe :query-id something): - (subscribe [:query-id something]) or - (subscribe [:query-id] something) This will only get worse in the future because we may well introduce a further argument (if ever we move re-frame from a framework to a library)

mikethompson00:08:45

But it sounds like this tripped you up. Is there a better error message that we should supply perhaps? I'm assuming we actually catch this and report it.

ag01:08:59

What's the difference between last two things? I personally probably would like re-frame to error out only when there's ambiguity

ag01:08:54

When there's only a single key IMO there's no ambiguity

frederic21:08:38

Hi there! Does anybody here know if I’m allowed to return functions from a re-frame subscription?

frederic21:08:21

I seem to remember that I must only return ‘plain data’, nothing fancy such as functions.

frederic21:08:32

But I can’t find that in the documentation.

frederic21:08:50

Maybe my information is out of date or just plain wrong

musheddev21:08:17

Try it! It works in my case, but I don't know about comparability weather (a=a and a!=b) holds true which is probably important.

jfntn23:08:23

@mikethompson haven't seen many people request this, but would you consider adding support for global interceptors registration?