feat(connection): have a way to know what is the state of the connection #43
Comments
|
@baczus I think, maybe, changing the reference of the promise during the 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 😄 |
|
How can I determine state of the connection based on promise? |
|
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. |
|
That sounds reasonable. I can't wait to test this change 😄 |
… the promise on the ngStomp service If you want to know if the system is connected or not, you can subscribe to the promise `ngStomp.connectionState.then()` and execute some code. `then` first function will be called if connection is up, `then` or `catch` will be called if connection is down. Don't forget, if you set a long timeOut in setting, the promise won't be fulfilled until we reach this timeOut. Linked to #43
… the promise on the ngStomp service If you want to know if the system is connected or not, you can subscribe to the promise `ngStomp.connectionState.then()` and execute some code. `then` first function will be called if connection is up, `then` or `catch` will be called if connection is down. Don't forget, if you set a long timeOut in setting, the promise won't be fulfilled until we reach this timeOut. Linked to #43
|
@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 |
|
All looks good,but I have two questions.
|
The promise is accessible with
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 If you have idea about it, let me know 😄 |
|
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 |
… the promise on the ngStomp service If you want to know if the system is connected or not, you can subscribe to the promise `ngStomp.connectionState.then()` and execute some code. `then` first function will be called if connection is up, second `then` function or `catch` will be called if connection is down. Don't forget, if you set a long timeOut in setting, the promise won't be fulfilled until we reach this timeOut. If the connection have already been open, the catch method won't be called Linked to #43
… the promise on the ngStomp service If you want to know if the system is connected or not, you can subscribe to the promise `ngStomp.connectionState.then()` and execute some code. `then` first function will be called if connection is up, second `then` function or `catch` will be called if connection is down. Don't forget, if you set a long timeOut in setting, the promise won't be fulfilled until we reach this timeOut. If the connection have already been open, the catch method won't be called Linked to #43
|
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 |
Linked to the issue #42, we should have a method to know if the system is connected or not.
The text was updated successfully, but these errors were encountered: