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

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

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

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.

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 #1117)

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

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

…sion-phone into migration-wrapup

This test failed due to a bad merge conflict resolution.
This commit reverts notifScheduler.test.ts to the state of 3cbb5f0 after sebastianbarry's fix.
The test now passes.

- ReminderSchemeConfig should be ReminderSchemesConfig - a problem that resulted from resolving merge conflicts
- Defining types in notifScheduler.ts so that the functions have return types and Typescript type warnings go away

-- With 'strictNullChecks' enabled in Typescript, we get type errors when declaring objects of a type with some of its properties missing.
But for the purpose of testing (ie fake data, potentially invalid inputs) we want to do just that. We can get around this by hard casting with `as unknown as <T>`.
In tests, for blank/invalid inputs being used (such as a blank CompositeTrip object) we can use `{} as any`

This fixes a bunch of type warnings that show up with strictNullChecks being true.
Fixes include adding types, disambiguating null and undefined types and handling them more carefully, and disambiguating trip vs place with type guards

With this change, any remaining uses of the `moment` library from datetime operations have been fully replaced by Luxon.
All references to moment are removed.

When using AngularJS, jQuery needed to be provided as a global by Webpack. Now, we do not need it at all (except Enketo which still uses jQuery internally, but provides it to itself and is not needed globally.)

(initiative previously described in 0527569)
>To be more consistent with the rest of the codebase, as a rule of thumb we're having top-level functions use 'function' synax while one-liners or nested functions are arrow functions.

Named functions that are at the top-level of a file, React component, or custom hook, should be declared as `function foo() { ... }`.
Anonymous / inline functions, and one-liner functions, will be declared as `const bar = () = { ... };`

These general rules should help to keep some consistency throughout the codebase.

in ES6, 'const' and 'let' are preferred over 'var', which is sort of outdated now.
In a few places 'var' was still used. For best practice we replace these.

-- Replace all uses of console.log or console.debug with the functions from logger.ts (logDebug, logWarn, displayError). This ensures that all log statements are recorded by both the Javascript console AND the Cordova Logger plugin
-- Format all these log statements concisely and in a unified way (longer statements make use of `template strings` with interpolation, and the statements are put on as few lines as possible to mimimize clutter)
-- Remove log statements that are deemed redundant or excessive (we want to be thorough but not spammy - avoid log statements that run on every single re-render)

🎀 UI Migration Wrap-up

Processed responses for user input surveys were not being matched because they were being looked up under "manual/trip_user_input", while it should have just been "trip_user_input".
This is because we were only invoking a function to trim off "manual/" for MULTILABEL user input matching, and it was neglected for ENKETO.

Revise the functions in confirmHelper (keeping 2 versions, `removeManualPrefix` which just trims the key, and `inputType2retKey` which looks up the key and then trims), and use `removeManualPrefix` in inputMatcher appropriately

Some day we can unify the data model (e-mission/e-mission-docs#1045) and not keep 2 versions of so many things

Adds basic unit tests for mapInputsToTimelineEntries under both MULTILABEL and ENKETO configurations.
It considers fake user inputs that are processed, and those that are unprocessed, and ensures that the returned map includes both.

🚑 Fix Processed Trip Survey Responses Not Matching

…-mission-phone into screen-reader

🎀 Final change of the service rewrite

We plan to support a conditional approach to surveys: depending on characteristics of the trip / timelineEntry, it may prompt for one survey or another.
This involves rearranging UserInputButton so that the survey name is not hardcoded as "TripConfirmSurvey". Instead, survey names and button labels will be pulled from the config.
Each survey that could show conditionally has a `showsIf` field, which is evaluated at runtime in conditionalSurveys.ts. The first survey whose condition matches is the one that is used for that timelineEntry.

…ground fixes

Bumped data collection version

See Issue [#1046](e-mission/e-mission-docs#1046 (comment))
for more details.  This commit adds the Dev-Zone settings option, which
will eventually link to the Bluetooth Scanner page.

TODO:
- Add i18next translation for control.bluetooth

The button added in settings now will open a Modal "Page" that
will (eventually) contain the bluetooth devices within scanning
distance!

….tsx


These are old changes from before I took over the PR, I can go ahead undo them

….tsx


These are old changes from before I took over the PR, I can go ahead undo them

It seems I accidentally turned off my local VSCode Prettier... Fixing
that now

🧹 📊  Metrics cleanup

👤🔊 OP Accessibility: Screen Reader Improvements

…oad on build.

…eated bluetoothScanner.ts which houses the plugin scan request. I then added in functionality to the BluetoothScanPage to output the data that we get from the scan function.

…into code-cleanup-jan2024

This was added in a relatively recent version of i18next; some online resources haven't updated to reflect it
https://www.i18next.com/overview/api#resolvedlanguage

`language` is what i18next detected or we have set it to. It could be either a locale code like 'en-US' or a plain language like 'en'.

`resolvedLanguage` is what language is actually being used for translation, after considering what is detected, what langauges we provided, and what fallbacks we specified.

In our case this should always be either 'en', 'es', or 'lo' - the 3 languages we support at this time.

So `resolvedLanguage` is the safe property to use and we should avoid `language`.

#1106 (comment)

GIven that the configs are JSON and we can only give the "showsIf" conditions as strings, it will be annoying if they get too lengthy.
This will allow us to reference trip properties directly (e.g. "end_loc" instead of "tlEntry.end_loc") which is a bit more concise and readable.

Although the 'ch' unit works here, is not officially a valid type for React Native Web
Changing to `25` to match the Label screen DateSelect

The `Icon` component was added in 5.11.0 and is referenced in CustomLabelSettingRow.
So we must use 5.11.0 at minimum

- Formatted buttons
- Added `BluetoothCard.tsx`
- Centered buttons & Device Info
- Fixed "Dismiss" Button, updated to arrow

Added english translations for scanner components

Reach Native Paper didn't have a standalone <Icon> component until recently. Now that it does, we can get rid of the component we had made and just use theirs.

If `getConfig` resolves to null (meaning there is no stored config & we are on the Welcome page), then we should not call Object.keys on it. (Object.keys expects a non-null input)

(There was causing an error in the console, but not a crash)

the textStyle of the datatable cell was not getting applied to the underlying Text element. With style applied on the Text component directly, the label is 12pt and bold

It is actually expected for appConfig to be initially null here, and we don't need to show an error message for it.
EnketoModal is not rendered until it is needed; it hasn't called useAppConfig() in advance. So until useAppConfig() resolves, appConfig is null.
Once it does resolve and appConfig is set, this useEffect runs again and initSurvey() gets called.

We avoid hardcoding colors to make dynamic theming easier

The initial state of modesShown should be 'labeled' only if the trip has a label; otherwise it should be 'detected' (since there will be no toggling)
With the initial state being 'detected', if there are multiple modes then the OverallTripDescriptives will show

The declaration of the Appbar.Header is repeated across every screen in the UI.
Let's unify all these declarations into one component called <NavBar>.

We already had a component called <NavBarButton>. It makes sense to put both in the same file since they will always be used together. So the new filename will be NavBar.tsx and it will export both <NavBar> and <NavBarButton>.

We had the NavBar height set at 46px to match the old AngularJS + Ionic UI. It was a bit cramped. The migration is done and we no longer have to worry about that, so what's the optimal height?
Well for accessibility reasons, click zones of the action items in the navbar should ideally be at least 44x44. If the NavBarButtons are going to be 44px tall, the NavBar should be a bit taller than that. 56px looks comfortable.

… now proper error handling.

…mission-phone into bluetooth_scanner

i18n Files were accidentally added in commit b2f4281 .  Rollling back the
repository to the same state as commit 6023c7f,  before the files were
added.

There's a bunch of places in the app where we need to show a SnackBar or "toast"-style message.
But to do this, we've been having to keep each SnackBar's visibility as state so it can show/hide depeding on its "visible" value.

It would be simpler to be able to do this from anywhere in the codebase, though, not just by setting local state.
So I refactored AlertBar to behave as a global stack of alert messages. AlertBar is instantiated once at the top level in App.tsx. A static class called AlertManager can be used to add messages to this stack from anywhere in the codebase.
As a result, components no longer need to have their own instance of AlertBar and they don't have to control the visibility themselves.
They just call AlertManager.addMessage when they want to show a message.

This comma didn't seem to have any adverse effects, but it doesn't belong here

Since AlertBar / AlertManager can now be used from anywhere in the codebase, they are not specific to the Profile screen and can be moved to a more general location