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

Refactor/pid registry #899

Merged
merged 1 commit into from
May 23, 2023
Merged

Refactor/pid registry #899

merged 1 commit into from
May 23, 2023

Conversation

ankur22
Copy link
Collaborator

@ankur22 ankur22 commented May 22, 2023

Description of changes

This moves the pidRegistry from the browser package into the registry package. This refactor will help isolate the details to within the registry package.

Related to: #889 (comment)

Checklist

Tasks

@ankur22 ankur22 added this to the v0.10.0 milestone May 22, 2023
@ankur22 ankur22 requested review from inancgumus and ka3de May 22, 2023 15:40
@ankur22 ankur22 self-assigned this May 22, 2023
@ankur22 ankur22 changed the base branch from main to refactor/remote-global-check May 22, 2023 15:53
Copy link
Member

@inancgumus inancgumus left a comment

Choose a reason for hiding this comment

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

LGTM, besides some naming suggestions 👍 In my opinion, it would be better to rename the browser package to module and consolidate these "registries" under a type called Registry in its own file registry.go within the module package. Reads fine: module.Registry. Since they're closely related and contain module globals, it makes sense to streamline them into one package. Is there a specific reason for keeping them separate?

// pidRegistry keeps track of the launched browser process IDs.
type pidRegistry struct {
// PidRegistry keeps track of the launched browser process IDs.
type PidRegistry struct {
Copy link
Member

Choose a reason for hiding this comment

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

Do we still need to say PidRegistry as the package name already implies that?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, I was thinking about that too. Would registry.Pid be better? I think for now it might be ok, considering we have things like context.BackgroundContext. As you've pointed out another good suggestion, we might need to refactor this again very soon, so i might leave the name as it until that next refactor 🙂


// RemoteRegistry contains the details of the remote web browsers.
// At the moment it's the WS URLs.
type RemoteRegistry struct {
Copy link
Member

Choose a reason for hiding this comment

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

The package registry implies registry. Should we still say RemoteRegistry?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Look here: #899 (comment)

"webvital_first_input_delay_good": false,
"webvital_cumulative_layout_shift": false,
"webvital_cumulative_layout_shift_good": false,
"browser_web_vital_ttfb": false,
Copy link
Member

Choose a reason for hiding this comment

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

Are these changes related to this PR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No. This branches off refactor/remote-global-check, and initially the PR was setup to merge back into main. I've changed this PR so that it now merges back into refactor/remote-global-check. This should highlight the one single commit now.

@ankur22
Copy link
Collaborator Author

ankur22 commented May 23, 2023

In my opinion, it would be better to rename the browser package to module and consolidate these "registries" under a type called Registry in its own file registry.go within the module package. Reads fine: module.Registry. Since they're closely related and contain module globals, it makes sense to streamline them into one package. Is there a specific reason for keeping them separate?

This is a good suggestion. I think we may have more "registries" that we need to create such as subprocessRegistry, connectionRegistry (or Pool), browserRegistry etc. I think they'll need to span the lifecycle of the test run 🤔 Maybe worth refactoring this again in another PR once we start working on those other registries? 🙂

@ka3de
Copy link
Collaborator

ka3de commented May 23, 2023

In my opinion, it would be better to rename the browser package to module and consolidate these "registries" under a type called Registry in its own file registry.go within the module package. Reads fine: module.Registry. Since they're closely related and contain module globals, it makes sense to streamline them into one package. Is there a specific reason for keeping them separate?

I like this idea also 👍

Base automatically changed from refactor/remote-global-check to main May 23, 2023 07:50
Now that we have a registry package, the pidRegistry can be moved out
of the browser package and into the registry package. This will help
isolate the details.
@ankur22
Copy link
Collaborator Author

ankur22 commented May 23, 2023

I'm going to merge this in and work on the refactor that Inanc suggested. It shouldn't take long 🤞

@ankur22 ankur22 merged commit ca61932 into main May 23, 2023
@ankur22 ankur22 deleted the refactor/pid-registry branch May 23, 2023 08:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants