* Update package.json
Without the babel plugin the app does not start because of an error with the new package.
* Update babel.config.js
* Update package-lock.json
* Switch to new package for Wikipedia text
* Update Podfile.lock
* Use new package in UserText
* Link underline was blue, now green again
* Make headings in user text the same as in the app
* Fix typo?
Not hundred percent sure about this, but MDN docs show no t tag and the original list in inaturalist has tfoot in this place here.
* Remove tag that is not supported on web
* Refactor making of html into helper function
* Update index.ts
* Create a snapshot test for build html function
* update react-native from 82.1 to 83.4 (includes react@19.2)
* Update Podfile.lock
* Create react-native+0.83.4.patch
There seems to be a known issue in React 19.2 that makes us hit errors during development with this code in regards to using realm.
https://github.com/realm/realm-js/issues/7086https://github.com/facebook/react/issues/35126
* restore flow
* add two new RN file exceptions to flow
* pin react/types to ^19.2.0B
---------
Co-authored-by: Johannes Klein <johannes.t.klein@gmail.com>
* Add navigation type
* Add navigation types
* Type Camera rout props
* Route param types from usePrepareStoreAndNavigate
* Add route param from useBackPress
* Refactor useBackPress to use useRoute
* Add params from AddObsButton
* Add route params from ObsEdit
* Replace navigation types from central
* Add param from PhotoLibrary
* Add route param from PhotoLibrary
* Collect param types from different routes into PhotoLibrary
* Combine Suggestions route param types
* Combine Match route params types
* Combine ObsEdit route param types
* This a bug?
* Undo WIP changes
* Type hook navigation
* Add route param type
* Add possible route param type
* Type navigation in hook
* Add another route param type
* Use types from central
* Add possible other type
* Typo in function import
* More possible navigation types
* Type route the same
* Add more route types to Camera
* Type from central
* Add TaxonDetails route param type
* Add Match to possible routes
* Move MatchContainer to TaxonDetails params to central definition
* Actually move it
* Remove unused prop
* Type navigation in TaxonResult
* Use more stringent type
* Add route param types to TaxonResults from TaxonResult
* Use central type
* Type navigation in Taxonomy
* Add route param from Taxonomy
* Type navigation in PhotoSharing
* Type route in PhotoSharing
* Add screen type
* Add possible screen name
* Add screen name to route param types
* Type route params as in App.js
TODO: this is not correct on the other side of the contract in PhotoSharing
* Add route param from GroupPhotos
* Update types.ts
* Update PhotoLibrary.tsx
* Update useExitObservationFlow.ts
* Add type definition
* Remove navigateToObsDetails from useExitObservationFlow
Why?
1.) To remove some level of complexity in our navigation flows.
2.) Migrating all to TypeScript reveals that, this is an edge case for a user being on an ObsDetails screen and then starting a new obs from the AddObsButton. This has nothing to do with a user being on ObsDetails and starting to edit this observation. In other words, when a user starts a new obs and saves it, we navigate them back to the ObDetails they were on when starting to create a new obs.
3.) This is actually kind of buggy: If a user is in the Notifications tab looking at an ObsDetails of someone else's observation, then starting a new observations and finishing it, we are resetting the navigation to be in the Me tab looking at the same ObsDetails of someone else, which doesn't make a lot of sense.
* Update useExitObservationFlow.ts
* Replace a navigate event with a reset
This is a fix for a performance issue we have seen where saving multiple observations and editing them leads to a slow app.
What is the problem? As the migration to TS made more clear, this hook is imported in screens in both the NoBottomTabStack and the TabStack.
Before: if you hit this action in a screen in the NoBottomTabStack it works fine, the app navigates to the TabNavigator here and loads ObsList as the first screen. However, if you call it while already being in the TabNavigator it just pushes another ObsList unto the stack and not removing any previous screens (even though they are UI wise essentially unreachable).
After: Every time we hit this action we just reset the entire navigation to only show the Me tab with ObsList loaded. This frees up all accumulated screens in either the NoBottomTabStack or the TabStack (depending on from which one it is called in).
* Remove TODO