serikjensen

UI Flexibility Exploration for the React SDK

This document proposes a high level solution that fits the updated partner requirements for SDK UI flexibility. This solution is inspired by composition found in other SDKs that have successfully made their core functionalities available in flexible, UI agnostic ways. It is also leveraging and enhancing React SDK patterns we are already familiar with.

Proposed solutions in this document still need stress testing and rigor that will come from prototyping. The purpose of presenting this document at this time is to gather initial feedback to determine if we should pursue one (or multiple) of these solutions more in depth (via prototyping) or if we feel we are yet to have a solution that is a good candidate and feel like we need to continue iterating.

Requirements

Partner

• Partner should be able to place SDK CTAs anywhere on a page, even outside the bounds of a rendered SDK component
• Partner should have control over the ordering of SDK content

serikjensen

TileRow can be used with the FeaturedLocationCard and the LocationCard

There are some caveats, however

• You will need to complete this ticket for allowing setting the tile widths
• You will need to use the TileRowItem component as a wrapper for each individual item

This ends up looking something like this:

serikjensen

Future of mobile forms

Goal

Have a uniform, easy to implement approach for mobile forms that results in consistent UX across the app.

Project scope and deliverables

There are two main areas where we are looking to gain team consensus

• Best practice implementation approach for forms moving forward
• Choice of form library

serikjensen

Sharing Props and State with React Native Styles

There are situations where we want to be able to share props and state with the styles in React Native. We want to figure out a consistent way of doing so.

Context

Take, for example, a simple component where we are changing the background color between two options

interface MyComponentProps {

serikjensen

Description

We should migrate instances of

import { Text } from 'react-native';

to do

serikjensen

Intro

We are looking to standardize how we specify component properties when they are an enumerated set of options within the mobile codebase. TypeScript provides both enums and unions for this purpose, but each has benefits and drawbacks. This document seeks to outline team goals and the benefits/drawbacks to both approaches in fulfilling these goals.

Definitions

Enums: Enums allow a developer to define a set of named constants. Using enums can make it easier to document intent, or create a set of distinct cases. TypeScript provides both numeric and string-based enums.

Unions: A union type describes a value that can be one of several types. We use the vertical bar (|) to separate each type, so number | string | boolean is the type of a value that can be a number, a string, or a boolean.

Goals

We want the chosen approach to meet the following criteria

serikjensen

PropertyTable component is now deprecated. We are going to replace it with DescriptionList instead.

PropertyTable upgrade to DescriptionList guide

PropertyTable prop	Updated DescriptionList prop	Notes
alignRowItems	alignRowItems	(No change)
caption	No replacement	This prop doesn't exist on DescriptionList and can be removed when updating
children	children	(No change)
propertiesLabel	No replacement	This prop doesn't exist on DescriptionList and can be removed when updating
propertiesMaxWidth	termsMaxWidth

serikjensen

const WorkExperienceProfileCard = ({ data }) => {
  const profileCardSummaryItems = [
    {
      label: 'Unit',
      value: data?.unit,
      isRequired: true,
    },
    {
      label: 'Location',

serikjensen

Updating Links

Linking in Vivian

Before starting on these tickets, it will be important to familiarize yourself with linking in our application. We use both a Next JS and React Redux application and need to link between both of them. For some more context, see this article on cross app linking here

Accounting for cross app linking when replacing with the base Link component

Our Link component only handles the styles. It does not handle any of the functionality, that is provided by the cross app linking components. The Link has a component property that can be used to set it to a next, main, router link as needed. For more info, see this section on usage with cross app linking.

serikjensen

How do we define tokens in TS?

• Looks like simple enum gives us flexibility to either have consumers import the enum and apply it to the component or use the current style where the object keys are used in the component API
• Once we define tokens in TS, we can transpile to the correct target and make them consumable for TS and JS apps

How should components implement tokens as part of their API?

• See codesandbox example for TS
• See also slack discussion
• Consensus growing around importing the constant even though that's more keystrokes (pretty straightforward migration path on web where we can just reconfigure any color prop to take either the key or the hex code)

What things should be shared from the design dir and what things should be implemented in the web repo?