Hi Alexander,
This is an interesting idea. I think passing the emit function in is a good
idea and might make somethings easier in PouchDB. I would rather a map
function looked something like this
function (doc, emit) {
}
I don’t like the idea of passing a userCtx object. That feels overly bulky.
Things like JSON/require are global variables in Node.js or the browser so my
feeling is to follow their lead on those.
I’m not sure what sum does and I’m not aware of isArray. But if those are
helper functions CouchDB creates then I guess their could be a case for passing
them down in some sort of object.
Cheers
Garren
> On 02 Dec 2015, at 12:25 PM, Alexander Shorin <[email protected]> wrote:
>
> Hi everyone!
>
> Following the PouchDB discussion[1].
>
> TL;DR we have quite a lot[2] of functions defined in the global
> context of executed JS functions (map, show, list, etc.). While
> everything is quite simple: read the docs @ use a function, this makes
> life harder if you want to write unit tests for your views, run linter
> over them and so on and basically everyone around tells you to not
> pollute global namespace (:
>
> Another problem with global namespace is that if you call getRow or
> send in a map function (yes, you can) - everything will be ruined.
> There is no reason for you to do that, but you can and that's an
> argument.
>
> Suggestion: deprecate their usage as global things in 2.0 and add one
> more argument for each design function (say, ctx) which will be an
> object of all valuable helper functions for specific ddoc function.
>
> For instance, map functions will take:
> {
> 'emit': emit,
> 'JSON': JSON,
> 'require': require,
> 'log': log,
> 'isArray': isArray,
> 'sum': sum
> }
> For reduce functions you don't need in emit and require (so far). And
> so on. Show/list functions will get their own specific helpers for
> sure).
>
> And it will looks like:
>
> function(doc, ctx) {
> if (doc.tags && ctx.isArray(doc.tags){
> ctx.emit([doc._id, doc.tags]);
> }
> }
>
> Previously, we had PR[3] to make emit function passed explicitly to
> map function. It didn't went too far because it doesn't solves whole
> problem.
>
> Also this will simplify a lot Erlang native query server, so we don't
> have to use closure hack.
>
> Drawbacks are oblivious:
> 1. Function signature change
> 2. We reserve second/third/fifth argument for some service, but very
> useful object
>
> I'm not JS expect, but I think it would be better to pass ctx object
> as first argument if function accepts two (or three in case of
> show/list/update, or five for vdu):
>
> function(doc) { /*old style*/ }
> function(ctx, doc) { /*new style*/ }
> function(newDoc, oldDoc, secObj, userCtx) { /*old style*/ }
> function(ctx, newDoc, oldDoc, secObj, userCtx) { /*new style*/ }
>
> This will make sure that first argument is always an object of
> helpers. If we add ctx as the last one, it makes not oblivious since
> "last" is different things for each design function.
>
> Anyway, thoughts?
>
> [1]: https://github.com/pouchdb/pouchdb/issues/4624
> [2]: http://docs.couchdb.org/en/1.6.1/query-server/javascript.html
> [3]: https://github.com/apache/couchdb/pull/127
>
> --
> ,,,^..^,,,
