Since we started working on the extension, time passed, scoped changed and also we know better how VSC-related stuff works. There are at least few places which I know could be improved (from technical perspective) and I'll gather those here so we can improve the extension iteratively based on that.
Validation
Validation is now triggered from multiple places (from validate command, from workspace related even listeners, from initalization procedure). Also some of those places require to be aware and pass application/extension related states (like modified file contents). This makes it quite complex, requires some extra knowledge from not-validation-related code parts and results in tight-coupling.
It should be reworked so that:
validation should have single entry point (see below section on events)
validation should be abortable (so if new validation request is there, abort previous one because it doesn't make sense to continue)
validation should be responsible for reading all files data and contents (using fs + active documents VSC API for modified files)
More event driven
Here again, there is an issue with tight coupling in some places. Moving to event-based architecture would help untangle the code and keep it more modular.
Good example could be validation. As mentioned before, it is now triggered from multiple places by simply calling validation method or validate command. Utilizing events each module /class would fire an event on specific actions like:
login
logout
file changed
configuration changed
policy updated
etc.
And then validator would listen to such events and decide if validation should be run.
More stateful
At the current state there is simple global state held by extension but it's used for top-level data/object only. In other places the state is calculated every time is needed - for example getting workspace config for validation would every time check for existence of config file and what type of config it is. It doesn't seem necessary and could be stored for the entire runtime (ofc, assuming it will correctly react to external config changes).
Tests
There are some E2E test, mostly added at the beginning of the project (CC still around 75%), but I feel like they may need revisiting and adding better coverage for some functionality which is not tested there.
Code structure
Now, most of the code is located in utils folder. It will be better to separate it somehow by purpose or responsibilities to make working with the code easier.
I started doing that in #87, by creating ./core/code-actions/ directory for code actions related files.
Since we started working on the extension, time passed, scoped changed and also we know better how VSC-related stuff works. There are at least few places which I know could be improved (from technical perspective) and I'll gather those here so we can improve the extension iteratively based on that.
Validation
Validation is now triggered from multiple places (from
validatecommand, from workspace related even listeners, from initalization procedure). Also some of those places require to be aware and pass application/extension related states (like modified file contents). This makes it quite complex, requires some extra knowledge from not-validation-related code parts and results in tight-coupling.It should be reworked so that:
More event driven
Here again, there is an issue with tight coupling in some places. Moving to event-based architecture would help untangle the code and keep it more modular.
Good example could be validation. As mentioned before, it is now triggered from multiple places by simply calling validation method or
validatecommand. Utilizing events each module /class would fire an event on specific actions like:And then validator would listen to such events and decide if validation should be run.
More stateful
At the current state there is simple global state held by extension but it's used for top-level data/object only. In other places the state is calculated every time is needed - for example getting workspace config for validation would every time check for existence of config file and what type of config it is. It doesn't seem necessary and could be stored for the entire runtime (ofc, assuming it will correctly react to external config changes).
Tests
There are some E2E test, mostly added at the beginning of the project (CC still around 75%), but I feel like they may need revisiting and adding better coverage for some functionality which is not tested there.
Code structure
Now, most of the code is located in
utilsfolder. It will be better to separate it somehow by purpose or responsibilities to make working with the code easier.I started doing that in #87, by creating
./core/code-actions/directory for code actions related files.