What is this about?

There are currently different styles associated with how navigation API calls are made in the codebase. For example, we'll see:

• Screen names defined as constants or inline string screen names
• HOF such as create...NavigationDetails utils or lower level navigation method invocation

This change proposes to consolidate these styles to remain consistent across the app. The style proposed is to use inline strings, which removes the need to manage another source of screen names as constants. Another proposal is to just invoke the navigation API instead of using HOFs to reduce complexity. The navigation methods is already aware of the global navigation types, immediately letting devs know if TS errors are present.

Scenario

No response

Design

No response

Technical Details

• Replace all screen constant names with inline strings
• Replace all create navigation details HOFs with navigation API call

Threat Modeling Framework

No response

Acceptance Criteria

• Navigation actions still behave the same

Stakeholder review needed before the work gets merged

• Engineering (needed in most cases)
• Design
• Product
• QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• Security
• Legal
• Marketing
• Management (please specify)
• Other (please specify)

References

• Draft PR from @Cal-L with example - 513eacf