[TRACKING] Split SelectionList into smaller, purpose-built list components

[mountiny]

coming from here

Proposal

Split SelectionList into smaller, purpose-built list components

Strategy

Expensify’s blue ocean strategy depends on shipping features quickly without destabilising the app. Engineering velocity directly improves Free Cash Flow by reducing time spent on regressions and long PR cycles. Refactoring a critical UI primitive will shorten future feature lead-time and lower maintenance cost per customer seat.

Background

The highly adaptable SelectionList component is based on React Native’s SectionList, which demonstrates its flexibility for various purposes. It has become very complex, supporting over 90 properties and being used in 107 different components. This design was aimed at reducing repetition and covers many functionalities, making it a central component of many projects. On the other hand, developers often have to work with its many settings to make changes, which can easily cause regressions in some use cases. This complexity means there’s a lot for new developers to learn about how to use and integrate the component. A similar change was done recently where the refactoring of the SearchList sped up its rendering by 1.5 seconds (almost 40% improvement).

Problem

When a developer changes list behaviour in SelectionList, they modify a 90+ prop monolith referenced by 107 components, which frequently causes regressions and lengthens feature delivery time.

Solution

Break the current SelectionList down into several smaller, more focused components. Each component will be designed for a group of similar cases, making them simpler and more streamlined. This approach will reduce the complexity of each component, remove unnecessary props and simplify the operations inside. The plan for this refactoring involves the following steps:

1. Audit usage across all 107 components to identify clusters of similar configurations and usage patterns.
2. Define smaller components for each identified cluster, with logic and props needed only for the specific case.
3. Gradual migration strategy - Introduce new components incrementally and replace existing SelectionList usages one by one to avoid large-scale disruption.
4. Clean-up - Once all usages have been migrated, remove the original SelectionList.
5. Define guidelines for contributor on how to decide when to create a new list and when it's still ok to update existing list knowing it will make it "heavier" and more compled

Advantages
This will result in:

• Improved performance: Fewer props and conditional branches will result in faster rendering and fewer re-renders.
• Better maintainability: Changes are isolated and the risk of regression is much smaller. Also testing will be faster as there would be less cases to check.
• Simpler debugging: Smaller, more specific components are easier and faster to understand and troubleshoot.

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details. Please add this Feature request to a GH project, as outlined in the SO.

[mountiny]

Looking for internal engineer to help with this but @zfurtak I believe you can start looking into ways to split this up, make sure to create this in small PRs that are easy to test and review please. Thanks!

[zfurtak]

I've been thinking about how to get this issue started, and I've come up with a plan:

So, what is the plan? ✨

So far, I've looked into which components use the SelectionList, and it turns out that around 80%(!!) of its usage doesn't involve sections (more details here). I'd suggest taking it one step at a time.

What would be the first step?

First things first, I would create a new list component that doesn't involve sections. This could then be used in all relevant cases. Once that's in place, we could check potential performance improvements in more complex scenarios — there's a good chance the gains might already be significant at that stage. 🚀
Next, we could make a list of components to update so that they use the new list. From there, we can start creating pull requests iteratively, refactoring one component per PR. This would make it easy to divide the work among developers and reduce the risk of regressions.
Later on, we could consider a more detailed breakdown into specialised components, using the new universal list as a base — in line with the DRY principle.

What about the components that need sections?


After we've dealt with the non-section use cases, we can then focus on making the ones involving sections better. One approach could be to group them based on how they are used, making it easier to design specialised components. We could also optimise the SelectionList (or create a new one), it will be possible and easier as there will be only 25 usages left to cover (instead of 125).

Let me know what do you think 😊

[mountiny]

That sounds good to me

[mountiny]

@zfurtak 👋 Georgia @grgia will help you push this ahead from internal side

[grgia]

@zfurtak, the plan sounds good. Could you please break it down into a bulleted list representing each piece of the plan (in the smallest PRs possible) for me? I'm sure you know, ideally we'd want to avoid any massive PRs since they are easy to revert 😁