mcoakley
commented
7 years ago As I'm writing more tests for coverage I realized that I could make the Web Server feature a plugin by changing the calling structure of the plugins based upon a "plugin type". This won't break any existing code for plugins and will allow someone to write a web service type plugin as robust as they would like it.
I've refactored the _from method to allow this and have made some other simplifications but I have a question...
_from = function () {
var collection = null;
var callback = null;
var collectionsLen = collections.length;
if (arguments.length === 0) {
return this;
}
if (arguments.length === 2 && isFunction(arguments[1])) {
collection = arguments[0];
callback = arguments[1];
if (isString(collection)) {
throw new Error("Web service calls no longer directly supported. " +
"Use the fromWebService plugin for this type of call.");
}
collections.push(collection);
} else {
for (var index = 0; index < arguments.length; index++) {
if (arguments[index] === null ||
arguments[index].length === 0 ||
isFunction(arguments[index]) // We don't support async here
) {
continue;
}
collections.push(arguments[index]);
}
}
if (collections.length > collectionsLen) {
collections.func = "from";
result = flattenCollection(collections);
}
return (isFunction(callback) ? callback : this);
}It appears that there is still a possibility of calling a callback but I'm not sure of the calling structure or why it would be used. NOTE that this is in line with the original code there is a case where you can call the _from method with 2 parameters and the first parameter isn't a string but the second parameter is a function which would mean that a callback will be called at the end. Can you let me know why this would be the case and how it would be used?
fordth
As I'm working through the testing of the system and moving towards more flexibility with the testing as well as full coverage I'm looking hard at the Web Service feature within jinqJs. While in simple cases I can see the need for the service - in production applications I would imagine it wouldn't be used much if at all. The reason I'm saying this is because more often all service calls will be abstracted away in order to provide consistent handling. This means that using the jinqJs web service function would create an outlier within the code base of an application. Additionally, the current implementations of the web service calls do not implement graceful handling of error conditions - therefore the implementations need to be augmented to handle these cases. At that point, the implementation of those methods becomes opinionated and may preclude the entire library from being used within an application.
I believe it would be cleaner to remove the functionality and simply require that users provide valid data to the library for the library to manipulate.