[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 : [email protected]
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.

[MustafaMulla29]

Proposal

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

Users face difficulty navigating long lists (e.g., categories, tags, members) as they lack a search input to filter items. Scrolling through large lists is inefficient and frustrating.

What is the root cause of that problem?

The SelectionList component does not include a search input to dynamically filter list items. This forces users to manually scroll through all items, which becomes impractical for large lists.

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

We should enhance the SelectionList component to include an optional search input field that filters the displayed list items. The search input should only appear when the list exceeds 15 items.

Key Changes:
Add Search Input to SelectionList

Introduce textInputValue, textInputLabel, textInputHint, and onChangeText props.
Conditionally render the search input above the list.
Update Parent Components:

Update components like CategoryPicker to pass search-related props to SelectionList

SelectionList Component:

return (
    <>
        {props.textInputValue !== undefined && (
            <TextInput
                value={props.textInputValue}
                onChangeText={props.onChangeText}
                label={props.textInputLabel}
                placeholder={props.textInputHint}
                clearButtonMode="while-editing"
            />
        )}
        <BaseSelectionList {...props} ref={ref} onScroll={onScroll ?? defaultOnScroll} />
    </>
);

CategoryPicker Component:

const filteredSections = useMemo(() => {
        if (!searchValue) {
            return sections;
        }
        return sections.map((section) => ({
            ...section,
            data: section.data.filter((item) => item.name.toLowerCase().includes(searchValue.toLowerCase())),
        }));
    }, [searchValue, sections]);

const shouldShowSearchInput = sections.reduce((count, section) => count + section.data.length, 0) > 15;

    return (
        <SelectionList
            sections={filteredSections}
            headerMessage={headerMessage}
            textInputValue={shouldShowSearchInput ? searchValue : undefined}
            textInputLabel={shouldShowSearchInput ? translate('common.search') : undefined}
            textInputHint={shouldShowSearchInput ? translate('common.typeToSearch') : undefined}
            onChangeText={setSearchValue}
            onSelectRow={onSubmit}
            ListItem={RadioListItem}
            isRowMultilineSupported
        />
    );

Do the same for other components as CategoryPicker

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

1. Search Input Visibility:
   Verify the search input appears only when the list contains more than 15 items.
   Ensure it is hidden for lists with 15 or fewer items.
2. Filtering Behavior:
   Test that entering a search term filters the list correctly (case-insensitive).
   Verify clearing the search input restores the full list.
3. Edge Cases:
   Test with empty lists and lists containing special characters or mixed-case strings.
4. Offline Mode:
   Ensure the search input displays an appropriate hint when offline (e.g., "Results are limited").

[melvin-bot]

📣 @MustafaMulla29! 📣
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>

[shawnborton]

Also to note, if we update the logic for when we should show a search input (if greater than 15 items), we should update that everywhere right? As in, for other places where you have a search input above a list (starting a chat, sending an expense, etc).

[MustafaMulla29]

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/~01e563610c8ef28901

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[ishakakkad]

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?

Improvement.

UI does not have filter functionality, so when item list are big user has to scroll to find the item.

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

As this functionality needs to be used in multiple places, it is ideal to create reusable logic. There are couple of solution. Any of the following solution can be applied to all the required places.

Solution 1:

• Step1: Create custom hook

// hooks/useSearchFilter.js
import { useState, useMemo } from 'react';

// TODO this logic likely to work but still needs to test will edge cases and adjust the logic during development if needed
const useSearchFilter = (items, threshold = 15) => {
 // TODO: Alternatively we can use `useDebouncedState` if we want, but as we are not sending query to DB it is better not to use debounce to get instant user experice. 

  const [query, setQuery] = useState('');  

  const shouldShowSearch = items.length > threshold;

  const filteredItems = useMemo(() => {
    if (!query) return items;
    return items.filter(item =>
      item.toLowerCase().includes(query.toLowerCase())
    );
  }, [query, items]);

  return { query, setQuery, filteredItems, shouldShowSearch };
};

export default useSearchFilter;

Step 2:

const { query, setQuery, filteredItems, shouldShowSearch } = useSearchFilter(categoryList);

return (
  <div>
    {shouldShowSearch && (
       // TODO style can be adjust at the time of development as per requirements.
       <View style={[styles.ph5, styles.pb3, !isSmallScreenWidth && styles.mw50]}>
          <TextInput
              style={[styles.textInput]}
              placeholder={translate('common.search')}
              value={query}
              icon={Expensicons.MagnifyingGlass}
              onChange={(e) => setQuery(e.target.value)}
          />
      </View>
    )}

    {filteredItems.length === 0 ? (
      <p>No results found.</p> // TODO: this should be replaced with proper empty state.
    ) : (
      // TODO logic to render display items goes here and we use `filteredItems` instead of categoryList
    )}
  </div>
);

OR

Solution 2:

• Step 1: Create same hook mention in Solution 1:
• Step 2: Leverage SelectionListWithModal to show the input and it required following change here

<SelectionListWithModal
      canSelectMultiple={canSelectMultiple}
      turnOnSelectionModeOnLongPress={isSmallScreenWidth}
      onTurnOnSelectionMode={(item) => item && toggleCategory(item)}
      sections={[{data: categoryList, isDisabled: false}]}
      onCheckboxPress={toggleCategory}
      onSelectRow={navigateToCategorySettings}
      shouldPreventDefaultFocusOnSelectRow={!canUseTouchScreen()}
      onSelectAll={toggleAllCategories}
      ListItem={TableListItem}
      onDismissError={dismissError}
      customListHeader={getCustomListHeader()}
      listHeaderWrapperStyle={[styles.ph9, styles.pv3, styles.pb5]}
      listHeaderContent={shouldUseNarrowLayout ? getHeaderText() : null}
      showScrollIndicator={false}
      textInputValue='car'
      textInputLabel={translate('common.search')}
      textInputValue={searchValue}
      textInputLabel={shouldShowTextInput ? translate('common.search') : undefined}

      // Also required new props to adjust the style and show icon
      icon={Expensicons.MagnifyingGlass}
      textStyles={} // TODO identify styles during development to match with current design

  />

OR

Solution 3: We can create HOC, to use this we need do refactor and move list logic into separate component and use HOC on that component. So this may be more work, so I consider this as a last option.

// withSearchableList.js
// imports .....

const withSearchableList = (Component, threshold = 15, emptyText = 'No results found.') => (props) => {
  // TODO search related logic can be move to custom hook(`useSearchFilter`) as I defined in  **Solution 1**. And we can use that custom hook here.

 // TODO: Alternatively we can use `useDebouncedState`  if we want, but as we are not sending query to DB it is better not to use debounce to get instant user experice. 
  const [query, setQuery] = useState('');
  const { items } = props;

  const filteredItems = query
    ? items.filter(item => item.toLowerCase().includes(query.toLowerCase()))
    : items;

  return (
    <div>
      {items.length > threshold && (
         // TODO style can be adjust at the time of development as per requirements.
        <View style={[styles.ph5, styles.pb3, !isSmallScreenWidth && styles.mw50]}>
          <TextInput
              style={[styles.textInput]}
              placeholder={translate('common.search')}
              value={query}
              icon={Expensicons.MagnifyingGlass}
              onChange={(e) => setQuery(e.target.value)}
          />
      </View>
      )}

      {filteredItems.length === 0 ? (
        <p>{emptyText}</p> // TODO: this should be replaced with proper empty state.
      ) : (
        <Component {...props} items={filteredItems} />
      )}
    </div>
  );
};

export default withSearchableList;

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

We can write test cases for useSearchFilter to check if it returns correct data or not.

What alternative solutions did you explore? (Optional)

[dubielzyk-expensify]

Also to note, if we update the logic for when we should show a search input (if greater than 15 items), we should update that everywhere right? As in, for other places where you have a search input above a list (starting a chat, sending an expense, etc).

I'll add that to the OG post

[dubielzyk-expensify]

How about this for empty state, @Expensify/design ?

I could see us doing a simpler one, but we already use this heaps of places so feels right to reuse like Shawn suggested.

[shawnborton]

The only pushback I might have here is that as you start typing, fewer and fewer rows will appear until suddenly you type something with no matches at all to trigger the empty state. So part of me thinks that a very simple empty state with no rows might feel like a less jarring transition? This way you see less and less rows appear until suddenly there are no rows, and just a simple empty state. Thoughts on that?

[dannymcclain]

The only pushback I might have here is that as you start typing, fewer and fewer rows will appear until suddenly you type something with no matches at all to trigger the empty state. So part of me thinks that a very simple empty state with no rows might feel like a less jarring transition? This way you see less and less rows appear until suddenly there are no rows, and just a simple empty state. Thoughts on that?

Yeah I agree with this. I think we can go way more minimal with the empty state when filtering rows. IMO it feels different than triggering a search that returns no results.

[daledah]

@thesahindia update proposal to handle case we don't have search data like mock here. I have a test branch here to easier to test

[dubielzyk-expensify]

The only pushback I might have here is that as you start typing, fewer and fewer rows will appear until suddenly you type something with no matches at all to trigger the empty state. So part of me thinks that a very simple empty state with no rows might feel like a less jarring transition? This way you see less and less rows appear until suddenly there are no rows, and just a simple empty state. Thoughts on that?

Down for that. Though you wanted to reuse the style from the comment above.

How about this:

Or if we wanna keep the header then maybe this:

There's a few more explorations in Figma.

[shawnborton]

Lovely, I quite like the simplicity of your first mock and I think that's fairly consistent with using something like the member list from start a chat when you type something that has no matches.

[dannymcclain]

I also really like the the first mock. I think in a situation like this, this is all we need.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.1.44-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix: add search bar to lists with items above 15 #60488

If no regressions arise, payment will be issued on 2025-05-20. 🎊

For reference, here are some details about the assignees on this issue:

• @thesahindia requires payment through NewDot Manual Requests
• @daledah requires payment automatic offer (Contributor)

[joekaufmanexpensify]

I noticed we are now showing a search bar on the company cards page when there's only one card assigned. Did that come from this issue? From OP, it seems like we only want to show a search bar for lists with more than 15 items.

[shawnborton]

Oh yeah, that is definitely a bug. We should only show the search bar when there are 15+ rows in the list.

[melvin-bot]

Issue is ready for payment but no BZ is assigned. @bfitzexpensify you are the lucky winner! Please verify the payment summary looks correct and complete the checklist. Thanks!

[bfitzexpensify]

@daledah can you look into the bug reported in #59864 (comment)?

[daledah]

@bfitzexpensify I've already put up a fix in #62260

[daledah]

@shawnborton The report fields page is different now, so we'll need a redesign to add search bar to this page.

[shawnborton]

Agree - I think we can just move the search input to be within that card wrapper and above the items. Thoughts? cc @Expensify/design

Alternatively, we can do nothing here too, as I wonder how common it is to have a ton of report fields...

[daledah]

For reference, here's what I came up with in #61686 (comment)

[shawnborton]

The width of the input feels way too wide though, can we match the other pages?

[dubielzyk-expensify]

The width of the input feels way too wide though, can we match the other pages?

Yeah, let's try that. If not, I'm also okay with ditching it for now, though It'd be nice to have it ideally

[melvin-bot]

@daledah Huh... This is 4 days overdue. Who can take care of this?