-
Notifications
You must be signed in to change notification settings - Fork 11
Open in new tab #856
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
Open in new tab #856
Conversation
Codecov Report
@@ Coverage Diff @@
## main #856 +/- ##
=======================================
Coverage 85.36% 85.36%
=======================================
Files 799 799
Lines 16428 16434 +6
Branches 2062 2064 +2
=======================================
+ Hits 14023 14029 +6
Misses 2373 2373
Partials 32 32
Continue to review full report at Codecov.
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
projects/components/src/open-in-new-tab/open-in-new-tab.component.ts
Outdated
Show resolved
Hide resolved
const timeRange = this.getCurrentTimeRange(); | ||
const fixedTimeRange: FixedTimeRange = TimeRangeService.toFixedTimeRange(timeRange.startTime, timeRange.endTime); | ||
const newTimeRangeParam = `${TimeRangeService.TIME_RANGE_QUERY_PARAM}=${fixedTimeRange.toUrlString()}`; | ||
|
||
return this.navigationService.getAbsoluteCurrentUrl().replace(timeRangeParam, newTimeRangeParam); | ||
} | ||
|
||
public getTimeRangeParams(): Dictionary<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need the time range param to generate the new tab URL
projects/components/src/open-in-new-tab/open-in-new-tab.component.ts
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
</div> | ||
` | ||
}) | ||
export class OpenInNewTabComponent { | ||
@Input() | ||
public size?: ButtonSize = ButtonSize.Small; | ||
public paramsOrUrl?: ExternalNavigationParamsNew | string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still have the same default behavior of the current url?
@@ -80,11 +82,16 @@ export class NavigationService { | |||
|
|||
if (params.navType === NavigationParamsType.External) { | |||
// External | |||
const queryParamString = getQueryParamStringFromObject(params.queryParams ?? {}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be better to let angular do any url building for us (such as url tree). This would break if we passed it a a url that contained query params, since it wouldn't merge. Say http://website.com?param1=value
and a second param via query params { param2=value }
, we'd get http://website.com?param1=value?param2=value
instead of http://website.com?param1=value¶m2=value
.
I think you can combine router.parseUrl
, router.serializeUrl
and maybe router.createUrlTree
to get all the right behavior here.
const timeRange = this.getCurrentTimeRange(); | ||
const fixedTimeRange: FixedTimeRange = TimeRangeService.toFixedTimeRange(timeRange.startTime, timeRange.endTime); | ||
const newTimeRangeParam = `${TimeRangeService.TIME_RANGE_QUERY_PARAM}=${fixedTimeRange.toUrlString()}`; | ||
|
||
return this.navigationService.getAbsoluteCurrentUrl().replace(timeRangeParam, newTimeRangeParam); | ||
} | ||
|
||
public getTimeRangeParams(): Params { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the fuller picture is coming together here for me - I'm guessing this was left public to later use as query params in an open in new tab case that should maintain the time range, and that's also why queryParams handling was added in nav service. The problem here is we do not want callers to be concerned about this. Time range is not the only global param that needs to be preserved, and we don't want callers to even have to be aware of global params by design.
My suggestion would be to
- revert the changes here (or at least make this method private)
- update
NavigationService.buildNavigationParams
to usebuildQueryParam
for relative external urls, similar to what we do innavigateWithinApp
- remove queryParams from
ExternalNavigationParamsNew
- it's never used today and shouldn't be for this use case, so no reason to build logic for it
</div> | ||
` | ||
}) | ||
export class OpenInNewTabComponent { | ||
@Input() | ||
public size?: ButtonSize = ButtonSize.Small; | ||
public paramsOrUrl?: ExternalNavigationParamsNew | string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Because this component is named as
OpenInNewTab
, i feel it should be able to take bothInApp
andExternal
params or a url and build a localExternal
Param object. This would mean that no matter what url or params you pass, this component would always open it in a new tab. I think we can build the local param insidengOnchanges
with reasonable defaults for missing properties. - Could we please rename
ExternalNavigationParamsNew
toExternalNavigationParams
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thoughts? cc @aaron-steinfeld
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the rename - how did that even get in?!
Also, yes - I think ideally the open in new tab component should be able to support and convert inApp params to external ones, but I personally don't feel it needs to hold up this PR, since we can add it later with fully backwards compatible support as it's a union type already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed it when i was migrating to the new interface. But you approved the PR, so....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure we can make #1 change separately
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm other than those two leftovers
@@ -73,6 +73,22 @@ export class NavigationService { | |||
return this.currentParamMap.getAll(parameterName); | |||
} | |||
|
|||
public constructExternalUrl(urlString: string): string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks! looks good - with these changes, do we still need the changes in time range service or the new url util?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nope, I already reverted those changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right, the TR ones are gone - one of the url utils looks like it's still there being unused though
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
import { HttpParams } from '@angular/common/http'; | ||
import { Params } from '@angular/router'; | ||
|
||
export const getQueryParamStringFromObject = (params: Params): string => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed or should we use the below function directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay I will remove this function as it is not being used anywhere, but It is better to have a separate function like this, firstly consumers didn't have to write a new instance of HttpParams
every time, and secondly if later we want to standardize queryParams
key-value pair we need to change this function only.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alok-traceable
Description
Testing
Checklist: