Allow Connect to existing enigma connection

[konne]

Description

Issues like #304 and #218 are more complex. Why not implement a new connect to that allows to have an existing enima.js connection as parameter.
So that you can have your own scoped enigma with Mixins, Interceptors and shemas without a conflict,.. but no new websocket connection, because the existing websockt connection is shared.

Some config like delta, url, createwebsocket are just ignored because they are used from the base connection.
There is only one tricky point. If the connection is a sharedConnection the requestID have to be fetched from the main enigma connection and not generated from the own enigma class.

a sample would be:

const config = {
  schema,
  enigma: $scope.model.enigmamodel
  Promise: bluebird,
  mixins: [{ types: ['Global'], init: () => console.log('Mixin ran') }],
};

enigma.attach(config).then((global) => {
  // global === QIX global interface
});

[peol]

Hey @konne! Thanks for the suggestion, it looks interesting and we have discussed similar approaches before. There are a few tricky things we need to figure out:

• There needs to be a delta cache in the "vanilla layer" in enigma.js, otherwise things like delta won't work
  • Scenario: One instance does GetLayout with delta, and another one does GetLayout without delta, this will cause the next delta patch to be a patch of the root object = lots of unnecessary bandwidth
  • Scenario: Both instances are using delta, the first one that does GetLayout get the patches, the next one will get zero patches since engine thinks it's up to date
• Not sure how suspend/resume would behave here, since one instance might want to keep the socket open, while the other wants to suspend it

There are ways around these issues for sure, we'll just have to be careful to not break existing behaviour (and prioritize the feature, of course).

[konne]

Hey @peol, thanks for the longer discussion.
I fully understand now the issue of the delta, because if both enigma.js make a call GetObject("IDXX") they get the same handle from the engine back. I thought that they both get a new handle so we don't have that issue.
I also understand now the issues around the Request & Reponse Interceptors.

Let us see if we can solve the issue with the FRs #218 #304

[ralfbecher]

I have a couple use cases in Qlik Sense client where I would like to hook in existing enigma session inside of an extension to prevent unnecessary rerenderings because of needless fired Validated or Changed events. An Interceptor would be a very good solution, right before the deltaResponseInterceptor here. There are (probably) some hacky ways to do already but would prefer an official way..

[peol]

@ralfbecher If you connect a new websocket to an existing session you'll cause invalidations in the other websocket anyway, but maybe I'm misunderstanding you? We are currently looking into how to properly expose the enigma.js instance/configuration inside the Sense client; there may be changes needed in this library for that to happen, but it's unlikely (it's more of an implementation detail inside the Sense client).

[ralfbecher]

@peol yes, I didn't meant a new websocket connect but rather a hook into the existing session.

[konne]

@ralfbecher I have discussed that feature already in a longer session. The tricky point is the delta mode and that the new enigma don't know the history of the objects.
But I still see the requirement for this feature

[ralfbecher]

@konne that's why I wanted to hook into an existing enigma instance and session..

[peol]

As you know you create an enigma session by enigma.create(), if you want access to this instance it's something that the sense client needs to expose (and working on exposing). It's not a feature in enigma.js per se.