898 save app state version 4

[chlebowa]

Extension of #1011

Five key objects are copied to the app session's userData: slices_global, filtered_data_list, mapping_matrix, snapshot_history, and state_history.
These objects can now be used and modified from any module.

There are multiple implementation within this one draft. Use the SHAs to checkout the one you want to see.

first implementation (f987c04)

Introduced a function set_intermodule_objects that sets these objects in the scope of a module:

• checks if an object exists in session
• if YES, assigns a copy in module environment (by reference)
• if NO, creates the object
  This function is dirty as all hell, it depends on state and has side effects. Possibly is buggy.

set_intermodule_objects is called in filter manager, snapshot manager, and state manager so that the key objects can be created and used. Passing them as arguments is no longer necessary.
Note this is discouraged by shiny but perhaps it will allow us to do some things otherwise impossible.

The problem with the first implementation is that set_intermodule_objects contains all routines for setting the key objects and thus the default value of the key objects is separated from the module that uses it. It would be better if they (the routine and the module) can be kept in one file. Therefore, a need arises for a way to send such routines to a place where they can be accessed by all modules.

second implementation (3f79bb2)

Introduced a dedicated setter function for every key object (five in total). These setter functions work much like set_intermodule_objects in the first implementation. They are defined in the same file as the modules in which the key object is created, along with all necessary utility functions for better maintainability.

Introduced R6 class GlobalSetter as a hub for the setter functions.
The GlobalSetter class has two methods:

• $add_setter: register function that sets global object
• $set_global: call setter function to set global object
  A singleton GlobalSetter, GS is created in the package namespace (assignment is made in zzz.R). From there it be accessed by all modules.
  Every module can register a setter function for the key objects that it creates in GS. Every module can use GS to call a setter function.

ISSUES

• update*Input is still a problem.
• application opened from bookmark still lacks the most recent bookmark (itself)

[gogonzo]

This class unnecessary complicated the whole process of setting userData$. userData is a singleton itself (on the session level) and doesn't need extra class to handle the process.
GlobalSetter doesn't make it more robust as setter_ functions are vulnerable. See the comment insetter_mapping_matrix.

I suggest to remove GlobalSetter and fix setter_xyz to use formal arguments instead of dynGet. Apart from this, utilization of userData is reasonable. Alternatively I can imagine R6 TealSingleton class to control mapping/snapshot/states and whatever exist i a future. However, I would keep it simple now to at least have a POC of bookmarking.

[gogonzo]

Seemingly independent function requires always to be called in the environment where filtered_data_list and slices_global exists (or will exist in the moment of a evaluation). This is not just unsafe but also too complicated.

[chlebowa]

Seemingly independent function

Where did you get that idea? 😆
All of this is extremely impure but If we are to share objects between modules, there is no way to do it in a pure way.

[gogonzo]

Existence of GlobalSetter complicates this as well. Optimally function setter_mapping_matrix should be called once and it shouldn't check whether values are set or not.

Suggested change

	} else {
	sesh$userData$mapping_matrix
	}