watson-virtual-agents / client-sdk Goto Github PK

• Add casperjs and test the basic interaction. See this example
• Add code coverage badge. I recommend https://codecov.io/
• Use eslint with 2 spaces indentation. Some of the variables are PascalCase and should be renamed to camelCase. Start with this config
• Add a CHANGELOG.md file
• JSdoc should be generated and updated on each commit using Travis. Every tag and branch should be documented. See http://watson-developer-cloud.github.io/node-sdk/ You can copy the process from here
• Since you are using Webpack, adding babel and es6 won't be a bad idea. Specially due to all the variables that could be constants.

Code review

• sdk.js:34: This whole section there needs some kind of clarification. The use of the regex seems suspect and both vars should be const.

• sdk.js:35: There is no test for this function and this function really needs a test.

• sdk.js:51: Should be const, not var

• sdk.js:97: function start has a required param of botID but the function never checks this id.

• sdk.js:136: there is more of this header stuff here. sending the request id as passed from a function like this makes me think their abstractions are pretty leaky. It would seem that generating a UUID and passing it as an identifier would be less good than simply hashing the payload or doing something else like that. and if it doesn’t matter, then some other method of generating that param should be in order. Ideally, this would be encapsulated at a different level than function by function.

• sdk.js:21: this is where the storage.js file is included. This file is very short. Has no tests. and seems to essentially replicate browser functionality If this is there to polyfill for node, it seems like there are better ways of managing this. as it stands, it look like it just adds complexity to the code without providing a whole lot. It would make more sense to me to have the storage object passed into the main SDK constructor and provide a default implementation or something. Or better yet, this storage should be refactored out of this completely unless there is a really compelling need to have it in there. It adds little value and is used all over the place. There also isn’t a way to substitute my own implementation if I wanted.

• Security notes: There is a comment in the file that the X-IBM-Client-Id should not be made public in a public environment, but then it doesn’t seem to offer any way of hiding it or hints how you might accomplish that.

• I’d defer to @nfriedly on this, but the onError function seems like a waste. The error handling semantics appears to be an artifact of the axios lib (probably an opportunity to switch to fetch). The onError function takes an error and rethrows it. If we're just rethrowing any error that comes in, I don't really see the point of including this in the catch block. This throwing of the error means the implementation needs to try/catch instead of dealing with appropriate http return values. This should be replaced with something that propagates the services errors in a cleaner way instead of re-throwing.The node sdk often has a callback with error args. that’s a lot easier to deal with IMHO.

CC: @nfriedly, @kognate

I get a cryptic: Request failed: eddd8e62-a6b7-4835-b5a2-5748cd529542 on my console while using my app using WVA client-sdk. I'm using a dozen different libraries that could be generating 'request failed'.

I tracked down this message to client-sdk's line 109 on src/sdk.js.

Luckily I figured it was the WVA client-sdk because the other dozen different libraries use the "debug" library which

A) lets me turn debug on and off for libraries
B) tells me which package generated the message

I suggest implementing a proper logging system because no hygenic dev likes their console polluted with random messages.

hello,

Not getting API from
https://developer.ibm.com/api/view/virtualagent-prod:watson-virtual-agent-public:title-Watson_Virtual_Agent

as per the documentation.
Is there anything changed?