-
Notifications
You must be signed in to change notification settings - Fork 0
Team Meeting Notes SUN 29 March
mliu433 edited this page May 13, 2020
·
1 revision
- Sukhans to provide quick recap on backend stuff
- GraphQL Discussion/Quick Q&A session
- Authentication Discussion + Document Authentication flow for sake of reference
- Documentation of flow of a new user entering the website
- Documentation of flow of an existing user entering the website (if it differs)
- Discussion of potential Implementation Issues
- Discussion on potential marketing avenues/launch channels
User logins in with a university that doesn’t have a community yet
- On sidebar: Sorry! We’re not at your university yet - but feel free to view confessions!
-
Authentication: Jordan & Sukhans
- SignupFlow probably contained inside a parent component (SignupFlowContainer)
- Parent component would contain an ordered array of signup flow dialogs that can be shown, with user data fields associated with each dialog.
- This way the signupflow can be triggered if any of the data fields are missing from the user data & then the appropriate signup flow dialogs can be shown by the container
- This signup user data validation check probably happens whenever the user opens the website again/we refetch the user data (useQuery supports a post-fetch callback)
-
Create Post Mutation*: Sukhans
-
Clientside GraphQL Setup: Harrison
-
PoC: The last selected community is persisted even across browser sessions
-
Landing Page: Maggie & Sukhans
- Navigating to confess.app (homepage url) should trigger a check for clientside graphQL field and navigate them to landing page if all the following are satisfied:
(if user who has not logged in successfully before click any categories at this point, it would route to landing page)
- The URL is not already associated with a community.. (Confess.app/uoa/.../...)
- they have not selected a community in the past (harry’s clientside graphql) the user is not logged in (and hence they do not have a default community)
- Otherwise navigate to appropriate community (based on order of the constraints listed above)
- Navigating to confess.app (homepage url) should trigger a check for clientside graphQL field and navigate them to landing page if all the following are satisfied:
(if user who has not logged in successfully before click any categories at this point, it would route to landing page)
-
Remaining GraphQL Queries (Resolvers + Frontend): Jordan
-
Just ping sukhans for questions with firestore (subcollections vs arrays)
-
Remaining GraphQL Mutations (minus submit post): Harry
-
Just ping sukhans for questions with firestore
-
Integrate Authentication into GraphQL/Frontend routes: Sukhans
-
Channels
-
Default uni for dropdown list on the sidebar (it looks like the visitor has to select a uni before login/signup)
-
Should we display names or UPIs on comments?
- Sukhans Asrani (sasr366)
- Replies might @Sukhans Asrani, @sasr366 @mentions resolve to UPI maybe?
-
Flow of a New User Authentication
- Landing Page prompting them to a select a university they want to view
- This selection should be persisted somehow to apollo graphql client state
- Login with university email (similar input box + login button)
- AI: sukhans to send pitch wireframe
- Maybe some explanations on the landing page of what Confess is
- Liking a post while not logged in should make a modal popup prompting them to sign in?
- Any action (newpost etc) should slam them into modal (except for share)
- They can view confessions of any community
- Landing Page prompting them to a select a university they want to view
- Passwordless Authentication (this is how medium authenticates)
- https://medium.com/m/callback/email?token=asdasd&operation=register
- Email Verification happens - when they click the link → it opens the signup flow on the link they click
- Signup Flow: Request their name (firstname + lastname)
- NEEDS TO BE DYNAMIC
- Date of Birth? (Niesh)
- Every time you login, compare what user data we have and what we need
- Fixes the problem where a day 1 user doesn't have all of the required information 1 year in
- 1 page for data point / input (UX best practice)
- Dynamically render pages as needed
- Each page has certain fields associated with it that are required from the user.
- We default their selected community to their university
- Sidebar should now show their name + University, maybe university logo.
- And a logout button (bottom left of sidebar)
- State should be persisted in Apollo Clientside @client annotations
- User @client { }
Get communities & categories for the community
- Loaded before React App even visible (Show loading screen/skeletons)
- For sidebar
- Should also provide an image for each community (for dropdown menu to be clean)
- Show retrieve approved categories for the community
** Client-side GraphQL Setup (fuck redux)**
- For persisting the community the user has selected/should default to the community that they are a member of
- Getting the user that’s logged in and defaulting the page to their community
** Get Feed for a Community (done)
- Maybe returns total confessions for the community
- Created in GraphQL Boilerplate PR (Needs to be renamed) and logic added for ordering
- Should just return posts that have been approved in their feed alongside summary details e.g:
- Content (we truncate on clientside)
- Title
- Author
- ConfessionID
- TotalLikes
- TotalComments
Get Detailed Post Info
- Get all post info again
- Get comments and people who have liked the comments
Get People that have liked a post (might not be needed, included in detailed post info query)
Get User Info
Get Posts To Be Approved
- For Admin Page
- Submit a post for approval
- Check the page for the data that u need (Sukhans to create this mutation)
- Like a Post
- Comment on a Post
- Replies via frontend
- Like a comment
- Approve a Post
- Confession Ids from the start
- Confession Id assigned when the post is approved (atomic counter used)
- Reject a Post
- Provide a rejection reason