Fork me on GitHub

@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)


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.


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


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


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


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


But I can’t find that in the documentation.


Maybe my information is out of date or just plain wrong


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.


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