-
Notifications
You must be signed in to change notification settings - Fork 1
Filtering and Matching Rivals
The Home Page's local state tracks users in four levels:
- fullbucket - all of the users, queried from the Firestore's users collection
- nondisplayed - the users we never want to display, set by checking the logged-in user for their ID and querying the Firestore for all the users they've previously challenged or matched with
- allUsers - once the fullbucket and nondisplayed users are set in set, allUsers is set by removing the nondisplayed users from the fullbucket
- users - the users actually displayed on the page, set by applying user-set filters (see Checkboxes below) to the allUsers list; this one updates repeatedly as the app is used
Every user document in Firestore has a rivals array, which holds the IDs of all the users they've matched with, and a pending array, which has the IDs of the users they've sent challenges to but haven't (yet) matched back with them. These two arrays make up the nondisplayed state, which is updated once when the Home Page first loads and every time the user challenges another user (see Matching below), thus updating the rendered view, as the users state is updated through a useEffect function that depends on the nondisplayed state.
Additionally, we have a listener on the User collection so when it updates (i.e. a new user signs up), the Home Page will rerender to include that new user in its display.
React-Native lacks a built-in checkbox input component, so our checkboxes are two icons (one checked and one unchecked) that depend on local state to determine which icon to render. Each interest checkbox is passed a state setter function which flips that interest's status in state from true to false, or vice versa. Every time the art checkbox is clicked, the art state of the Home Page component is toggled, and so on.
When the user exits out of the filtering menu, these interest booleans in state are applied and the users list in state is filtered to only show users whose interests match the selected filters. It's important to note that these filters work as logical ORs rather than ANDs. If I filter for users by cooking and math, I will see users who have either of these interests listed; it's not necessary for them to have both.
When a user challenges another user, there is a possibility that the second user has already challenged the first - which would make them a match - or not.
When a user challenges another, first Firebase runs a query to the rivalries collection in Firestore to see if there's already a document between those users. As Firestore is a non-relational database, our rivalries collection is a manually created junction table; when documents are added, they are created with a unique ID following the format of challengingUserID_otherUserID. So when a user challenges someone, if they've already been challenged by that user, their rivalry document's ID will be the other user's ID first then theirs, and we query by that ID format.
If there isn't a pre-existing document, it means the logged-in user is challenging the other but not creating a match. As previously mentioned, this document's ID has the format of challengingUserID_otherUserID and sets the challengingUser as userOneID with userOneMatch set to true. The other user is set as userTwoID with userTwoMatch set to false. A second query to the Firestore finds the challenging user's document and adds the other user's ID to their pending list, as well as updating the nondisplayed state to include this user, thus updating the view.
If there is a pre-existing document, that means the two users have now matched. The document gets updated so that the userTwoMatch field is now set to true, and an overall active field on the rivalry document it set to true as well. Queries are then made to the logged-in user's document to add the other user to their rivals list, and to the original challenger's document to move the logged-in user from their pending list to their rivals list. As above, the newly matched user is now updated to the nondisplayed state to update the view.