A Galactic Voyage Log: Navigating Toward Good-Quality Code in a Search Service

To respond to rapidly changing policies and UI requirements, the 11st search/recommendation service frontend redesigned the structure of its existing search code around agility and flexibility. PC had a high proportion of common component reuse, while mobile had many independently implemented per-collection, each with different strengths and weaknesses, so rather than simple commonization, separating responsibilities to fit the search domain became the core task.

The search screen is broadly divided into listing and collection: listing is the standard product UI, and collection is the purpose-driven curation UI. As collections increased, exposure methods and sizes became inconsistent, and actions like left-right swipe and see-all landing pages grew more numerous, increasing congestion. To reduce this, in 2023 a common guide for listing and collection was established, and improvements proceeded in the direction of increasing UI consistency.

The starting point of the design was breaking change units into smaller pieces. Product information was abstracted into the minimal policy units such as product name, price information, and shipping information, and areas that change frequently were distinguished from those that don't, redistributing component responsibilities accordingly. In particular, since Props simultaneously determine coupling and reusability, a standard was set that if there are 4 or more Props, the entire item is passed, and otherwise only the necessary values are passed explicitly, balancing flexibility with clarity of dependencies.

Where exposure conditions are handled—parent or child—was also separated. When multiple child components need to be controlled together or conditions are complex, the parent takes charge; when simple conditions relate only to a specific child's behavior, they're handled inside the child. Following this principle, CollectionVisibilityManager was introduced to manage exposure rules by product type and tab in one place, allowing dynamically changing rules like product options to be controlled consistently as well.

Rather than forcibly reusing the exact same structure as listing for collections, it was concluded that creating a new component is better for maintainability when policies differ. Conversely, minimal units with low likelihood of change, such as detailed elements within the price area, were reused to reduce duplication. Finally, Wrapper components such as Thumbnail, HeadLine, GridRow, and GridColumn commonized the markup structure, laying a foundation that can flexibly respond to company-wide common markup policy changes as well.