Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce ViewRouter Component #337

Merged
merged 31 commits into from
Feb 4, 2025
Merged

Conversation

taldekar
Copy link
Contributor

@taldekar taldekar commented Jan 28, 2025

Issue #335

Description of changes:
Introduced a ViewRouter component to determine which view to display based on an order of resolution logic.

Open Questions:

  • Checks to determine browser compatibility and UI asset availability needs to be implemented, but which components should be responsible for this requires some more thought.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@taldekar taldekar requested a review from shruti0085 January 28, 2025 19:42
@taldekar taldekar changed the base branch from main to nickdb/lspErrorHandling January 29, 2025 14:19
@taldekar taldekar requested a review from breedloj January 29, 2025 15:04
* Add functionality for hot subscribers that track latest event

* Add test to ensure event stream isolation

* Fix missing subscription disposal in test

* Use autoConnect to implicitly manage stream connection
@ParameterizedTest
@MethodSource("provideStateSource")
void testActiveViewResolutionBasedOnPluginState(final LspState lspState, final AuthState authState,
final ViewId activeViewId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this be renamed to "expectedActiveViewId"?
Is there a way to do an assertion on what is expected and what is the actual active view ?

Copy link
Contributor Author

@taldekar taldekar Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update the name. Changing this to an assertion is possible using ArgumentCaptors like so. Should I transition to this approach. I've verified that verify calls on the mock fail if the ViewIds are not what is expected. The ViewRouter doesn't really expose any methods to retrieve the activeView, so assertions are a bit difficult.

RxJavaPlugins.setComputationSchedulerHandler(scheduler -> Schedulers.trampoline());

publishSubject = PublishSubject.create();
authStateObservable = publishSubject.ofType(AuthState.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do any of the observables need disposal?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe so, but I'll verify this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Observables do not need to be disposed. But on a related note I did add functionality to track any subscriptions in the event broker and added a method that can be used to dispose off them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be a example of a use case where we would want to dispose off a subscription?
By disposing observable I was talking about the situation when we want to stop listening for a certain event. By disposing off a subscription I am unclear what exactly that does?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disposing off the subscription basically cancels it. So we stop listening to events. Observables are the stream of data, and those don't need to be disposed. For the ViewContainer component, before the check to see if the parent composite is disposed, if we didn't dispose the listener then it would try to call update child view when the parent composite was disposed and error out. Cases like these it would make sense to dispose of the listener.

@taldekar taldekar requested a review from shruti0085 January 31, 2025 00:14
RxJavaPlugins.setComputationSchedulerHandler(scheduler -> Schedulers.trampoline());

publishSubject = PublishSubject.create();
authStateObservable = publishSubject.ofType(AuthState.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be a example of a use case where we would want to dispose off a subscription?
By disposing observable I was talking about the situation when we want to stop listening for a certain event. By disposing off a subscription I am unclear what exactly that does?

@taldekar taldekar changed the base branch from nickdb/lspErrorHandling to feature/viewRefactor January 31, 2025 21:21
@taldekar taldekar merged commit f975e6f into feature/viewRefactor Feb 4, 2025
@taldekar taldekar deleted the taldekar/ViewRouter branch February 4, 2025 21:27
taldekar added a commit that referenced this pull request Feb 25, 2025
* improved handling of lsp failure state

* add static mock to lsp connection test case

* Integrate Event Broker in LspStatusManager

* Add ViewRouter POC

* Fix code formatting bug

* Add method to retrieve observables

* Add listeners for combined state streams and view update request

* Add listeners for combined state streams and view update request

* Add listeners for combined state streams and view update request

* Add functionality for hot event streams that track latest event (#340)

* Add functionality for hot subscribers that track latest event

* Add test to ensure event stream isolation

* Fix missing subscription disposal in test

* Use autoConnect to implicitly manage stream connection

* Remove active view update request listener

* Add ViewRouter tests

* Remove public constructor

* Remove public constructor and unused event in tests

* Add comments

* Add documentation for EventBroker

* Remove ViewRouter initialization

* Remove LspInitializingView from ID enum

* Add documentation for ViewRouter

* Refactor and enhance EventBroker tests

* Refactor ViewRouter tests for clarity

* Remove PluginState class into separate file

* Add documentation to subscription management logic

* Add support for notifying  multiple late-subscribers over time of latest state (#342)

* Remove CODE_REFERENCE_VIEW

* Rename newActiveViewId to newActiveView

* Rename ViewId class to AmazonQViewType

* Revert "Integrate Event Broker in LspStatusManager"

This reverts commit 374e549.

* Revert "improved handling of lsp failure state"

This reverts commit 13c55ac.

* Refactor EventBroker and enhance tests (#343)

---------

Co-authored-by: Nicolas Borges <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants