-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
[Search v1] Implement policy filter #41769
[Search v1] Implement policy filter #41769
Conversation
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.
Left some small comments, the navigation logic is getting pretty complex and hacky IMO :/ but I don't have enough knowledge (yet) to help simplify it.
src/libs/SearchUtils.ts
Outdated
function getQueryHash(query: string): number { | ||
return UserUtils.hashText(query, 2 ** 32); | ||
function getQueryHash(query: string, policyID?: string): number { | ||
const textToHash = policyID ? `${query}_${policyID}` : query; |
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.
you can write this as:
const textToHash = [query, policyID].filter(Boolean).join('_')
;
no conditional logic + whenever we add 3rd or 4th parameter (I believe we will add more params like page or sortBy, right?) it will be easy to expand to more phrases.
@@ -93,8 +102,10 @@ export default function switchPolicyID(navigation: NavigationContainerRef<RootSt | |||
return; | |||
} | |||
|
|||
const shouldPushCentralPane = !getIsNarrowLayout() || shouldOpenSearchPage; |
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 find it hard to understand what does "push" mean in this context. If you think this is obvious to people working with navigation then feel free to leave as is.
If not then perhaps some other name or a comment?
src/libs/actions/Search.ts
Outdated
const hash = SearchUtils.getQueryHash(query); | ||
API.read(READ_COMMANDS.SEARCH, {query, hash}); | ||
function search(query: string, policyID?: string) { | ||
const hash = SearchUtils.getQueryHash(query, policyID); |
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 suggest we only compute hash
in the search component and pass it here along with the other arguments.
Feels unnecessary to count hash twice, and it will make this function super simple.
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, we have agreed on some naming and comment changes but approving this
@ahmedGaber93 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
// Case when the user is on the AllSettingsScreen and selects the specific workspace. The user is redirected then to the specific workspace settings. | ||
if (screen === SCREENS.ALL_SETTINGS && policyID) { | ||
screen = SCREENS.WORKSPACE.INITIAL; | ||
} | ||
|
||
// Alternative case when the user is on the specific workspace settings screen and selects "All" workspace. | ||
else if (!policyID && screen === SCREENS.WORKSPACE.INITIAL) { | ||
screen = SCREENS.ALL_SETTINGS; |
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.
Why did we remove this?
|
||
// Currently, the search page displayed in the bottom tab has the same URL as the page in the central pane, so we need to redirect to the correct search route. | ||
// Here's the configuration: src/libs/Navigation/AppNavigator/createCustomStackNavigator/index.tsx | ||
const isOpeningSearchFromBottomTab = newPath.startsWith(CONST.SEARCH_BOTTOM_TAB_URL); |
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.
Can we use the screen name instead of creating a new const for it?
if (!getIsNarrowLayout()) { | ||
// Case when the user selects "All" workspace from the specific workspace settings | ||
if (checkIfActionPayloadNameIsEqual(actionForBottomTabNavigator, SCREENS.ALL_SETTINGS) && !policyID) { | ||
root.dispatch({ | ||
type: CONST.NAVIGATION.ACTION_TYPE.PUSH, | ||
payload: { | ||
name: NAVIGATORS.CENTRAL_PANE_NAVIGATOR, | ||
params: { | ||
screen: SCREENS.SETTINGS.WORKSPACES, | ||
params: undefined, | ||
}, | ||
}, | ||
}); | ||
} else { | ||
const topmostCentralPaneRoute = getTopmostCentralPaneRoute(rootState); | ||
const screen = topmostCentralPaneRoute?.name; | ||
const params: CentralPaneRouteParams = {...topmostCentralPaneRoute?.params}; | ||
const isWorkspaceScreen = screen && Object.values(SCREENS.WORKSPACE).includes(screen as ValueOf<typeof SCREENS.WORKSPACE>); | ||
|
||
// Only workspace settings screens have to store the policyID in the params. | ||
// In other case, the policyID is read from the BottomTab params. | ||
if (!isWorkspaceScreen) { | ||
delete params.policyID; | ||
} else { | ||
params.policyID = policyID; | ||
} | ||
|
||
// If the user is on the home page and changes the current workspace, then should be displayed a report from the selected workspace. | ||
// To achieve that, it's necessary to navigate without the reportID param. | ||
if (checkIfActionPayloadNameIsEqual(actionForBottomTabNavigator, SCREENS.HOME)) { | ||
delete params.reportID; | ||
} | ||
|
||
root.dispatch({ | ||
type: CONST.NAVIGATION.ACTION_TYPE.PUSH, | ||
payload: { | ||
name: NAVIGATORS.CENTRAL_PANE_NAVIGATOR, | ||
params: { | ||
screen, | ||
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.
I'm not sure that I understand this diff. Would you mind explaining why we can replace this code?
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.
This code is related to the pages that have been already refactored. Previously Workspace Switcher was available on Account Settings and Workspace Initial Page pages, we don't need this anymore since these pages don't display WS :)
src/libs/API/parameters/Search.ts
Outdated
@@ -1,5 +1,6 @@ | |||
type SearchParams = { | |||
query: string; | |||
policyID?: 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.
We're actually using policyIDs
, string containing a comma separated list of policyIDs since in the future users will be able to search for results with search syntax instead of just using the workspace switcher, e.g. type:transaction to:<policy>
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 have a question regarding this change. In the design doc we have an url for this page in the format: route: search/:query/:sortBy/:order/:policyID, example: search/all/date/asc/1
and I'm wondering whether storing these filters in route params would be more readable for users: search/all?sortBy=date&order=asc&policyIDs=1
. It's also easier to implement optional params in this format. In the situation when we don't have any filters and we select a policy, we have to add also other params to the url which are before the policyID
. WDYT?
cc: @adamgrzybowski @Kicu
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.
Yea, I think that makes sense. Would we want to implement those changes in this PR or in a follow up?
Bug: switch workspace call search API 3 times. issue1.mp4 |
Ah yea, I noticed that too but forgot to post about it. The first call seems to have no policyIDs param, while the next ones do. We should fix that. |
I am not sure if this bug or not implemented yet. 20240509233624846.mp4 |
Work fine in web, but not work in iOS native. 20240510002633146.mp4 |
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.
Looking good. We still need to address the multiple API calls and the deeplink issue
Reviewer Checklist
Screenshots/VideosAndroid: Nativea.mp4Android: mWeb Chromeaw.mp4iOS: Nativei.mp4iOS: mWeb Safariiw.mp4MacOS: Chrome / Safariw.mp4MacOS: Desktopd.mp4 |
Looks good to me, but we still need to fix this #41769 (review) and clean this #41769 (comment) |
@WojtekBoman I'm gonna go ahead and merge this one since it'll reduce conflicts in the next PRs, but can you please work on this follow up? #42177 |
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by https://github.com/luacmartins in version: 1.4.74-0 🚀
|
🚀 Deployed to production by https://github.com/chiragsalian in version: 1.4.74-6 🚀
|
Details
This PR adds switching between workspaces on the SearchPage.
Fixed Issues
$ #41618
PROPOSAL:
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
Screen.Recording.2024-05-08.at.15.50.45.mov
iOS: Native
Screen.Recording.2024-05-08.at.15.13.09.mov
iOS: mWeb Safari
Screen.Recording.2024-05-08.at.15.14.39.mov
MacOS: Chrome / Safari
Screen.Recording.2024-05-08.at.15.29.54.mov
MacOS: Desktop
Screen.Recording.2024-05-08.at.15.28.51.mov