- used in
ConnectUrlViewer
, this component is now deprecated in RN and needs to be used from here.
- is now deprecated and must be used from here.
- used in three places:
Connect
(main bookmarks view): checkingisConnected
before allowing pull down to refresh (is this even needed?)Main
: observingconnectionChange
to start/stop messagebus subscription.Chat
: observingconnectionChange
to start/stop messagebus subscription.
- is now deprecated and must be used from here.
- used in two places:
Main
: to clear notifications when app is launched.sagas/notifications
: everything else notification related (launching app, pre-fetching, etc).
- This was a terrible architecture choice made at the very beginning that makes for very annoying dirty code
- The store looks like the following:
{ ... chat: { ... data: { ConnectRoom_43243: {}, ConnectRoom_837283: {}, User_2: {}, User_34484: {} } }
- Instead, the ideal would be:
... chat: { ... data: { ConnectRoom: { 837283: {}, 43243: {} }, User: { 2: {}, 34484: {} } } }
- Because of the way it is right now, we're left doing this all the time:
chat.data[`${roomInfo.type}_${roomInfo.id}`]
- It was made this way because IDs can repeat between Users and Rooms, which would clash in the same object.
- This is a helper that was added by ex contributors because of the issue on 4, but it's just a way of masking the logic to prevent undefined-access errors, which nowadays are preventable using the optional operator from ES7.
- Currently used in 3 files:
Chat
RoomRoster
sagas/chat
- We're at 0.59.10
- the newer version uses the native navigation libraries which provide for a more native like experience for the user
- the new version will allow us to use redux hooks, which make the code much cleaner in function components, and keeps us current.
12. Use react-native-firebase
:
- Right now we're using a deprecated library called
react-native-fcm
.
- The app uses SQLite probably as a way to allow native-land to access its data, but we ended up never going this route (see bookmarks export to share extension for example).
- This creates issues because a DB like that is not very compatible with react's way of fetching data (ideally everything should live in redux).
- Right now the SQLite DB only stores users and rooms, and this could be moved to redux too.
- A small step towards this was made on https://github.com/powerhome/connect-rn/pull/515 and https://github.com/powerhome/connect-rn/pull/526
- We're now only using data from SQLite to populate the corporate directory and the add room members old view.
- The app receives new state data via messagebus and also fetches every 90s via HTTP GET.
- The data received is what's changed since the last time fetched (providing a timestamp in the GET request).
- The data is the following:
users
: every user in connect.user_ids_connected_with
: we currently don't use this in the RN client, but it's the list of user IDs that I've ever contacted before.rooms
: every room in connect.presence
: the online/idle/offline indicators on every user avatar.bookmarks
: probably the easiest one to be migrated because there is already a HTTP GET endpoint for this.unread
: the source of all issues related to badge counts on bookmarks, because this is pushed to the clients asynchronously and the data takes half a minute to be calculated, when it arrives it's already old, and the badges keep being set wrong.events
: everything related to corporate events that should be displayed to the user.
- Right now, we are kind of evolving into having a separate state request using GraphQL to fetch the following:
territories
featureToggles
permissions
- Something that is not in either two requests, and should also be moved to GraphQL for consistency:
- notification preview preference: right now done in a HTTP GET request.
- The way I see to migrate to GraphQL is start adding GraphQL endpoints for these things we currently receive via state, then start fetching them with GraphQL every 90s like we do now, and one day when everything is fetched via GraphQL we can think of a way to use subscriptions to observe the data instead of relying on message-bus.
- Basically this SDK is in charge of showing that update popup and screen when we load the app.
- We all know this medium has its drawbacks and has made people be stuck on old versions of the app before.
- HockeyApp died back in October and we keep using it, I'm impressed AppCenter is still backwards compatible.
- The thing is the library is maintained by a random guy that stated he doesn't care about it anymore and it doesn't support autolinking (which is enabled by default on RN0.60+).