Several smaller inconsistencies in app behavior (confirmed by testing manually and programmatically) indicate a fundamental error in the approach used in the current iteration of the ConfigFile TreeView. Currently, the intended dependence of the ConfigFile view on the currently selected rulebook is hard-coded. Continuing in this manner would require unnecessarily hard-coding the expected cascading behaviors on edit, on delete, etc.
Alternatives
The VS Code API provides several mechanisms that can automate this kind of interactive and dependent functionality.
Subscriptions [EventEmitter and Event Pattern]
The EventEmitter class can be used to create events in your extension that other parts of your extension can subscribe to.
For instance, you could emit events whenever the state of the Rulebook view changes (like after an update). The ConfigFile view can then listen for these events and refresh its data accordingly, ensuring it's always in sync with the Rulebook's state.
FileSystemWatcher
If changes in the Rulebook are reflected in local configuration files, FileSystemWatcher can be used to monitor these files for changes. When a change is detected, it can trigger a refresh in the ConfigFile view.
This approach is particularly effective if there's a delay between when changes are made and when they're written to disk, as it doesn't rely on actively tracking the state within your extension.
Extension Context
The Context (often provided in setup functions like activate) is a key-value store that's persisted across the active session of your extension.
You can use this to store the state of your Rulebook view, and then your ConfigFile view can monitor this state and refresh when necessary. This requires a good key-management strategy but can be a simple way to share a "source of truth" within your extension.
Extension GlobalState / WorkspaceState
Similar to Context, these are key-value stores that persist across sessions (GlobalState) or within a specific workspace (WorkspaceState). They can be used to store states, and views can monitor and react to changes in these states.
Tasks
[x] Briefly explore each of the above options to determine which would be the best fit. First impressions:
Subscription model would most smoothly utilize existing features in the TreeViews.
FileSystemWatcher would be more robust and isolate this functionality, but may be more than necessary for the MVP.
Context would work, but would require careful manual management of the state (not ideal).
GlobalState is unnecessary, except maybe for use in testing (likely also unnecessary if the state is well-managed otherwise).
[x] Thoroughly document the details of state management.
[x] Write RulebookView tests focused on state management.
[x] correct refreshes itself after add, edit filename, delete
[x] correctly refreshes ConfigFileView after editing Rulebook contents
State Management for a Smooth User Experience
Problem
Several smaller inconsistencies in app behavior (confirmed by testing manually and programmatically) indicate a fundamental error in the approach used in the current iteration of the ConfigFile TreeView. Currently, the intended dependence of the ConfigFile view on the currently selected rulebook is hard-coded. Continuing in this manner would require unnecessarily hard-coding the expected cascading behaviors on edit, on delete, etc.
Alternatives
The VS Code API provides several mechanisms that can automate this kind of interactive and dependent functionality.
Subscriptions [EventEmitter and Event Pattern]
The EventEmitter class can be used to create events in your extension that other parts of your extension can subscribe to. For instance, you could emit events whenever the state of the Rulebook view changes (like after an update). The ConfigFile view can then listen for these events and refresh its data accordingly, ensuring it's always in sync with the Rulebook's state.
FileSystemWatcher
If changes in the Rulebook are reflected in local configuration files, FileSystemWatcher can be used to monitor these files for changes. When a change is detected, it can trigger a refresh in the ConfigFile view. This approach is particularly effective if there's a delay between when changes are made and when they're written to disk, as it doesn't rely on actively tracking the state within your extension.
Extension Context
The Context (often provided in setup functions like activate) is a key-value store that's persisted across the active session of your extension. You can use this to store the state of your Rulebook view, and then your ConfigFile view can monitor this state and refresh when necessary. This requires a good key-management strategy but can be a simple way to share a "source of truth" within your extension.
Extension GlobalState / WorkspaceState
Similar to Context, these are key-value stores that persist across sessions (GlobalState) or within a specific workspace (WorkspaceState). They can be used to store states, and views can monitor and react to changes in these states.
Tasks