This repository contains the client for providing access to data about services for refugees and immigrants to BC.
The client is implemented in react-native, using create-react-native-app, redux, redux-first-router, native-base and lingui.
With a fresh repository, this will get the application compiled and running on Expo:
Install dependencies
yarn install
Copy example configuration file and modify accordingly (set your own API host, Sentry auth token etc).
cp .env.example .env
Compile TypeScript, optionally watch source files for changes and build them automatically
yarn build [--watch]
Run tests, optionally watch source files for changes and run the tests automatically
yarn test [--watch]
Build and start Expo to run the app in a simulator or on an actual Android or Apple device, optionally clear cache
yarn start [-c]
To clear out cached values from .env, use --reset-cache.
We are using jsLingui and Weblate for translation and internationalization. We translate strings through our own Weblate application here: translate.peacegeeks.org. The source strings for Arrival Advisor, as well as information on how we integrate Weblate into our workflow can be found here: https://github.com/tomy-pg/ui-strings.
To update the in app translations:
-
git clone git@github.com:tomy-pg/ui-strings.gitto retrieve the translated strings. This is the source of truth for all strings translated using Weblate. -
cd pathways-frontendand run./bin/strings --combine-pos. This command expects the../ui-stringsdirectory from step 1 to exist and will not work without it. Once this command is run, a messages.po file will be generated for each locale. Each of these files contain pairs of English source strings and their translated versions. -
yarn build-stringsto generate compiled versions of the messages.po files. Themessages.jsfiles generated are the source catalogs Lingui uses for internationalization. Source catalogs are used to lookup translations when English strings are wrapped with<Trans>tags.
These are the entities of the client side data model:
If you want to help out, get in touch at info@arrivaladvisor.ca.
All commits are labelled with the issue they are being done under. This ensures that we don't do work that is not tracked, and history of why every change is made is maintained. Most front end and back end work is tracked by issues in their respective repositories, in which case the commit message should start with "Issue #N", e.g. "Issue #13". Occasionally, front end work may be tracked under backend issues, in which case each commits message should start with "Issue pg-irc/pathways-backend#13".
- Client and server are versioned independently.
- Client specifies the minimum server version required for proper client operation.
- We use semantic versioning of the form X.Y.Z.
- We start with version 1.0.0 for client and server.
- The version string of the client or server is done in the same pull request that contains the changes that require the version to change.
- We bump the Z each sprint, except for sprints where no changes went in. We also bump Z for any hotfixes that may go in independenty of the sprint cadence.
- We bump the Y when we add features that are backwards compatible as per semantic versioning.
- We bump the X when we add features that are backwards incompatible, i.e. when the client would fail to operate correctly with an older server version, as per semantic versioning.
- Versions are stored as git tags in each git repo (client and server).
- On the server side, the version is stored in VERSION.txt.
- On the client side, the version is stored in VERSION.txt and several other files, with unit tests making sure that all version strings are the same.
- Client About screen shows the version of the client.
Changes that are made in each release are tracked following Expo's procedure.
- changelog is updated with every PR that affects functionality.
- a new heading is added to the changelog as part of every PR that bumps version strings.
Cross-browser Testing Platform and Open Source <3 Provided by Sauce Labs