feat(connection): have a way to know what is the state of the connection

[davinkevin]

Linked to the issue #42, we should have a method to know if the system is connected or not.

[davinkevin]

@baczus I think, maybe, changing the reference of the promise during the connection error fallback could help you, you'll always a promise initialized, but the resolve / reject happen only after the next ngStomp.connect() method.

In this way, I just have to move the init of the promise, and if I forget nothing, you can check the state of the connection by accessing the promise itself. I'll expose the promise around a getter to have something more simple (in term of api), but I think this could be a good idea.

Do you see something wrong with this idea ? Don't hesitate 😄

[baczus]

How can I determine state of the connection based on promise?

[davinkevin]

By using the then function ? Like this :

ngStomp.getConnectionState()
    .then(callbackCalledIfConnected)
    .catch(callbackCalledIfNotConnected)

This way, instead of using a boolean, which reflect the $$state of the angular $q promise, we can use the promise itself.

[baczus]

That sounds reasonable. I can't wait to test this change 😄

[davinkevin]

@baczus : Could you try to see if this modification feet your need.

I've updated the master but not yet released it, I'm waiting to see if it's all ok for you. To try this version, you just have to get the version available in the /dist/ folder.

[baczus]

All looks good,but I have two questions.

1. What about function which returns connection state (promise)?
2. Does function initConnectionState should not be set as private (with $ at the beginning)?

[davinkevin]

1. What about function which returns connection state (promise)?

The promise is accessible with ngStomp.connectionState. It's not a function, just a reference to the promise itself.

1. Does function initConnectionState should not be set as private (with $ at the beginning)?

The problem with this, and what I don't like in this solution, is if someone want to init a connection by itseft (for example, after an intentional disconnection), he should call initiConnectionState and connect after it... And, I don't think this is a good solution after all, but I don't find a better way to do that right now. Because of that, the two method should have the same visibility, both private or public. Right now, I've choose public, but I'm thinking about a better way to do that...

If you have idea about it, let me know 😄

[baczus]

I don't think it's a good idea to force user to invoke two methods in situation when he wants to set new connection. Maybe a better solution is creating one public method connect, which internally will invoke private methods $initConnectionState and $connect?

[davinkevin]

I've published the 0.9.3, with this improvement, but I still think there is a better solution for this...

One promise is used for the connection, resolved in the success callback and reject in the error callback. But, both can be called by the lib, so I begin to think it should be handle by two different promise.

And, to get the connectionState, something like the Promise.race or $q.all on both promise to have the general state of the connection...