[Due for payment 2025-05-20] [$250] Add search/filter text input to lists with items above 15

[dubielzyk-expensify]

Problem

When lists like categories, tags, members, etc. get too long it can be hard to find what you need. Users will have to scroll for ages and this is unproductive and frustrating. Some companies can have 100+ tags, members, or categories where this problem is even worse.

Solution

Let's add a search input that filters the results for lists above 15 items. This search input should filter the list below in a keyword filtering way. E.g. Searching for car should reveal cards and trains and cars given the string can be found both places.

For lists below 15 items, the search field should not appear:

Less than 15 items	More than 15 items

When the input field is filled it should have a clear button to clear the input field as well:

No value	Search field entered

When there are no results matching, we should show a simple text message:

These changes should immediately impact these pages:

• Categories
• Tags
• Report fields
• Members

but also every other part of the app that has a list with a search bar. If the list there is less than 15, then it shouldn't show.

Full mocks

Categories

Members

Tags

Report Fields

cc @Expensify/design @davidcardoza @JmillsExpensify @trjExpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021909806305274031266
• Upwork Job ID: 1909806305274031266
• Last Price Increase: 2025-04-09
• Automatic offers:
• daledah | Contributor | 106968267

Issue Owner

Current Issue Owner: @daledah

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021909806305274031266

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[abzokhattab]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Add search/filter text input to lists with items above 15

What is the root cause of that problem?

The UI lacks a built-in search/filter mechanism, displaying the entire list regardless of its length. This forces users to manually scroll through long lists when they could quickly narrow down their options.

What changes do you think we should make in order to solve the problem?

1. Add a search value state:

   This state will store the user’s search input. We now use a debounced state so that filtering isn’t triggered on every keystroke.

  const [searchValue, debouncedSearchValue, setSearchValue] = useDebouncedState('');

2. Determine if the search field should be rendered:

Only display the search box if the list exceeds 15 items.

const shouldShowSearch = categoryList.length > 15;

3. Filter the list of items:

const filteredCategoryList = useMemo(() => {
    if (!debouncedSearchValue.trim()) {
        return categoryList;
    }
    const lowerQuery = debouncedSearchValue.trim().toLowerCase();
    return categoryList.filter((cat) =>
        cat?.text?.toLowerCase().includes(lowerQuery)
    );
}, [debouncedSearchValue, categoryList]);

4. Render the search field conditionally:

Integrate the search input within the UI. On mobile it will take full width; on non-mobile screens it will be centered at half width.

{shouldShowSearch && (
    <View style={[styles.ph5, styles.pb3, !isSmallScreenWidth && styles.mw50]}>
        <TextInput
            style={[styles.textInput]}
            placeholder={translate('common.search')}
            value={searchValue}
            icon={Expensicons.MagnifyingGlass}
            onChangeText={setSearchValue}
        />
    </View>
)}

5. Replace the usage of categoryList with filteredCategoryList:
   Use the filtered list in any component or occurrence in the file that was previously using the full categoryList.

6. These snippets can be duplicated in the pages for Tags , Report fields , and Members as well, ensuring consistent behavior across all long lists.

7. to display an empty state we should use the EmptyStateComponent to display an empty state text in case the user entered a search text and there are no results

Result:

Screen.Recording.2025-04-09.at.05.44.42.mov

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Solution 2:
Instead of adding an external search input, we can leverage the built-in TextInput from BaseSelectionList (used inside SelectionListWithModal). By passing search-related props into SelectionListWithModal, the component will automatically render its own text input for filtering. To improve flexibility, we propose adding new props to the base component:

• textInputIcon: To allow passing an icon.

• textInputContainerStyle : To enable custom container styles (e.g., making the width half on non-mobile screens).

In the Categories page, modify the call to SelectionListWithModal as follows:

<SelectionListWithModal
    // ... existing props
    // Pass search text and handler so the built-in TextInput is rendered
    textInputLabel="Search Categories"
    textInputPlaceholder={translate('common.search')}
    textInputValue={searchValue}
    onChangeText={setSearchValue}
    shouldShowTextInput={shouldShowSearch}

    // New props for additional customization:
    textInputIcon={Expensicons.Search} // Icon to display in the search input
    textInputContainerStyle={isSmallScreenWidth ? {width: '100%'} : {alignSelf: 'center', width: '50%'}}

    // Provide filtered data for the list:
    sections={[{data: filteredCategoryList, isDisabled: false}]}
    
    // ... any additional props
/>

This approach leverages the built-in TextInput, reducing redundancy and ensuring a consistent user experience.

Third Solution

Instead of handling search/filtering logic in each page, we can centralize it within the BaseSelectionList component. By adding a new prop (e.g., enableSearchFiltering), the component will internally:

• Maintain its own search state.
• Render a built-in TextInput for filtering when enabled.
• Apply filtering on the items before rendering.

This way, all lists (Categories, Tags, Report fields, Members) automatically gain search functionality without duplicating code, while still preserving backward compatibility.

Example Implementation Inside BaseSelectionList:

    const [searchValue, setSearchValue] = useState('');

    const filteredItems = useMemo(() => {
        if (!enableSearchFiltering || !searchValue.trim()) {
            return items;
        }
        const lowerQuery = searchValue.trim().toLowerCase();
        return items.filter(item => item.text.toLowerCase().includes(lowerQuery));
    }, [searchValue, items, enableSearchFiltering]);

.... 
            {enableSearchFiltering && (
                <TextInput
                    placeholder="Search..."
                    value={searchValue}
                    onChangeText={setSearchValue}
                />
            )}
            />
    );
}

other adjustments are needed inside the base list but this is the general idea.

[daledah]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-10 17:31:29 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Add search/filter text input to lists with items above 15

What is the root cause of that problem?

Improved

What changes do you think we should make in order to solve the problem?

I will do it for category and other pages will do the same

1. Create a new state searchQuery and inputValue

2. Create a search text input with the SearchIcon in the right with clear button as mock in this comment

    const getSearchBar = () => {
        return (
            <View style={[{width: '300px', marginLeft: '20px'}]}>
                <TextInput 
                    accessibilityLabel="Find category"
                    placeholder='Find category'
                    onChangeText={setInputValue}
                    value={inputValue}
                    icon={Expensicons.MagnifyingGlass}
                    onSubmitEditing={() => setSearchQuery(inputValue)}
                    shouldShowClearButton
                />
            </View>
        );
    };

3. Add the search text input below the header text

        {shouldUseNarrowLayout && <View style={[styles.pl5, styles.pr5]}>{getHeaderButtons()}</View>}
        {categoryList.length > 15 && getSearchBar()}

4. Update the condition when we build the category list and use this in here

        const filteredCategoryList = useMemo(() => {
        if (!searchQuery.trim()) {
            return categoryList;
        }
        const lowerQuery = searchQuery.trim().toLowerCase();
        return categoryList.filter(cat =>
            cat.text?.toLowerCase().includes(lowerQuery)
        );
    }, [searchQuery, categoryList]);

App/src/pages/workspace/categories/WorkspaceCategoriesPage.tsx

Line 468 in c7f9d53

sections={[{data: categoryList, isDisabled: false}]}

5. Add condition filteredCategoryList.length === 0 here to show the text

        {
            filteredCategoryList.length === 0 && (
                <View style={[styles.ph5, styles.pb5, styles.pt3]}>
                    <Text style={[styles.textNormal, styles.colorMuted]}>No results found matching "{searchQuery}"</Text>
                </View>
            )
        }

Note: If we want to display the results without submitting, we can remove the inputValue state and use searchQuery directly by using useDebouncedState. And If we want to submit search input, we can implement onPressIcon to TextInput and submit when the user press on the icon.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

Screen.Recording.2025-04-14.at.17.13.44.mov

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[binaya-adhikaree]

we can solve this problem in react by using hooks like useState
const [searchValue, setSearchValue] = useState('');

and if you want to show input field only when length is above 15 then for that you need to do

const itemLength= item.length > 15;

3.You can now filter that
{itemLength && const filteredCategoryList = useMemo(() => {
if (!searchValue.trim()) {
return unfilteredCategoryList;
}
const lowerQuery = searchValue.trim().toLowerCase();
return unfilteredCategoryList.filter(cat =>
cat.text.toLowerCase().includes(lowerQuery)
);
}, [searchValue, unfilteredCategoryList]);}

after writing the function you can apply it in input field

<input
type="text"
placeholder="Search categories..."
value={searchValue}
onChange={(e) => setSearchValue(e.target.value)}

  />

Email : adhikaribijaya2035@gmail.com
upwork profile link : https://www.upwork.com/freelancers/~0133be706cf1b6d147

[melvin-bot]

📣 @binaya-adhikaree! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[abzokhattab]

Updated Proposal

• POC added
• Added an alternative proposal.
• Replaced useState with useDebouncedState in the searchValue state
• Added a third proposal

[shawnborton]

Looks good @dubielzyk-expensify! Let's also add a screenshot for when you search something in the input and we can't return any results in the table. This is what we show when the search router can't find anything:

We could reuse that style or even do something much more simple like a report empty state where we have no skeletons in the BG.