chore: Added size prop to TitleLeft component

[brianacnguyen]

Description

Added a size prop to the TitleLeft component to support different title sizes. This allows consumers to choose between medium (Md) and small (Sm) variants:

• TitleLeftSize.Md (default): Uses TextVariant.DisplayMd for the title
• TitleLeftSize.Sm: Uses TextVariant.HeadingLg for the title

This provides more flexibility when using TitleLeft in different contexts where a smaller title is needed.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: TitleLeft size prop

  Scenario: TitleLeft renders with default medium size
    Given the TitleLeft component is rendered without a size prop
    When user views the component
    Then the title should display using DisplayMd text variant

  Scenario: TitleLeft renders with small size
    Given the TitleLeft component is rendered with size={TitleLeftSize.Sm}
    When user views the component
    Then the title should display using HeadingLg text variant

Screenshots/Recordings

Before

After

Simulator.Screen.Recording.-.iPhone.15.Pro.Max.-.2026-01-19.at.15.02.45.mov

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Note

Introduces configurable sizing to TitleLeft for flexible typography.

• Adds size prop and TitleLeftSize enum (default Md) mapping title to DisplayMd (Md) or HeadingLg (Sm) in TitleLeft.tsx
• Updates Storybook: size control and examples in TitleLeft.stories.tsx
• Adds tests validating text variants per size, including mock for Text in TitleLeft.test.tsx
• Exports TitleLeftSize via index.ts; updates types and JSDoc in TitleLeft.types.ts

^{Written by Cursor Bugbot for commit 26994a7. This will update automatically on new commits. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 92%

click to see 🤖 AI reasoning details

This PR adds a new optional size prop to the TitleLeft component in the component library. The changes are:

1. New enum TitleLeftSize with Md and Sm variants
2. New size prop with default value TitleLeftSize.Md
3. Title variant selection based on size (DisplayMd for Md, HeadingLg for Sm)
4. Updated unit tests covering the new size functionality
5. Updated Storybook stories for documentation

Why no E2E tags are needed:

• The change is backward compatible - the default size is Md, which uses TextVariant.DisplayMd, exactly the same as the previous hardcoded behavior
• None of the existing consumers (ImportPrivateKey, ImportNewSecretRecoveryPhrase, ConnectHardware/SelectHardware, HeaderWithTitleLeft, HeaderWithTitleLeftScrollable) pass the new size prop, so they continue to work identically
• This is a purely visual/styling change with no functional impact on user flows
• The component is in components-temp (temporary/experimental component library)
• Unit tests have been added to verify the new functionality
• No critical paths, controllers, or core functionality are affected

View GitHub Actions results

[georgewrmarshall]

LGTM! Not sure how I feel about our testing approach for this one. I understand we want solid coverage for our components, and without these tests, we don't reach 100%. That said, mocking our Text component and testing internal props feels like a code smell, even if the intention makes sense. I'm wondering if a snapshot test might be more appropriate here. I don’t have a strong answer, but it’s something to think about. Is this the pattern we want to follow for app components that use MMDS components under the hood? Something to align on going forward.

[georgewrmarshall]

non-blocking: @amandaye0h have we got any code comments we can add here on when to use each size?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud