[Solved] Question about promises

---

Hi,

i had a quick question about promises.
i’m still quite new to the concept. I understand the principle (not that hard )
But one of the things i’m still struggling with is: How and when are they resolved?

in my case, i’m developing a new Kodi plugin, with a different library. That lib is a lot cleaner and works perfect with promises.

But my issue:
The library returns a connection through a promise, which is great!

But i need to access that connection on multiple places in the plugin. like sending commands to Kodi.

At this point i set the connection from the promise to a local variable that i use later in the plugin at a different command.
Which of course is ugly as hell

i do not want to initialize a new connection on each command i send.

current way:

KodiApi(@config.host,@config.port).then (connection) =>
        @kodi = connection

And further on i use “@kodi” to send commands to the connection.

KodiApi(@config.host,@config.port) returns a promise. is it better to store this promise in a variable and use that one every time?
or does it then reconnects every single time?

like:

@kodi = KodiApi(@config.host,@config.port)
@kodi.then (connection) =>
  #first commands here (listeners)


@kodi.then (connection) =>
  #send commands
  connection.send bla bla

In the example above, does it use the same connection for both of the code parts? or does it resolve the KodiApi twice, and also opens a connection twice?

if so, that would be the best way to do this?
Check if the variable has been resolved, and no errors before executing a command?

@Fjux I would create a class e.g. KodiService which provides the service methods you require throughout your plugin (think of this as a wrapper around the KodiAPI). If multiple devices need to share the KodiService you can instantiate it as part of the plugin initializer and pass it on to device instances.

Inside the KodiService you can maintain the internal connection state to make sure, you only need to create the connection once (and perhaps provide a reconnect if the connection dies for whatever reason). As part of the service method implementations you could use an internal method, e.g. _acquireConnection() which builds the connection or simply returns the already existing connection. Needless to say, the _acquireConnection() should also return a Promise and the
KodiService service methods as well.

The following is just some pseudo code I have sketched making wild assumptions about the KodiAPI.

_acquireConnection: ->
      return new Promise((resolve, reject) =>
		if connected
			resolve connection
		else
			# make a new connection
			newConnection = kodiAPI.connect().then( (newConnection) =>
				connected = true
				connection = newConnection

				connection.on "disconnected", (() =>
					connected = false
					connection = null
				)

				resolve connection
			).catch( (error) =>
				reject error
			)

@mwittig Thanks!

to bad it is only possible with something like this, but your solution above is exactly what i had in mind, if i couldn’t get it working without using the promise.

Now looking for some time to implement it

@Fjux
solved?

@leader21 said:

@Fjux
solved?

Yes, should i close the topic in any way?
if so: How?

@Fjux
we decided to not close any threats, but if an issue / threat has been solved it can be marked as “solved”.
for that, you’ll have to put [Solved] in front of your headline text. just have a look above, i already did so

@leader21

Will do that if i have someting similar going!

New question:

i just found out that the librarys i was using were using the built in promise of NodeJS.

But the default nodeJS version of Pimatic runs on V10.xx and that does not support it yet.

Now i made a small test and forced those packages to use bluebird.
But as they are 2 seperate libs, i needed to add bluebird twice as an external library.

Which seems a bit over kill. i noticed that the pimatic framework makes it possible for a plugin to load the bluebird lib from Pimatic instead of having to install it per plugin.

Can i do something similar for librarys that do not depend on Pimatic?

@Fjux said:

Can i do something similar for librarys that do not depend on Pimatic?

Yes, you can! See promise-retryer, for example, which is used by pimatic-openweather plugin.

  Promise = env.require 'bluebird'
  PromiseRetryer = require('promise-retryer')(Promise)

@mwittig said:

@Fjux said:

Can i do something similar for librarys that do not depend on Pimatic?

Yes, you can! See promise-retryer, for example, which is used by pimatic-openweather plugin.

  Promise = env.require 'bluebird'
  PromiseRetryer = require('promise-retryer')(Promise)

i don’t think i meant something like this.

i thought it was a bit overkill that every library i use needs to have its own Bluebird plugin in their own node_modules folder.
i was asking for a way to have 2 libraries share their bluebird module.

like the plugins of pimatic are doing (i think) through the env.require ‘bluebird’. As my own plugin does not need to have bluebird as pimatic already has it.

@Fjux said:

i was asking for a way to have 2 libraries share their bluebird module.

But this is exactly what it does. Pimatic-openweather shares its bluebird module (which it got passed in from pimatic via env object) with with promise-retryer. This way, promise-retryer does not depend on bluebird by a module dependency via package.json. Instead, the bluebird library is passed on to an initializer function (similar to env.require) of the promise-retryer module. If you want to pass multiple modules you can have look at the env implementation - https://github.com/pimatic/pimatic/blob/master/startup.coffee

@mwittig
I understood what it does for pimatic. which is great.

But my “problem” is this:

my Plugin, uses a Library. That library needs Promises (bluebird in our case because V0.10 does not have it integrated)
And that library is using another library that also needs Promises, and again the same case as above.

So this means:

• Pimatic + bluebiurd
  • my plugin, Shares bluebird with pimatic
    • library + new bluebird
      - library’s library + new bluebird.

and that seems a bit overkill but i don’t see any other way to do it. As those libraries also need to work for other systems

@Fjux I don’t see any other short-term solution than forking all the dependents and make sure you pass-through bluebird downstream from pimatic.

May be you can convince the maintainers to address the backwards compatibilty issue (no native Promise implementation with node 10) and to adress the need of injecting a Promise implementation of choice in some scenarios. There is a library which appears to handle this - have a look at i-promise. See README section “Preferring user implementation over native” :

" … Default behavior is to always favor native implementation if found. You can still favor the implementation of your choice without overriding global Promise:

require('i-promise/config').use(MyPromiseImplementation);

NB: It is possible to inject dependencies at runtime - see “rewire” for example, but I won’t recommend this for production code, It is mainly for testing purposes if you need to replace parts of the implementation with mockups.

Yeah thats to bad.

Will keep it like it is now!