Backend

• Setup npm server with typescript for backend
• Setup linting
• Add README

Frontend

• Setup Xcode project

Discuss with Aman and design the schema we will be using for our mongoDB

Database schema is basically laying out what types of data you will store in mongoDB, how your data will be structured etc. In our codebase, the schema can be translated to the models.

To design this schema, you should have a basic understanding of how data is stored inside mongoDB (what are documents?). You should also have a solid understanding of the figma, more importantly the data that's being represented in figma.

Once the schema is complete, we will be able to create a plan for our API routes (the GETs, POSTs and other such routes)

Resources

mongoDB has a lot of articles about schema design

• https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design
• https://www.mongodb.com/developer/products/mongodb/mongodb-schema-design-best-practices/

We need a label over our input component.

Look at the label "Email" in the screenshot -

Example Uses

Resources

N/A

Depends on

#11

PR #11 creates an Input Text Component. When a user enters some text, we want to be able to validate it and render out relevant messages.

Look at the image below -

Note the different types of error messages (look at the colors green and red) and also how some have an icon at the beginning and some don't.

Example uses

• Note that the functionality you add to make this happen should be easily reusable at different location. You can come up with the best way to organize code.
• I recommend looking at this term called regular expressions for validation.
• See if you can somehow have the parent component of the input field (one that uses it) define the entire error message and its styling (while building components always try to limit the work done by the component as much as possible)

Resources

• In addition to google, ask ChatGPT - "swiftui how to add input validation" and see it do the magic! Best way to use ChatGPT is to always take its answers with a grain of salt so beware. But feel free to ask it any question you have and it has never disappointed me yet

Now that we already made some components its time to assemble them to create the login page.

Refer to figma but here is a preview

TODOs
Just a guideline on how you could break this task down. Feel free to approach this task in whichever way you see fit.

• Setting up firebase iOS SDK (check with backend devs for getting access to our firebase proj
• Arranging the login page components (Create a LoginPage View)
• Connecting the login page with the iOS SDK

Notes

• Remember the MVVM architecture while implementing the Views
• You might need the app bundle which can be accessed from our XCode
• You would need a label as well for the inputs (#15)

Resources

• ChatGPT can be very helpful if you are trying to understand the MVVM architecture
• Example repo for reference - https://github.com/iosapptemplates/swiftui-starter-kit/tree/master/FirebaseStarterSwiftUIApp

Requirements for feature

• Reuse the model created for Mentor/Mentee Profiles
• Create the views/components needed for the Edit Profile Page (ignore the image edit at this point)
• Hook the save button with a network call to our backend (if backend is not up, just have the interface for the service ready but fill it with dummy data - maybe just print to verify save is called)
• Implement the image edit with the picture picker

Any context for feature

• Profile Display Screen will change to Profile Edit Screen when the pencil is tapped in the top right. That pencil should only be visible when the user is allowed to edit the field (a user can only edit their own profile).
• Try to make the transition from Profile Display to Profile Edit screen as smooth as possible.

Resources / tips for development
Apple Image Picker - https://developer.apple.com/documentation/photokit/bringing_photos_picker_to_your_swiftui_app
Note that some of the components like drawer container etc. should already be created.

Requirements for feature

• Add code to setup connection between our frontend app and our backend for all our requests/responses
• Confirmation Screen should be created (use mock data for testing if needed)
• Sync with assignee of #34 to settle on a model for the Sign up Flow and use that model if you can
• Send all the data shown on confirmation screen to POST /mentor or /mentee created through #40 (if PR is not merged, you can branch off of the sign-up branch for testing)
• Setup a service that deals with the network calls for mentor or mentee (design for these services is up to you)

Any context for feature
We have our POST mentor or mentee routes on backend so let's connect our frontend to it. Note that this is the first task that sets up a connection between our backend and frontend how you structure it will drive what comes on in future so keep that scalability in mind.

Resources / tips for development
I would have to look up resources so you should take a shot at it first! Please let me know if you need resources and I can find some.

Requirements for feature

• Route should take answers for pre/post session notes
• Body Argument "type" specifies whether a PATCH is for pre/post session notes
• Session Notes should be updated with request arguments

Any context for feature
As discussed for sessions API, we need a route that will update the pre/post session notes. This PATCH route is called when the user hits "Save" in the screenshot so you can figure out the inputs accordingly -

Resources / tips for development
To figure out the inputs, look at what are the things user is filling in the entire presession flow (check figma).

Requirements for feature

• Research on how to store user token when authenticated (by Login)
• Implement the getToken and storeToken functionalities so that any screen can easily use it
• Test storeToken by integrating it with the Login View and getToken by just displaying the token in some view and manually validating this token belongs to the expected user (feel free to test this in some other way if easier)

Any context for feature
N/A

Resources / tips for development

• Checkout this ChatGPT conversation - https://sharegpt.com/c/hX3ICSu
  • You should also research into these methods and pick the best one. I'm leaning towards Keychain with iOS Key-Value Store as fallback
• Referenced screenshot of POST request for LOGIN
  - URL for the POST (ONLY for Postman testing) - https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=[API_KEY]
  - API_KEY can be found in GoogleService-Info file
  - Takeaway: Login Response returns the ID_Token that needs to be stored
  

Once you have finalized the DB schema (#17) we need to decide what API endpoints are we going to implement to provide access to those resources from our DB

Create a design for all API endpoints to be used. Make sure to utilize REST design standards.

For each endpoint, we need

• Route URL (eg. /users/)
• Request Type (GET / POST etc.) -- eg. (GET /users/, POST /users)
• Who will interact - (mentor, mentee, or both)
• What kind of authentication do we need here?
• What arguments / parameters should the request have
• What is the response

Resources

• Learn more about REST - https://www.freecodecamp.org/news/rest-api-tutorial-rest-client-rest-service-and-api-calls-explained-with-code-examples/
• Example from LAKTAA - https://docs.google.com/spreadsheets/d/1h2y0m6q81K6nrAfRYWMsMq0XUOJNiPEx2Sr4_kw0uUY/edit#gid=0

Depends on #17

Requirements for feature

• Utilize the PATCH notes route to save pre-session notes
• Utilize the GET notes route to load notes from backend (PR #72)

Any context for feature
Feel free to open PRs for the save functionality when done (regardless of GET functionality)

Resources / tips for development
N/A

Requirements for feature

• Create Sign Up Screen Steps 1 and 2
• Ensure input validations are taken care of using our infra already created
• Implement navigation between both screens
• Setup a model for the sign up flow (MVVM) and sync with assignee of #35 so that all screens of the flow is consistent

Any context for feature

The main highlight of this task is that it adds navigation / routing to our app. The way we route pages here will be used to route all our views so implement this with care. Make sure to sync up early so that all screens of this flow are consistent.

Resources / tips for development
I would have to look up resources so you should take a shot at it first! Please let me know if you need resources and I can find some.

Requirements for feature

• Research into the 2 ways of implementing reset password flow in terms of firebase-ios-sdk
• Implement the views (after research) - N/A
• Send reset password link to user email and the reset password through that link (this will be sent when user hits "Send Verification Email")
• When forgot password is clicked, user gets navigated to a screen which takes in an email and has a "Send Reset Password Link"
• Once email is sent, navigate the user to "Success" screen

Any context for feature
Reset password flow deals with when user forgets their password and needs to change it. This task needs some research on how reset password works with firebase. We have two ways to go about this -

Decided to go with the sending reset password email because of ease in development

1. Send reset password link to user email and the reset password through that link (this will be sent when user hits "Send Verification Email")

• CON Issue with this is we don't have control over the password strength of the new password they make because the link firebase sends only checks whether password length is more than 6 characters or not.
• PRO very easy to implement

2. Send reset password code to user email and they enter the code in our app (current figma design)

• CON harder to implement
• PRO We have full-control on the password strength

Resources / tips for development

• Use firebase-ios-sdk which was already setup by #32
  Written Tutorial - https://medium.com/swift2go/firebase-authentication-using-ios-sdk-28a6a6cb9815

Requirements for feature

• When GET is sent on URL/notes/, respond with the questions and their types
• Might be useful to return the question ID as well

Any context for feature
This route will be called before setting up the pre/post session forms

Resources / tips for development

• Might be useful to return the ID of the question in this request. That way when the frontend sends the PATCH notes request, it can just send the ID instead of the question text.
• This will be especially handy when we move our questions to mongoDB

We need a progress bar component that can be reused in the various views we have. This component should have some form of state that dictates how much progress has been made

Look at the screenshot -

Example Uses

Resources

ChatGPT will be helpful. Feel free to reach out to me if you need more resources

Requirements for feature

• Creates the Sessions collection and the Notes Collection
• Populates empty answers for all questions in pre/post session notes because answers are only populated after event is created.
• Just for testing purposes, you can add "mentorID" and "menteeID" fields in the POST route (in future we will detect that from the user token)

Any context for feature
Now that we won't use Calendly to create our sessions, our create sessions route will be called from our frontend when the user uses the "Book Session via Calendly" button.

Resources / tips for development
https://docs.google.com/spreadsheets/d/1h1LmmF9NtEkucmPMpy8WkK-ubjwUXb_qWc0b0USPN04/edit#gid=0

Requirements for feature

• Add zoom link and calendly link inputs to mentor's signup screen (3rd page)

Any context for feature
N/A

Resources / tips for development
N/A

Requirements for feature

• EDIT mentor and mentee routes (PATCH) must be implemented such that the object ID is provided through the URL
• All attributes for the profiles might be present on the request so this route should apply all those changes to the DB
• If a valid authentication token is not included in the request, return invalid.
• Route should be limited only to the user that is being edited. This means a user can update only their own profile.
• Setup image uploading
• Ensure error handling is taken care of
• Sync with who is doing GET mentor/mentee endpoints to iron out how you plan to store images

Any context for feature
This route allows users to change their profiles. Changes in profile could include any changeable fields shown on figma for edit profile screen including the profile picture. Since a lot of logic will be similar for both mentor and mentee, leverage services to reuse code. Also, remember that the way our frontend is designed it will be hard for the frontend to know which fields are changed so it might be best if frontend just sends all updated data for the profile (which means data which is not edited might also be sent)

Resources / tips for development

• Use middlewares for setting up token verification - https://github.com/TritonSE/TAP-Foster-Dog-Matching/blob/main/middleware/auth.js
• Image upload has been implemented using multer for LAKTAA so you can check that. But make sure to do your own research on the package.
  Checkout POST new job - https://github.com/TritonSE/LAK-Goods-Transport-Application/blob/main/backend/routes/job.js
  PR to set it up - TritonSE/LAK-Goods-Transport-Application#24

Requirements

• When search text is added, suggestions list should only show matching tags

Now that we have basic structure ready for the tag selection component, we can work on adding the search feature to it. Remember the ViewModel logic while designing this view (more info on Development Notes as MVVM architechture)

What do we need?

Component to input user passwords. Need a toggle which specifies whether the password is shown/hidden

Ignore input validation for this task (i.e., ignore the red and green comments under inputs and the red highlighting of textbox)

Example uses

Resources

You are encouraged to look for more resources if needed, but here some I have -

Example of show/hide secure field shown towards the end - https://medium.com/devtechie/securefield-in-swiftui-f4ba2c68f32
SecureField - https://developer.apple.com/documentation/swiftui/securefield

Requirements for feature

• Add fields from figma to mentor/mentee sign up routes - PR comment
• Add email validation for mentor - PR comment

Any context for feature
This PR is just to finish up the mentor/mentee sign-up route

Resources / tips for development
Checkout past PR - #40

Task Description

Please read the firebase overview in Development Notes
https://docs.google.com/document/d/1aF1qgPodrwS3TVitwZvYrJPQ0eqLOVmJQlKDNZlg0V0/edit#bookmark=id.mhk1zyd2w15e

We will use Firebase Auth for our user authentication because it will make our lives easier to setup the reset password flows. Given our user base, the free tier for Firebase Auth will serve all our needs.

Firstly, here are the requirements for this task. Some requirements described below might not make sense until you read the entire Firebase Overview

• Firebase Auth should be setup for our application (please lmk if you have any questions in the process or are not sure about something)
• #27
  Anything else that is described below can be done as a separate PR (whatever you see fit)

Requirements during signup are the following. You can ignore the implementation of this for this task if that makes lives easier but make sure you are designing the route in such a way that this can be added later.

1. Email must not match **@iusd.org
2. Password requirements to be given later (for now no requirements)

Let me know if you need any other resources. Make sure to read the firebase overview section

Resources

• Past TSE project that uses Firebase Auth for reference

  • https://github.com/TritonSE/TAP-Foster-Dog-Matching/blob/main/services/auth.js
  • Understanding how firebase is integrated here will be extremely helpful
  • Pay special attention to the organization of logic (look into use of services)

• Firebase Official Setup - https://firebase.google.com/docs/admin/setup

This issue is to make sure all of us are able to setup frontend and backend on their machines

Instructions for setup (frontend + backend) are provided in the README.md - https://github.com/TritonSE/ALUM-Mobile-Application/blob/main/README.md

Please let me know if you are facing any issues

Everyone needs to setup the following things

TODO - Copy the following two todos and make a comment with them marked as completed. (for example, see below)

• You are able to view the hello world screen preview using Xcode (image 1)
• You are able to run npm run dev and start the server (image 2)

Image 1

Image 2

Requirements for feature

• Defined such that it is easy to cover a route with the auth layer (all routes except signup will be covered)
• This auth layer will perform ALL authentication checks using the user token

Any context for feature
This is critical in moving our backend towards release because all routes needs to be authenticated (except signup).

Resources / tips for development

• Look into how to effectively use middleware functions to setup this auth layer
• Benefit of having a middleware function with the auth logic is, we can add that middleware to the route definition whenever we need so very easy to authenticate a route.

Note: Once you are assigned to this task, please send me your email ids so that I can add you to the mongoDB cluster we have created.

What do we need?

• First step to setting up our backend is to integrate the server with our database in MongoDB.
• Once done, we should be smoothly able to store / retrieve documents to and from our database
• Use package mongoose for communications between server and mongoDB (link in resources)
• Use .env to store DB configuration (like MONGO_URI) BUT DO NOT PUSH IT TO GITHUB. .env file should be shared with the team over slack and is to be maintained locally.

How to show its done?

Note that this is just a guideline for creating a proof of concept to show that our DB connection is setup so feel free to play around with it. Take a look at PR from resources for an example

• Create a placeholder model (eg. User) with the following schema
  • User { name: String, email: String }
• Setup a POST route (eg. POST /user) with inputs some arguments for the model you created and stores that model in the DB
• Setup a GET route (eg. GET /user/) which takes ID as input and returns the particular resource with matching ID from DB

Once routes are setup, use POSTMAN to test it and upload a screen recording of the same

Resources

Intro to MongoDB - https://www.mongodb.com/basics
Mongoose with Typescript - https://mongoosejs.com/docs/typescript.html
Tutorial - https://medium.com/swlh/typescript-with-mongoose-and-node-express-24073d51d2ee
PR from LAKTAA - TritonSE/LAK-Goods-Transport-Application#22

Requirements for feature

• Specify the QuestionModel and QuestionsViewModel (check resources)

Any context for feature
This QuestionModel and QuestionsViewModel should be designed carefully because it will be used by all the screens

Resources / tips for development
Brainstorming done w Jenny & Aman - https://sharegpt.com/c/I0UVlTd
Model - Question { id, question, answer, type }
ViewModel (guideline so feel free to change anything here)

class QuestionsViewModel: ObservableObject {
    @Published var questions: [Question] = []
    @Published var currentQuestionIndex: Int = 0
    @Published var lastQuestion = true
    func nextQuestion() {
        currentQuestionIndex += 1
    }
}

What do we need?

Generic text input component that accepts single line of input.

Ignore input validation for this task (i.e., ignore the red and green comments under inputs and the red highlighting of textbox)

Example uses

Ignore the red marks (input validation) for the scope of this task

Resources

You are encouraged to look for more resources if needed, but here some I have -

https://medium.com/@ricardomongza/create-custom-textfield-styles-in-swiftui-b484b7ba31bf
TextFieldStyle - https://developer.apple.com/documentation/swiftui/textfieldstyle
TextField - https://developer.apple.com/documentation/swiftui/textfield

Requirements for feature

• QuestionView renders a screen with question and place to enter answer
• This should have the ProgressBarComponent
• Navigates to QuestionsSummaryView (not ready yet so can be left empty if needed)
• Should display BulletEditor Component or paragraph input based on the type specified by the current question

Any context for feature

Resources / tips for development

• This view uses the QuestionsViewModel and renders the question based on currentQuestionIndex or something similar
• Calls the nextQuestion method in the viewModal which increments the currentQuestionIndex or marks the last page

https://sharegpt.com/c/I0UVlTd

Requirements for feature

• Safari instance should have open the calendly booking link
• When "Book Session Via Calendly" is booked a Safari browser should open up inside the app
• The Button should open up the route which is hosted on our backend that returns an HTML file which relays message from window.postMessage (calendly) to webkit.messageHandlers.myHandler.postMessage that is received by our SwiftUI
• You will get the calendly URI that you should pass into POST session route (will have to change the session route)
• Your POST session route handler will take the URI, get the event time from there and update our database

Any context for feature
We are using calendly to help mentee find time in the mentor's schedule so user will be redirected to an external link for calendly. We should open the link inside of our app so that we are still able to intercept the messages that website sends (check resources). Once we have the message which will have event date and time our frontend will make a backend request to create a session.

New Resources / tips for development

• Repo with experimentation code - https://github.com/AmanKAggarwal/Calendly-Experiment

  • Checkout server.py on how the GET route is done + CalendlyController for the swift logic

• Messages that calendly sends - https://developer.calendly.com/api-docs/ZG9jOjI3ODM2MTAz-notifying-the-parent-window

• GET event time through calendly - https://developer.calendly.com/api-docs/e2f95ebd44914-get-event

• Use personal access token for the calendly auth

  • https://developer.calendly.com/how-to-authenticate-with-personal-access-tokens#:~:text=If%20you%20have%20no%20prior,Create%20Token%2C%20then%20Copy%20token.
  • This token should be collected in the signup route

Initial Resources / tips for development

• You can create a calendly account and use your booking page as you play around (https://calendly.com/)
• This task requires researching and playing with how the functionality to get data out from calendly website into the app works so you have to playaround a bit.
  
  WKWebView - https://developer.apple.com/documentation/webkit/wkwebview
  Notifying the parent window - https://developer.calendly.com/api-docs/ZG9jOjI3ODM2MTAz-notifying-the-parent-window

Add lint check either using SwiftLint to Github CI
Add a sanity test to build Xcode app to prevent issues like #20 in the future

Requirements for feature

• GET mentor and mentee routes must be implemented such that the object ID is provided through the URL
• If a valid authentication token is not included in the request, return invalid.
• Route should be limited only to logged in users (could be either mentee or mentor)
• Ensure error handling is taken care of
• Sync with whoever is working on the EDIT user endpoint to support including profile picture in the GET response.
• Image Retrieval should be working

Any context for feature
We need a route that our ProfileView pages can use to view self profile or profile of their mentor/mentee. This route will be used for that purpose. Checkout figma to see the ProfileView screen to get an idea of what fields to include in the response.

Resources / tips for development

• Look into the requireAuthenticatedUser middleware - https://github.com/TritonSE/TAP-Foster-Dog-Matching/blob/main/middleware/auth.js
• LAKTAA backend will be a good reference for using services
• In LAKTAA, we just store the image ID in our documents and then return that to frontend when the JOB is fetched. If the frontend needs to display that image we just let them use our GET /images/ route. This worked out well because its easier for frontend if you can simply get an image using a GET request. Components are generally made that way. (TritonSE/LAK-Goods-Transport-Application#24)

Requirements for feature

• Add a pairing collection to our MongoDB. Each document in this collection should be like -

{
   _id: ObjectId,
    menteeId: ObjectId,
    mentorId: ObjectId,
    why-paired: String,
}

• Mentee document should be updated to link to the currently active pairing

active-pairing: ObjectId

• Mentor document should be updated to link to all its currently active pairings (since its 1-mentor-N-mentees)

active-pairings: [ObjectId]

• Make sure the GET request still remains the same so that. Frontend shouldn't have to query from pairings collection.
• We can have four situations
  1. Mentee GETS Mentor -> why-paired is returned
  2. Mentor GETS Mentee -> why-paired-is-returned
  3. Mentee GETS Mentee (self) -> why-paired is omitted
  4. Mentor GETS Mentor (self) -> why-paired is omitted

Any context for feature

• Currently, our backend maintains pairing in the mentee and mentor documents. This needs to be moved to a pairing collection so that it is more scalable for our future requirements like report and others

Resources / tips for development

Requirements for feature
Generic custom alert component

• Must be created that can be used throughout the app (ensure this is generic i.e. what is displayed can be passed in by the component that calls this)
• Buttons should trigger actions that are passed into the component
• Custom Alert should just appear over the existing screen (blur the background)

Prompt Screen

• Clicking the Great Button should call an action passed in to the component
• Text displayed should not be hardcoded but passed into the component.
  Any context for feature
  N/A

Resources / tips for development
Checkout how custom alert can be generalized here - https://medium.com/geekculture/dynamic-custom-alert-in-swiftui-4154a0d4204d

Requirements for feature

• Resolve - #40 (comment)
• throw errors for setup failures - #40 (comment)

Any context for feature
N/A

Resources / tips for development
N/A

Requirements for feature

• Implement an API service to handle GET mentor/mentee (fill this to return dummy data until backend is up)
• Setup a model for mentor/mentee that can be used for Profile View and Edit
• Create Profile Display Scene and reuse logic using components etc whenever you see fit

Note - Don't link the "Book Session Via Calendly" button right now. This will be a separate task

Any context for feature

• Profile View Display is the screen users can view their own profile or a different user's profile. The View will change depending on who is viewing who's profile. For example, when a mentee is viewing a mentor's profile they will see a"Book Session Via Calendly" button that they can use to schedule via calendly. In addition, they will not see who the other mentee's are for that mentor. On the other hand, when the mentor is viewing that same profile (self), they should see a view my calendly button + see all their mentees.

If you are confused on some field, please ping on slack and we can address it with our PM and designers.

Resources / tips for development

• You should setup a model that can be used in our ViewModel and Model for the Profile Screens. You should be able to reuse the same model for the Edit Profile screen

Requirements for feature

• Create route to update pre and post session questions. This will be used when the form is being submitted.
• Ensure that the way we structure our sessions document doesn't break when we change a question (discussed during DB schema design)
• Implement a GET pre and post session notes end point as well. This will be used when the form is opened to fill in the existing values on frontend. (This GET route should supply the questions as well as the answers)

Any context for feature
This task tracks the creation of routes that can deal with pre and post session notes. As discussed, we should store these notes in the sessions collection. For purposes of this task, don't include the calendly data inside the Session collection.

Resources / tips for development
Use discussion from the DB schema design meeting to create the question/answers in a scalable way - https://docs.google.com/document/d/16vCBgjZL0qNcE_xX_K5JtysVjkkLpGhqh-vFezesbL8/edit#

Requirements for feature

• Displays the question and answers from the model
• Create a notes service to send PATCH request (same notes service can be used for GET note)

Any context for feature

Resources / tips for development
-> How to test the service without backend setup - https://sharegpt.com/c/0iYVIAJ

Requirements for feature
Input for "Other" option for Missed Session will just be a big box

Any context for feature
n/a

Resources / tips for development
n/a

Requirements for feature

• Utilize the GET /mentee and /mentor routes
• Add the token mechanism implemented in PR #76

Any context for feature
N/A

Resources / tips for development
Feel free to make any edits to backend as well if needed

What do we need?

Create a button component that can be reused all across the app. This component should be generic so that without any changes to the component it can be shared by various pages

• We need 3 types of buttons (filled active, outlined active, filled disabled).
• Button should be resizable

Example uses

Filled button in active state

Filled button in disabled state

Filled and Outlined Button in active state (resizable)

Resources

You are encouraged to look for more resources if needed, but here some I have -

https://www.kodeco.com/34851726-swiftui-button-tutorial-customization#toc-anchor-008
Shows ButtonStyle protocol around 10:59 - https://youtu.be/Kt4vpQ9ms5E?t=659
Look into Apple's ButtonStyle protocol - https://developer.apple.com/documentation/swiftui/buttonstyle

https://betterprogramming.pub/create-custom-button-styles-in-swiftui-f3778f695266

Change default port for starting backend server from 5000 to 3000

On MacOS, port 5000 is being used already - https://progressstory.com/tech/port-5000-already-in-use-macos-monterey-issue/
Therefore, when our server tries to use port 5000 it fails as following

Requirements for feature

• Drawer Container must appear from the bottom of the screen whenever an input field is clicked
• Ensure the Drawer is generic and can be used for things like tag edit, mentor college selection etc.
• Paragraph Input Component must take in a question and allow user to answer the question.
• State for this component will be stored by its parent (for eg. in signup we will store the answer in the sign up screen state)

Any context for feature
Editing forms on phones is always hard especially when we have to enter long answers inside a one or two line input field. To solve this, our app provides a big space for the user to list their thoughts. This Drawer Container will act as a container for several of our input fields including the paragraph input (eg. Tag Selector, Mentor College Selector, etc.)

Resources / tips for development

• See if you can create the Drawer Container and Paragraph Input as their own standalone components. This way it will be easy to change what we want to show inside the Drawer Container to support are several use cases.
• Might be a helpful read to separate container and its contents - https://betterprogramming.pub/swiftui-reusable-components-higher-order-components-192c65375c36
• Animation might be helpful - https://stackoverflow.com/questions/63066800/how-do-you-create-a-drawer-like-slide-out-animation

This should be a reusable component because we will use this in multiple views. This component has multiple moving parts so will be useful to first plan the entire implementation.

Though the final version of this component needs to filter the suggestions based on the text input, ignore that part for the scope of this task. First let's try to get the checkable functionality right.

Component Inputs -

1. List of Tags - list of strings that the user can select from
2. Selected Inputs (these will be the ones that are selected - should be checked in the tag list and should appear as tags right below the text input) -- this state should be created outside the component so that its parent can use the state once the component is closed

Notes -

• Whenever a tag is checked, it should appear in the list of blue tags.
• Blue Tags can be its own component os that you can just reuse it for multiple tags)

• Sign-up route should be created for the frontend to create users with.
• Mentor/Mentee models should be implemented as discussed in DB Schema design #17
• Add error handling (https://github.com/TritonSE/LAK-Goods-Transport-Application/tree/main/backend)

Requirements for feature

• Assemble components like Drawer Container / Tag Inputs etc. to create Sign Up Step 3
• Create components for year selector etc. if needed
• Connect step 3 with other steps and finish Sign Up Flow (i.e. make sure model/state is being updated by this page)

Feel free to create PR even if not all these tasks are done!

Any context for feature
This task is blocked by #36 and #33 so as long as they are open don't start this

Resources / tips for development
Lmk if you need any resources!

Requirements for feature

• When keyboard appears, move view up so the logo and app name aren't visible
• Make sure password and email boxes do not move upon appearance of error messages
• Connect to rest of app with routing/navigation

• Replace multiple calls to .custom("Metropolis-Regular", size: 16) with one call at the main app file
• Remove hardcoded pixel sizes and make sure screen resizes on all iPhones. Eg -

Any context for feature

Finishing up login page, lower priority task for now

Resources / tips for development

• Look at sign up page for navigation help

Finish up the Tag Input Editor by combining all the work done by the following issues

• #26
• #30

Requirements for feature

• Reusable component should be made such this bullet view can be inserted in most pre/post screens
• This component should not maintain the state of bullets directly but should instead have its parent (screen) maintain the state and pass a reference to the state to this component
• Create the + button
• Ensure the bullets allow checkboxes as well
• Drawer container + Paragraph Input should be utilized for bullet editing. #33

Note - This task doesn't ask for creating a particular screen but instead it should create the bullet system which can be easily used in all screens

Any context for feature
Quite a few of our pre/post questions are answered in the form of bullets/checkbox items. That's why we can create a reusable bullet system that can be reused through out.

Resources / tips for development
Lmk if you need any resources!