Same repo, multiple apps proof-of-concept

Goals

• Avoid 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

• Each “app” contains a distinct react-native root.

• Tracking provider is a service in each app

• Views are mostly the same, and can be configured with props

• “Containers” abstract out the difference between apps, that is… MainContainer listens to the GPS/BTE TrackingService, and reports such “state” down via props to a shared Main component

  • Main switches between all the core “No known exposure”, “tracking disabled” states.

• When functionality is very different, those components remain in the app directory, not in shared. e.g. Share location history might be different.

# 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.

// 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,
};