Tech: Centralize all user settings in single service that also handles cascading.

Feature Request

Description

This is a tech story with no value for the user, but still important for future features.

The single service centralizes all settings a user can set. Modules are notified of changes using something like rx.js.

Cascading means that settings can overwrite each other if they are from different sources. F.ex. the default settings can be overwritten by url parameters.

TODO

• map is immutable, take map out of settings, markingPackage in settings instead in map
• Simplify settings to only handle getting and updating settings from partial settings objects
• Updated settings object, which uses three sub-objects. See interface codeCharta.model.ts#L32
• Create codeCharta.model.ts file which holds all globally needed interfaces
• Create codeCharta.service.ts file which combines simplified functionality from former codeCharta.component, data.service, data.validator.service, data.loading.service. The codeCharta.service.ts get called from codeCharta.component and is supposed to be the global connection to the core functionality like onLoadApplication
• Deleted data.service, data.validator.service, data.loading.service
• Implement ScenarioService behaviour onLoad and onFileImport(?)
• Merge fileSettings from visible CCFiles into settingsService.settings.fileSettings
• Check if #352 is fixed
• Implement UrlUtils which updates the settings. Don’t forget about the mode=Delta
• Update content of the dialog when clicking URL Parameters button inside sidebar. Only show file and mode keys
• Remove URL Parameters functionality from UrlLUtils and SettingsService, but keep option to import files and set a mode (renderState) from within the url
• Adapt the new settings/fileState/metric behaviour step by step to the UI components
• Adapt all tests and try to follow the scheme for setting all objects like nodeContextMenu.component.spec.ts
• Everywhere -> Remove unused injections
• scenarioHelper -> Refactor getScenarioByName array[string]
• Tests -> update skipped Tests
• settingsService -> onCameraChanged
• fix latency issue with gitignore search/blacklist

[Richargh]

• Going reactive is an interesting choice. Should work well with Typescript async/await.
• I think of settings the way CSS thinks about styles. It goes from general to specific:, global -> tags -> classes -> ids. I probably missed some CSS stuff in there. The more specific CSS style overwrites the more general style.
• What does that mean for our settings, they also go from general to specific: default -> application -> user -> file. That’s my initial ordering at least. The more specific one overwrites the more general one. This would mean file overwrites user, which does sound strange, now that I have written it. Something to ponder I guess.
• Unlike CSS our settings have things that do not make sense to specify on all levels. ** A user can have a list of “recent files” he openend in the standalone. That only makes sense to store in the user settings. A user might also prefer to view the CodeMap by default from the top. That to me are user settings. You have them in almost all programs and they are usually stored in something like user.properties.

… I would go on but I think my sentences only go longer and less coherent. I’ll sleep about it and talk some more in two weeks 😃 If you have a solution by then it’s fine by me 😄

[Richargh]

Url Parameter can probably be removed. The only useful feature is opening specific files in normal, multiple or delta mode.

I’ll check with the teams.