why isPlainObject?

[Santinell]

Why you use isPlainObject in handlerCacheFromDir?

I want use complex Objects for controllers. In ideal - ES6 classes.
for ES5 Object methods can be used _.each
for ES6 classes is needed workaround.

[whitlockjc]

I use isPlainObject because the API expects a map of key/value pairs. I can relax things a bit to let you pass in a class instance but in 1.5 years, this is the first request so I'm not sure how useful it would be other than to you.

[Santinell]

Hmm... i think i can generate map and use it in options.controllers

[whitlockjc]

I'm closing this for now but if you get something in mind for class-based stuff, let me know. Also, PRs are appreciated. :)

[pixelshaded]

+1 to this. We use typescript to generate our controllers and were exporting instances of a class which is not compatible with isPlainObject. Means we can't create controllers that inherit from other controllers. isPlainObject is very limiting.

[whitlockjc]

I don't mind changing isPlainObject as it really doesn't need to be that specific, if possible.

[pixelshaded]

yes but isObject allows arrays, functions, regexes, new Number(0), and new String('') which I don't think you accept.

[pixelshaded]

the work around for us may be to use _.toPlainObject on the instance before exporting, but I dont know how that might affect the 'this' inside method.

[whitlockjc]

Well, that's why I did this in the first place. It use to be isObject. I'll figure something out.

[pixelshaded]

I tried _.toPlainObject and it destroyed the references to 'this'. This project was actually passing in a map object with instances before. I was refactoring to the use the folder convention instead and thats when stuff stopped working.

[pixelshaded]

could always brute force it:

if (_.isObject(controller) && !_.isArray(controller) && !_.isFunction(controller) && !_.isRegExp(controller) && !_.isString(controller) && !_.isNumber(controller))

[whitlockjc]

That's ugly but if that's what I have to do because there is no other option, I don't mind.

[pixelshaded]

I've been looking around for some solutions. This may work and be the cleanest:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/toString#Using_toString()_to_detect_object_class

Object.prototype.toString.call(controller) === '[object Object]'

Interally this comes from an inaccessible property [[Class]] and possible native values are:
http://stackoverflow.com/questions/3250379/what-is-the-call-function-doing-in-this-javascript-statement/3250415#3250415

"Object"
"Array"
"Function"
"Date"
"RegExp"
"String"
"Number"
"Boolean"
"Error" for error objects such as instances of ReferenceError, TypeError, SyntaxError, Error, etc
"Math" for the global Math object
"JSON" for the global JSON object defined on the ECMAScript 5th Ed. spec.
"Arguments" for the arguments object (also introduced on the ES5 spec.)
"null" (introduced just a couple of days ago in the ES5 errata)
"undefined"

[pixelshaded]

Actually I was slightly wrong on it working before. Before we had our own middleware imlementation: we would get the operation and controller info from the meta data middleware and use that to check for the existence of said method on controller and then execute it. It seems that swagger-router looks at the object and scans every property to put it in a handler cache. This means that every property on the controller must be a function. Since our controllers are classes, they may have some members that aren't functions. This is causing throws on start up. I may just need to revert back to our custom router. We were only using swagger-router for stubs.