Define and implement more stable API

[madroneropaulo]

Currently the way to extend the package is by overwriting public methods. This is not scalable and not safe as different parts of the project may overwrite the same method without a clue of that. We should change that either by passing the extended function as a callback or implementing some EventEmitter pattern.

//Current
public isError(payloadType): boolean {
        //Overwrite this method by your buisness logic
        return false;
    }

//Proposal 1. Callback
public onError(callback: () => any): void {
   callback.call()
}

//Proposal 2. EventEmitter
public subscribe(eventType: EnumEventTypes, callback): void {
  //Add callback to event type
}

Im more prone to the first proposal, as it is less intrusive for this package. The second one only adds more complexity. More proposals are welcome.

[madroneropaulo]

So the final API decided from a PR presented on a team meeting, considering the amount of options for message handling looks like this: ConnectTs API

//INTERFACES
interface SendCommand {
    message: any; //Message to be sent
    guaranteed?: boolean; //Will send the message as soon as the connection is established
    multiResponse?: boolean; //If true, will *not* unsubscribe handler. Consumer will have to unsubscribe manually
    onResponse?: (data?: any) => void; //Handler. Data response received, will unsubscribe by default after first response as it is the most common use-case. If not present no handler will be subscribed.
    onError?: (err: string) => void; //Triggered when an error occurs before a message could be sent
}

interface Subscription {
    unsubscribe: () => void;
}

//PUBLIC METHODS
sendCommand(command: SendCommand): Subscription;
addPushEventHandler(pushEventHandler: (pushEvent: any) => void): Subscription;

//DEPENDENCIES INTERFACES (Passed in constructor)
interface Adapter {
    send: (data: any) => void;
    onOpen: (callback: () => void) => void;
    onData: (callback: (data: any) => void) => void;
    onError: (callback: (err: any) => void) => void;
    onEnd: (callback: () => void) => void;
}

The adapter interface will be the same as https://github.com/spotware/connect-js-adapter-tls/blob/master/index.js#L17 The method "connect", however, it's not relevant for us and the connection logic is up to the adapter.

Also, the coding/decoding logic has to be moved to the adapter, as connect-ts will only contain message id handling logic.

[madroneropaulo]

Closed on commit aa589dc