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.
How will we sync any manually linked native packages between the two projects?
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,
};
CI/CD
Currently we have github workflows set up to run tests, generate artifacts, and deploy. We’ll want to duplicate the workflows for artifact generation and deployment, but run tests for the entire repository as one.
Add Comment