Run requests to the backend concurrently.

We need a system that can deliver translations of individual components in the website, such as question text, front page text, button text, etc.

Using a model with 4 fields might be a good starting point:

translation_model_object:
  id: GUID
  component_name: string
  language_code: string
  content: string

In the case of a missing object, a fallback system should be available, such as sending back a default language.

The translation might be obtained by a simple GET request, with a body such as this:

{
  "component_name": "question_1",
  "language_code": "en"
}

With a response such as:

{
  ...
  "content": "What is your age?"
}

Get the factors from the server instead of the hard-coded version.

Server side changes are currently part of issue #2

Create a way for factors to be grouped together such that one factor can have "sub" factors. An example would be the parity factor, which when > 0 has some accompanying questions.

{
  "factor": "parity",
  "question": "...",
  "answertype": "int",
  "maxdigits": 1,
  "requirement": ">;0",
  "subfactors": [
    {...},
    {...}
  ]
}

This way we can create a nested system of factors which only show up when we want to.

For the "requirement" the point is to give a way for the system to know if the subfactors should be displayed.

Requirements should have a syntax like: comparator;value such as >;0, =;T, <=;5, etc.

Part 1: Implement a system which can send a png (or link to a png on the server), and the language code to the client.
Part 2: Implement a dynamic language select, which populates the flag list based on the information given by the server.

Use a logging library in order to properly log events.

To maximize performance we need to split the code into smaller chunks so that the initial load will be smaller. I think we should strive to make the page as snappy as possible.

A library recommended by Google Lighthouse is loadable-components found here:
https://loadable-components.com/docs/getting-started/

Error message:

Warning: Failed child context type: Invalid child context virtualizedCell.cellKey of type number supplied to CellRenderer, expected string.

Steps to reproduce:

1. Run Metro in standard mode (Not production mode)
2. Open on Android/iOS Device (either in emulator or by QR code)
3. Press “Start Risk Assessment” and then “Click to see why we need this information”

This is needed for factors like ethnicity.

Create the first working version of the website, this will include:

1. A basic interface
2. A rudimentary system to send and receive information from the sever.

When changing language, you automatically jump back to the landing page.
Instead, we should try to preserve the current state of the site so that the questionnaire answers are not lost when changing the language.

While testing I realized that people who will use the site from countries like the UK will use the Imperial system for weight and height. To keep confusion to a minimum we should include a unit descriptor next to the text input such as:

______ kg

______ cm

Add the django-cors-headers dependency so that we can whitelist specific origins.

https://pypi.org/project/django-cors-headers/

Ask Anagha for the regression model

Change from TouchableHighlight to Pressable for future proofing.

Lighthouse accessibility problem with screen magnification.

[user-scalable="no"] is used in the <meta name="viewport"> element or the [maximum-scale] attribute is less than 5.

"Disabling zooming is problematic for users with low vision who rely on screen magnification to 
properly see the contents of a web page."

A common problem is that the question "Is your diet non-varied" is very hard to understand, because of this we should just hardcode that diet-non-varied is a specific case where if the answer is True then it should be treated as False.

The front-end question will then be something like "Do you have a varied diet".

The diet-non-varied keyword should be changed to diet-varied

Create a prototype of the website in Figma to create a goal for frontend development.

Lighthouse recommended that the flag assets should be larger than the size they are on the page. The flags are displayed as 32x32 images, and the images themselves are 32x32, lighthouse recommends increasing the size to 64x64.

This will most likely be done using React-Natives own Fetch API.

https://reactnative.dev/docs/network

@AlexanderDeBattista

Instead of going through the validation process, I am just returning the original dictionary. This is because the validation dict was not updated. Maybe there's a better way to do this? If that list is not updated, the whole page is useless.

Maybe we should just remove the keys that are not valid? (That does seem like it will create problems in the future, problems that may be very hard to track down).

So far we haven't really looked into how to web version works on devices such as phones. This should be fixed as it's important for the usability.

Currently it's almost unusable, unless if we put it into desktop mode, which is subpar at best.

Just need to change Form.js import line 19 to
import Progressbar from "./Progressbar";

and Results.js line 6 to
import ComplicationProgressbar from "./ComplicationProgressbar";