Deprecate Container.setAutoReconnect(), Container.resume(), IContainer.connected, and IFluidContainer.connected.

[scottn12]

As described in #8745, the following APIs will be deprecated.

Contianer.setAutoReconnect()

This function is being deprecated to keep the reconnection logic internal. To replace its functionality, Container.connect() and Container.disconnect() were introduced.

Container.resume()

This function is essentially being renamed to Container.connect(). This is done to provide developers a more intuitive API to connect a container. To avoid duplicate functionality, this function will be deprecated and removed.

IContainer.connected

This API serves the same purpose as IContainer.connectionState, and therefore will be deprecated and removed.

IFluidContainer.connected

This API serves the same purpose as IFluidContainer.connectionState (newly added), and therefore will be deprecated and removed.

[vladsud]

We are also introducing the callback argument to provide additional control for the developer. This callback function will be required when the mode is set to Custom and will evaluate as a boolean. If the value is true then the container will reconnect, and if false it will not. This allows the developer as mechanism to control when a user is or is not reconnected based on information which the developer has access to, but Fluid does not.

I think what you are trying to say is that developer wants pull model (FF asks it) vs. push model (developer changing auto-reconnect property as new data on his/her side arrives).
Before making API more complex, I'd love to understand why we believe we need to introduce more complexity and allow polling.

I have bigger issues with continuing to introduce these things on Container - I believe things like that should be exposed on Loader object, such that they apply to all containers under same context (here, "context" object is a loader, I do not think we need another context object). That way, it works great for things like guest components, where container points to a component from another container, and thus child container is loaded under same loader - doing operations on one container will miss this kind of scenario).
Developers should have ability to create any number of custom contexts (loader instances) and thus control the scoping of such policies.

[ssimic2]

This is a good point to consider.

If we do this at a loader level, is it still a natural place to inject callback? (Consider more complex FFX use cases around host apps). Also, maybe elaborate on "information which the developer has access to", so it's clear what those can be.

If the container is disconnected (say for an inactive tab), and you come back to it, what/who initiates reconnections?

[vladsud]

I do not understand why callbacks are needed, so I can't answer that question. Access to information does not matter here though, as you can achieve same thing - the question is really why pull model is preferred over push, IMHO, and is this difference warrants more complicated API? Is there an example of scenario demonstrating it? I have not seen one.

Today, in FFX case, I believe OWH code initiates reconnect, I believe they use React capabilities to learn if user is there (any input generated), though I believe browser has similar capability (at global level).

[ssimic2]

Comments were for @scottn12 to clarify "information which the developer has access to", to understand need for callback. Scott - is this is all around "user inputs"?

[scottn12]

Yes, user inputs such as mouse movements or clicks which are not accessible by Fluid. There may also be other relevant information, such as browser tab focus, for example. That said, based on feedback I received we probably won't be refactoring setAutoReconnect() after all, and I'll be updating the main issue shortly.

[scottn12]

FYI, this issue has been updated to reflect the changes in #8745