Page MenuHomePhabricator

Decide how to handle TypeaheadSearch's button display logic
Closed, ResolvedPublic

Description

Background/Goal

The TypeaheadSearch component is designed and built on top of the SearchInput component and, like its "parent", it should present two anatomic variants:

  • A variant that features only a single input type search
  • A variant that also includes a 'Search' button besides the input

Nevertheless, the current released version of the TahS component displays its search button when users hover on the element. How might we capture this logic?

Options

  1. (Initial decision) Make this idiosyncratic behaviour to be handled by the application. The logic that makes the Search button to be displayed on hover/active could be considered to not be core to the component, and thus would need to be implemented in context.
  1. Nevertheless, since the TahS will be reused with its current logic in many of our projects, it would be reasonable to simplify its reusage by allowing implementers to enabe this logic via a prop (e.g. "hideButtonByDefault" or "showButtonOnHover") of the "with button" version. Problem: we'd be contradicting our component architecture by adding this configuration to only one of the variants of the component, since component configuration should be shared between variants.
  1. Creating a new variant of the TahS component that includes this logic. We'd need to consider whether we'd then want to apply this behaviour to the parent SearchInput component.
  1. Make this the default behavior of the TahS component in Codex. (Wouldn’t be aligned with the default behavior of its parent, the SearchInput component)
  1. Create a new variant of the SearchInput component that displays this behavior, and a subsequent TahS variant derived from it

Event Timeline

STH triaged this task as High priority.Apr 30 2022, 5:58 PM
STH lowered the priority of this task from High to Medium.

Hey @Jdlrobson 👋🏻 I was wondering about your / the Readers Web team's opinion regarding the first suggested option:

(Initial decision) Make this idiosyncratic behaviour to be handled by the application: The logic that makes the Search button to be displayed on hover could be considered not core to the component, and thus would need to be implemented in context.

You'll have to excuse me if I'm assuming something technically incorrect or obvious, but: would it be possible to implement this behavior (displaying the component's button on hover) as part of the Vector implementation of the Codex TypeaheadSearch component? And, could this be done in a way that ensures that the behavior will be consistent if the component is reused as part of the Vector skin by other projects?

Thank you!

Volker_E renamed this task from Decide how to handle button display logic to Decide how to handle TypeaheadSearch component button display logic.May 16 2022, 8:30 PM
Sarai-WMDE renamed this task from Decide how to handle TypeaheadSearch component button display logic to Decide how to handle TypeaheadSearch's button display logic.May 20 2022, 3:21 PM

Working decision: The DS team decided to proceed to remove the button display logic (making the button available on hover) out of the core Codex component.

The behavior will need to be introduced in context, as part of the new Vector 2022 skin implementation of the component, and distributed from there.

Follow-up task: T309722: Remove logic to display button on hover from TypeaheadSearch component