Page Comparison

Goals

• Minimize separate repo tasksAvoid separating repo management efforts into another location

  • Who is maintaining old PrivateKit? not us

  • Who is maintaining old tripleblind/covid-safe-paths? not us.

• Minimize need to “sync” manually and face merge conflicts.

  • Sync + merge overhead will increase churn, and risk burn out.

• Visual design patterns are changed in one place, shared.

  • Visual alignment and polish is a never ending process, it can always be better. e.g Animations, delight, performance fixes. Diverging would hurt both repos.

Open questions

• How do we keep GPS and BTE separate enough that one will not accidentally turn on via a release?

  • Deploying an app that doesn’t have one of the assets enabled will make it so we can’t request it, IIRC. Apple and Android won’t accept a build that requests permissions it doesn’t have access to.

• How would i18n work?

• Branding, logos, splash screens.

Options

Two RN heads, shared packages with yarn workspaces or lerna

...

# existing app
gps/
  app/
    services/
      GpsService.js
    views/
      # fetch state from service, but pass to shared view
      MainContainer.js
      ExposureHistoryContainer.js
      ShareLocation.js # different, no shared component
    App.js
    ...
  android/
  ios/
  .env
  .env.release

# BT app
bte/
  app/
    services/
      GaeService.js
    views/
      ShareLocation.js # very different, no shared comp
    App.js
    ...
  android/
  ios/
  .env
  .env.release
  
# shared packages via yarn workspaces
packages/
  @safe-paths/
    ux/
      Theme.js
      Button.js
      IconButton.js
      NavWrapper.js
  # shared views, could work. We could have containers around them in app land ^
    views/
      main/
        NoExposure.js
        UnknownExposure.js
    services/
      # would there even be shared services?
      # language.js?

App specific containers

...

Each “head” can provide services or different routing/navigation, flows.

Code Block
language js
// gps/app/views/MainContainer.js import { GpsService } from '../services/gps_service'; import { Main } from '@safe-paths/views/Main'; import { Button } from '@safe-paths/ux/Button'; // or whatever export const MainController = ({navigation}) => { // assume useEffect const {canTrack, hasExposure} = await GpsService.checkStatus(); return ( <Main canTrack={canTrack} hasExposure={hasExposure} showHistoryPress={goToHistory} /> ); }

Shared components will need to be developed to allow some customization. This is not a new thing, common components should always consider slight variations and extensibility/config.

Theming/branding

The theme system already has a decent amount of power, but it could be adapted to allow each app to share some themes, and define new themes. The basic concept of themes stays the same: theme config flows down and common components read from theme config. It could be extended to iconography and logos:

// bte/app/themes.js
import {defaultTheme} from '@safe-paths/ux/themes';
import {bteLogo} from '../svg/bteLogo.svg';

export const defaultTheme = {
  ...defaultGpsTheme,
  logoSvg: BTELogo,
};