Constructors should not cause side effects

[viglucci]

Hi @agsh, first I would like to say; great package! Thank you for taking the time to put this together and for sharing it with all of us!

I've been playing around with your package lately as I learn more about the vast world of streaming IP security cameras, and for the most part, your library has worked great, and my issues have lied elsewhere.

However, in integrating with your library I have hit some integration pain points with the API that it exposes. The first being that the model objects exposed (Cam in this example) cause side effects when they are instantiated.

new Cam({
 hostname: <CAMERA_HOST>,
 username: <USERNAME>,
 password: <PASSWORD>
}, function(err) {
 // camera has connected
});

In the above example, the connect prototype method is called in the Cam constructor, which causes side effects such as firing network requests, etc.

In general, this is considered bad practice, as it prevents the consumer from separating the creation of objects, and the invocation of methods which cause side effects.

A more preferable pattern would be:

const camera = new Cam({
 hostname: <CAMERA_HOST>,
 username: <USERNAME>,
 password: <PASSWORD>
});

camera.connect((context) => {
 // camera has connected
});

Would you be open to a pull request that changes this behavior for Cam and other classes?

If so, I would recommend that once the PR was merged, a new major version of this package would be required, as changing the constructor behavior would be a breaking change to the current API contract.

Thanks for your time.

Resources for reference:
http://blog.millermedeiros.com/constructors-should-not-cause-side-effects/
https://stackoverflow.com/a/31392273

[fbertone]

I agree with you

[chriswiggins]

Closing out old issue - we've just merged in an autoconnect PR that addresses this