…y/e-mission-phone into migration-wrapup

…s/e-mission-phone into migration-wrapup

…y/e-mission-phone into migration-wrapup

…barry/e-mission-phone into migration-wrapup

…m/niccolopaganini/e-mission-phone-nvsr-iter1 into migration-wrapup

…eelis/e-mission-phone into migration-wrapup

-In useAppConfig.ts, we can't rely on $ionicPlatform anymore since we won't be using Angular moving forward. So we need an alternate way to ensure Cordova plugins are ready before we try to do stuff with them. I found that Cordova fires the 'deviceready' event once plugins are loaded - so we can just listen for that, wrap it in a promise, and use it in the place of $ionicPlatform.ready(...)
-There were a few uses where getAngularService() was still used to access the old Logger, which were easily substituted to instead use the functions exported from logger.ts (logDebug, logWarn, etc)
-There were several unused imports left over in files where getAngularService was formerly used and is no longer

The startup logic will now happen not in an Angular context, but with an event listener for 'deviceready' (which is what Cordova uses)
And the React initialization will happen from there.

…m/niccolopaganini/e-mission-phone-nvsr-iter1 into migration-wrapup

…s/e-mission-phone into migration-wrapup

Since these have both been simplified we can merge them together

It was failing because 'commHelper' is no longer directly in '/js' -- it is in 'js/services'

This commit enables strictNullChecks for greater type safety and then fixes the dozens of instances where TS now warns us about values that are potentially null https://www.typescriptlang.org/tsconfig#strictNullChecks

This means adding types on a lot of places where we had not added types before. Typescript is more powerful when it's on a stricter configuration, but this means we have to be more explicit.

In a few of the files, I also cleaned up formatting and modernized syntax while I was making changes there.

continuation of 49a1a64

This file had a lot of outdated JS syntax and console.log statements. I just did a full sweep of this file and 'modernized' it.
Added some type definitions too.

I previously used the wrong property name here. Now that we have Typescript on a stricter configuration, I found my mistake

e-mission/e-mission-docs#1029

We previously had maintainers for the translations in these languages, but they have not been updated in a very long time. Because the app has changed so much since then, the old translations are almost entirely obsolete.
At this point, I think it is better to remove them from usage. If we ever get someone to update the translations we can add them back.
We'll still keep the old translations up on the e-mission-translate repo although they won't be used here.

VSCode was only picking up on our declaration TS files if they were open in the editor. This signals to VSCode and TS to check js/types for .d.ts files.

This file was a JSX file until very recently and so a lot of type errors and warnings went unnoticed. There were a lot, so I just went over the whole file - fixing typings, modernizing syntax, and removing things that are unused.
As part of this I expanded the typings for AppConfig.

Continuing to clean up type warnings that are now showing up since 49a1a64

dt might be undefined here (like in the case of the most recent / current place in the timeline)
In that case we should return nothing instead of letting Luxon create a new date (it would fallback to the current date&time which we don't want)

this is used in a few places - it's tidier to have a common type definition

i) instead of providing timelineLabelMap and timelineNotesMap to the entire component tree under LabelTab, we can pass accessor functions (userInputFor, labelFor, notesFor) to get user inputs in a cleaner way

ii) Unify the structure of how multilabel vs enketo user inputs are kept on the phone. Now both will be the 'raw' format (an object with 'data', 'metadata' etc).
Note that there is still a discrepancy on the server - for multilabel inputs we get a plain string and for enketo inputs we get the whole userinput entry.
The plan is to unify this on the server at some point, so I am doing it here on the phone in advance.

iii) instead of using a 'justRepopulated' flag to signify that an entry should not be filtered within 30 seconds of having a user input recorded on it, we can just look at the write_ts in the metadata of that entry's inputs and see if it was within 30 seconds ago. If so, it's immune to filtering.
After a label is recorded and added to the timelineLabelMap, we'll trigger a refilter after 30 seconds by calling setLastFilteredTs.
This approach negates the need for an extra property on the timelineEntry object - which is good because we want it to match the server type.

This useEffect was watching timelineEntry for updates, but we changed the mechanism so timelineMap is no longer updated -- only the timelineLabelMap gets updated when a new response is recorded. By watching the result of userInputFor(...), this component will recieve the update.

This has always been a property on the server for trips as well as places. For some reason I must have missed it on the first pass of making the ConfirmedPlace type definition.

It keeps the codebase more logical (and more modular) to keep Enketo survey-related type definitions encapsulated away in enketoHelper.

When we have Typescript compiler in 'watch' mode (useful for linting/ finding type errors in VSCode), it outputs to the root level directory 'dist'. Adding this directory to gitignore so we don't end up needlessly committing these output files.

Each tab gets wrapped by an error boundary. We were doing this in the body of the App component which means every time the App component was updated/rerendered, the tabs were recomputed too.
Doing the error boundary wrapping outside of the App component ensures that it only happens once and we use the same tab components each time

-Fix size of Leaflet markers
-- this changed when we removed all the extra CSS bloat and easy one line restores the previous size

-Unify app bar styles
-- removed elevation: 3 to soften the shadow (default is 1 and matches the rest of the app better - we were only using elevation 3 to match the style of the Ionic header)
-- use 'colors.surface' instead of hardcoded 'white'

- unify 'notesButton' style of diary cards
- add paddingHorizontal to ModesIndicator
-- this way, if there are a lot of modes, they have room to breathe

…barry/e-mission-phone into migration-wrapup

…y/e-mission-phone into migration-wrapup

As in fa1dfbf, TypeScript puts output files here. We don't need git NOR Jest to pick up on these 'dist' files.

…-mission-phone into migration-wrapup

…-mission-phone into migration-wrapup

…y/e-mission-phone into migration-wrapup

With invalid inputs, this function should return early rather than continuing and resulting in a zero-length duration.
Fixes the diaryHelper test that was failing.

We need a safe way to mark that validation fails in this function, without actually throwing an error. Let's use a third parameter for this purpose which is a callback function 'onFail' to handle the invalid case.
- Updated tests accordingly - now passing

…-mission-phone into migration-wrapup

…barry/e-mission-phone into migration-wrapup

…y/e-mission-phone into migration-wrapup

Typescript wants us to be more explicit about what could be null/undefined and what couldn't be.

transitionTrip2TripObj should return a Promise that could resolve as an UnprocessedTrip or undefined.
(If undefined, it gets filtered later in readUnprocessedTrips)

We also need to address that Luxon's DateTime.toISO has string or null as the return type – null is for if the input was invalid. It never should be, but if it was for some reason we can have an error dialog and assert type with an empty string.

mockUnprocessedTrip was unnecessary and not used anywhere
mockFilterLocation didn't need all these fake properties and instead could just include the few that are needed and then declare it 'as FilteredLocation'

enketoHelper.test.ts had a lot of the wrong types in the fake responses. They were all strings but I've since updated them so there some strings, some numbers, objects.
EnketoResponseData in enketoHelper is correct.

- some other type casting (with 'any') in both of these tests to ensure fake inputs satisfy parameters types

this test still had LabelOptions type for the userInput values instead of the UserInputEntry type.
It didn't cause the tests to fail because inferFinalLabels and verifiabilityForTrip only check that the values exist - they don't care what properties they have.
Anyhow, the types line up now.

this test still had LabelOptions type for the userInput values instead of the UserInputEntry type.
It didn't cause the tests to fail because inferFinalLabels and verifiabilityForTrip only check that the values exist - they don't care what properties they have.
Anyhow, the types line up now.

…sion-phone into migration-wrapup

…barry/e-mission-phone into migration-wrapup

In 4f173ba I bumped the prettier version to 3.1. Whatever version we are using for the project should be the same as the workflow runs with (as we established in e-mission#1117)

We wanted to keep the 3.1.0 not downgrade to 3.0.3

-- Part of the fix for e-mission/e-mission-docs#1034

When a user input is recorded, we put it in storage. For snappy performance we also cache it in the timelineLabelMap / timelineNotesMap state.
However, if we switch filters or load more trips, this state gets overridden. So, we need to call updateLocalUnprocessedInputs at some point.
It is an async function but we can call it without 'await' and just allow it to execute in the background.

-- Part of the fix for e-mission/e-mission-docs#1034

When the yellow checkmark is used to verify a pair of inferred mode+purpose labels, both labels should be verified by a single click.
The labels get stored fine; however, the way we update state after doing so prevents both labels from being updated simultaneously and only one of them gets filled in. The resulting UX is that it takes 2 clicks and this is not desired.
We could: update state in succession, one after the other (await label A, then proceed label B),
OR we could rework these functions to support adding labels for a particular trip as a batch (so the same function call could store mode+purpose at the same time). This was decided as a better and more performant option.

It uses Promise.all to store all labels from the batch, then it updates the state with all changes from that batch.
When a single label is recorded, it is a batch of 1 - when verifying inferences, it may be a batch of multiple labels.

When selecting date, the following behavior occurs:
- If 2+ days, behave as normal (Range of Day1 -> Day2)
- If  "open Ended" (i.e., only start is picked), fetch
  a range of days between that day and present (Day1 -> Today)
- If 1 day, fetch range for 48 hours from that day

TODO: The 1 day range going to 48 hours is meant as a patch, so that
this WSOD fix can go to staging.  To make a single day only fetch
24 hrs, some changes to the server may be needed.

🗓️ Fixed WSOD on Metric Date Selector

Instead of mutating an extra property 'displayDt' onto the entries, let's use a get function that returns the displayDt. This should fix issue (4) in e-mission/e-mission-docs#1034.
And let's also memoize that function so performance is not impacted

If something was thrown, it could display 'undefined' if 'err' was an error message and not the error object.
Using the displayError function is a more proper way to guarantee we see any error messages

- 'key' could be kept in 'data' or 'metadata' depending on if it is a processed or unprocessed entry (this is an inconsistency we may want to revisit later)
- handle possible null/ undefined parameters in functions: check for truthy inputs before executing

…-mission-phone into migration-wrapup

-In useAppConfig.ts, we can't rely on $ionicPlatform anymore since we won't be using Angular moving forward. So we need an alternate way to ensure Cordova plugins are ready before we try to do stuff with them. I found that Cordova fires the 'deviceready' event once plugins are loaded - so we can just listen for that, wrap it in a promise, and use it in the place of $ionicPlatform.ready(...)
-There were a few uses where getAngularService() was still used to access the old Logger, which were easily substituted to instead use the functions exported from logger.ts (logDebug, logWarn, etc)
-There were several unused imports left over in files where getAngularService was formerly used and is no longer

The startup logic will now happen not in an Angular context, but with an event listener for 'deviceready' (which is what Cordova uses)
And the React initialization will happen from there.

Since these have both been simplified we can merge them together

It was failing because 'commHelper' is no longer directly in '/js' -- it is in 'js/services'

This commit enables strictNullChecks for greater type safety and then fixes the dozens of instances where TS now warns us about values that are potentially null https://www.typescriptlang.org/tsconfig#strictNullChecks

This means adding types on a lot of places where we had not added types before. Typescript is more powerful when it's on a stricter configuration, but this means we have to be more explicit.

In a few of the files, I also cleaned up formatting and modernized syntax while I was making changes there.

continuation of 49a1a64

This file had a lot of outdated JS syntax and console.log statements. I just did a full sweep of this file and 'modernized' it.
Added some type definitions too.

I previously used the wrong property name here. Now that we have Typescript on a stricter configuration, I found my mistake

e-mission/e-mission-docs#1029

We previously had maintainers for the translations in these languages, but they have not been updated in a very long time. Because the app has changed so much since then, the old translations are almost entirely obsolete.
At this point, I think it is better to remove them from usage. If we ever get someone to update the translations we can add them back.
We'll still keep the old translations up on the e-mission-translate repo although they won't be used here.

VSCode was only picking up on our declaration TS files if they were open in the editor. This signals to VSCode and TS to check js/types for .d.ts files.