Feat/tracking impl

[bohdanprog]

Here are three tasks in a single PR; unfortunately, they are linked:

• GPS/Location is off #236 GPS/Location is off
• GPS/Location is on #237 GPS/Location is on
• Recording Tracks #238 Recording Tracks

Next time, we plan to approach them partially, hoping for a clearer outcome.

Resolves #236
Resolves #237
Resolves #238

[achou11]

How difficult would it be to revert significant styling changes that are beyond the scope of this feature? for example, reverting the UI changes made to:

1. The GPS pill
2. The big action buttons
3. tab navigation container

main reason i ask is mostly related to stuff we've talked about elsewhere in terms of limiting the focus of the changes you introduce. would also help reduce the size of PRs in some cases :)

[achou11]

What you think about wrapping Home (rendered via HomeTabs component) screen with context we created?

Yeah that makes sense to me 👍

What would be benefits of using useSyncExternalStore vs zustand store?

i don't really have strong thoughts on one vs the other. I'm just more familiar with how to deal with subscriptions (i.e. managing event listeners) with useSyncExternalStore than zustand. if it's straightforward to implement with zustand, i'm all for it!

Also subscribing with different parameters will be the trickiest part. Easiest way would be having a store storing few locations with their own subscriptions and different update periods. There could be 3 pre-configured levels of refresh period (slow, medium, fast). You can just subscribe to whatever update frequency you want via selector

yeah definitely the trickiest part. depending on if i'm reading the suggestion here correctly, it could be interesting!

• one way i'm reading it is that you're suggesting having 3 location subscriptions set up (i.e. addEventListener() 3 times). i'd be worried about due to the potential cost of having multiple active location subscriptions (not sure how the native side is implemented).
• the other way is that you're suggesting 1 location subscription, but having selectors (e.g. zustand selector) that do the hard work of determining the update frequency (e.g. based on distance difference)

[bohdanprog]

How difficult would it be to revert significant styling changes that are beyond the scope of this feature? for example, reverting the UI changes made to:

1. The GPS pill
2. The big action buttons
3. tab navigation container

main reason i ask is mostly related to stuff we've talked about elsewhere in terms of limiting the focus of the changes you introduce. would also help reduce the size of PRs in some cases :)

1. We updated the GPS pill styles (it should match those in the main branch).
2. I haven't made any changes to the large action button. (If I understand correctly, you are referring to a big button on the map screen, correct?)
3. Are you referring to the size and tab labels? (We made changes to them, and they now look identical to those in Figma.)

[achou11]

1. We updated the GPS pill styles (it should match those in the main branch).

2. I haven't made any changes to the large action button. (If I understand correctly, you are referring to a big button on the map screen, correct?)

3. Are you referring to the size and tab labels? (We made changes to them, and they now look identical to those in Figma.)

Yeah apologies for the confusion. I originally asked the questions because of uncertainties we had internally around the more global design changes we wanted to introduce. Will clarify in our chat on Slack with what we've agreed upon internally, but the short sumary is that you can ignore my question about reverting UI changes and instead keep what you have implemented :)!

[achou11]

Adding a note about implementing a feature flag setup so that the tracks feature(s) can be hidden behind a flag so as to not be exposed by default. In this PR, the flag should determine whether the tracks tab is rendered

[bohdanprog]

@achou11

yeah very strange - would think doing what's described here (but for the beforeRemove event) would be feasible: https://reactnavigation.org/docs/navigation-events/#screenlisteners-prop-on-the-navigator (haven't tried it myself - I'm just reading through docs and hoping they're accurate 😄 )

about that, I found that beforeRemove call is only when we navigate between stacks.
and in screenListeners option state doesn't have value about the target screen, unfortunately :(
That's why I guess using :

screenListeners={{
        tabPress: handleTabPress,
}}

[achou11]

Changes around the feature flag look good!

Think I mentioned this regression before, but think it should be fixed before merging. Reproduction steps:

1. Navigate to camera tab
2. Press big button
3. Press button in top-left to discard observation (i.e. leave observation creation flow)

After (3), you end up in the map tab, but you should end up in the camera tab.

[CDFN]

According to my response here:
#257 (comment)
behaviour you described is not regression. This is how it worked before. For babel plugins order, I pushed a commit fixing it.

[achou11]

According to my response here: #257 (comment) behaviour you described is not regression. This is how it worked before. For babel plugins order, I pushed a commit fixing it.

Ah sorry, missed that! This is a regression compared to the old app, but as you said, this is not something that was introduced with your changes. Thanks for pointing that out! will create a separate issue that someone else can tackle separately :)

[achou11]

great initial work! hoping the next pieces will involve less back-and-forth 😄