hack4impact-calpoly / general-vms Goto Github PK

We are going to want to switch out certain things in our app based on the environment.

For now, you can just make this change based on the port. This will change later but this is good enough for testing.

Here's an example search that may yield stuff that's useful: "node express backend environment variables prod vs dev" -- https://www.google.com/search?q=node+express+backend+environment+variables+prod+vs+dev&rlz=1C1CHBF_enUS798US798&oq=node+express+backend+environment+variables+prod+vs+dev&aqs=chrome..69i57j33i160l2j33i299.56115j0j7&sourceid=chrome&ie=UTF-8

NOTE: We do want this to be "correct" in a sense so it's worth spending the time investigating for the best solution. Please write down any findings on things that do work and don't work and pros/cons of different approaches and why we want to use the way you have suggested. It's fine if this write up is short... because React recommends it officially is totally ok for a reason.

• Investigation
• Documentation
• Implementation

Title

This is a utility component. Its point is for another component that needs to fetch data to use it to display (for now) a spinner or progress circle while data is being loaded in and supply the data once it has been loaded in to the component. This can be a HOC (higher order component) or it can use composition principles. I think for now composition may be easier and might be more modular, if more work. A given component would use it like this:

const MyComponent = () => {
   // some stuff...
   return (
       // some stuff
       <DataLoader loadingComponent={...} query={...} onceLoadedComponent={...} errorComponent={...} />
       // some stuff
   );
};

NOTE: Cool component react provides called Suspense to make this easier: https://reactjs.org/docs/concurrent-mode-suspense.html

The component should take props that make it modular like you see above. The loadingComponent should be a React element of some sort ( like MyLoadedDataComponent). A number of the props should be optional (like errorComponent) with a default if it's not specified.

The overall behavior should be:

• Call the query (this will probably be an HTTP request)
• While loading, display that it's loading in some way (either through prop or default)
• Once loaded, it passes in the data as a prop to the component that should be shown once loaded.

Once again, how you do this is sorta up to you. Feel free to talk to the team about plans and decisions.

In terms of a query, this can be an abstract concept. It could be an HTTP request or a GraphQL query (it shouldn't matter). Your component should just require some function to exist to make the given "query" (this will be an async function).

• Create component of some type
• Implement proper behavior
• Probably make some interface called Query that has to have certain functional behavior. The needed behavior is up to you, as the component will need to use some function it specifies to make the query.
• Write unit tests

This task will hopefully help with expediting not needing a given database to do a task. Instead, the part of the backend that gets the requests that will eventually call the database functions to retrieve/input/delete data will not need to know the inner details of that.

Abstract database class attributes:

• whether it's connected to source
• some function like this that can be a wrapper for other functions (perhaps a decorator for this!) so that we are checking that we are connected before making DB calls.
• abstract connect function
• some abstruct dummy function, like getUser()

Eventually, we can use this to plug in like a Mongo DB or a SQL DB or whatever as we need.

• Create abstract Database class that contains basic info
• Create a "dummy" database instance (just as file) that for now just returns dummy data and implements necessary functions to extend Database class.

Title

Title

Sometimes when developing, it's not convenient to use the actual backend and get it running, since it might be broken or not scale well. This task is to create a mock backend. What that means is creating a mock backend (in frontend) that the frontend uses by default instead of connecting to the backend.

This means creating classes that can be switched out (common interface called like Backend or Server) that extend calls the frontend will need to make to the backend.

Example: Let's say on the frontend we need to get the user's volunteer events. The component that needs to do that may call serverInstance().getVolunteerEvents(user). The server instance would have a function called getVolunteerEvents that takes a user and makes the appropriate HTTP request to do so. It then parses the response and gives it back to the component. The mock backend would not make the HTTP request; instead it would return some default mocked response to the frontend.

This task is to create a form and new page (maybe like /personal-info) and record:

• First name
• Last name
• Car type

Only those for now.

This is a software design task. Admins/staff need to be able to create forms and users need to be able to fill them out.

This is based on https://www.notion.so/h4i/Form-creation-ab561f8da7f142dbb40594a8da1e8126

Forms will consist of:

• Form fields
  • This includes a title question and the actual input
  • Field type: number, date, text, time, etc
  • Need whether it's optional/required
• Form title and description
• Date form is published
• Whether form can be taken anonymously
• options for what should happen after a form is submitted
• predefined form type

This is probably best achieved partially by using a library like: https://github.com/rjsf-team/react-jsonschema-form. Something that takes a form/schema and dynamically renders the form so we don't have to do so.

cd test-app/backend

npm run lint-check

Oops! Something went wrong! :(

ESLint: 7.32.0

ESLint couldn't find the config "standard" to extend from. Please check that the name of the config is correct.

https://blog.nrwl.io/lerna-used-to-walk-now-it-can-fly-eab7a0fe7700

This task is to set up unit testing in the backend. Just follow something like: https://www.pluralsight.com/guides/how-to-test-react-components-in-typescript. You may need to edit the package.json for this (to modify test script or add new ones you want).

NOTE: Frontend tests are already running in the frontend. Feel free to add more script options if you want.

The backend currently does not have unit tests so please add just one basic unit test for src/server.ts. Create this in a new test directory (so there will be src and test).

At the end of this, we should be able to run npm test in either the frontend and backend successfully.

• Jest Config set up for backend with necessary installations done
• Backend unit test
• Frontend and backend tests are succeeding. (npm test)

We need designs for what it will look like for an admin or volunteer to sign up for an event/shift. It may be helpful to take inspiration from past projects H4I has done that are VMSs.

This task is just to design that page.

Check out https://nx.dev/recipe/using-tailwind-css-in-react

This page assumes the user has successfully logged in. The page should be one that allows them to easily (in a way that looks better than the navbar) navigate to other pages. Here we may also want to include an additional information thing and maybe a slideshow (would be nifty!) for like the VMS. Idk maybe we think of something cool and creative to put on the homepage. Up for ideas!

• Home page design
• Home page can navigate to other pages

We are going to want to switch out certain things in our app based on the environment.

The easy example, and one we should implement, is the changing backend URL that we will want to hit (for dev, this should be localhost:<port defined in environment variable> and for the prod URL it should be just some garbage for now (just make something up, it won't be used for awhile).

Check out https://create-react-app.dev/docs/adding-custom-environment-variables/ and search "react app environments".

NOTE: We do want this to be "correct" in a sense so it's worth spending the time investigating for the best solution. Please write down any findings on things that do work and don't work and pros/cons of different approaches and why we want to use the way you have suggested. It's fine if this write up is short... because React recommends it officially is totally ok for a reason.

• Investigation
• Documentation
• Implementation

Create a new file in the backend specifically for creating and sending emails to a given email account that has as parameters the email address, the subject, and the email body and creates/sends an email to the email address.

Will need to look into how to do this (try to find best practices).

Create endpoints related to #43 (can GET personal info, PUT personal info, POST personal info). No delete is needed for now.

This is blocked until the unit test task (#4) is done.

This task is to setup a GH action workflow that lints and runs unit tests for any new pushes. This will help reviewers not have to worry about that.

• Workflow does lint check on files
• Workflow runs unit tests

Set up husky for frontend AND backend. This means installing it in the root directory of test-app (/test-app) probably (like this and setting up linting/test running for each package.

For adding test support, this may involve changing the test script in the package.json to exit successfully.

• Install Husky
• Install linter (eslint)
• Create husky precommit hook to run linter
• Add hook to run tests

Title

This task is to create a new "See Forms" page on /forms/view. This page should pull from the backend as a GET for all the forms (/api/forms) that have been made. This is not for the filled out forms yet. This is just to get the forms the admins/staff have created that volunteers can/have filled out. The page should show some sort of list of forms in some way that show each form's:

• Title
• Date Published
• Who published it (let's say this is just a string for now)
• Form type (for now this can only be "waiver")

If some of these fields are annoying or don't fit well, we can talk about how to reorganize it or what needs to be removed.

Gracefully handle (and display) when there are no submitted forms.

• Make GET call
• Create mock data for this (ignore result of GET call and immediately return mock data)
• Design page
• Implement page design to show the form data mentioned in some way
• Create some unit tests for the page

BLOCKED ON #11

This will be a PATCH request to edit information of a shift. Editable info includes title, description, max volunteers, start/end time.

Once again, do proper error detection as needed and add to the Database instances as needed.

This is just a test application so you can sorta do whatever. Just try to make it look decent and cohesive between the 2.

Here is the Navbar for the Happy Hats project: https://github.com/hack4impact-calpoly/happy-hats/blob/173baba2ae7f17eb92ad839cf7fef506d7d6b378/frontend/src/components/Navbar.js.

For any user-related stuff (collapsing certain links in the navbar) just ignore that and show all links. The links should include:

• Shifts
• Sign in/sign out
• Volunteers page
• Home page (can be picture)

For component organizations, see: https://github.com/hack4impact-calpoly/general-vms/wiki/Frontend-Component-Organization.

Footer (example should include (and can just fill out with garbage for now):

• contact info
• fake information about organization (Test Organization, 290(D)(9), founded in ...)
• Made by Hack4Impact

Please note, you do not have to make it similar to the ones I've posted above. They can be improved/changed as long as they are still functional.

• Navbar
• Footer
• Navbar and Footer integrated into App

This task is to design a waiver form on the frontend that the admin creates. So this is a form to create a specific waiver form. The fields the admin needs to fill out include:

• title for form (limit of let's say 200 chars)
• description (limit of 500 chars)
• complete by date (datepicker)

The data of the form that gets sent to the backend endpoint /api/form/waiver as a POST request:

• title for form

• description

• complete by date

• New page on /form/waiver on frontend

• Page let's user fill out form fields mentioned above

• Page does validation on inputs

• Page makes HTTP request to endpoint with given fields as JSON

• Create interface(s) for the data required here (so called like WaiverFormRequest)

• Create some unit tests for the page

See title and make VSCode use prettier extension

Assume a isUserAdmin middleware function works.

This endpoint (/api/new-shift for now?) should take information as a POST request about a Shift and create that shift. Here is an example: https://github.com/hack4impact-calpoly/happy-hats/blob/173baba2ae7f17eb92ad839cf7fef506d7d6b378/backend/calendar/calendar-api.js#L108

For this endpoint, make sure to do error detection and send appropriate responses back. For when this needs to interact with the database, add to the Database abstract class and any instances of it a new function that would be called that you can use in the endpoint code.

Also need to create a shift schema:

• Start datetime

• End datetime

• Max volunteers

• title

• description

• event admin (probably just the creator)

• getShiftTime() function that returns total time of shift (time interval type)

• Shift interface

• New shift endpoint

Related to #21

This is to make the backend POST endpoint /api/waiver. The data that makes it here and the validations required are described in #21. Validate the request data and then append to that data the:

• publish date (current date; this field should be called the publishDate or something)

• the user who published it (just a string here is fine for now)

• last edited date (also current date; can be like editDate or something)

• user who last edited it (same as publisher for this endpoint)

• Create new endpoint

• Create interface for the data that will be submitted to database (WaiverForm or something)

• Do validations on incoming data

• Append the new data (this data must be appended by the backend)

• Give appropriate response to frontend (201 created with a form ID for the newly created for). The ID can be a hardcoded string for now.

Should be approximate match of #2 for user scheme (they should relatively agree).

For the user session, the idea here is to not necessarily rely on if we are using Amplify/Cognito vs something else for authentication. This means we need some idea of what we need from something like Amplify/Cognito to not rely on it but be able to create an instance of an interface or abstract class that gives the express server access to whatever it needs.

As an example let's imagine we are using Amplify. In the HTTP request, we attach a bearer token to an Authorization header. This token is used as an ID token in Amplify that we can ask AWS Amplify to verify in order to make sure the token is correct. We can then use that token as a lookup key to find our corresponding "User" in the database of users. From there, the endpoint can do whatever it needs to with the user object it now has and any other data sent with the HTTP request.

Another example is with JWTs. These are another type of token as what AWS Amplify gives but is structured differently and must be created and verified differently. The token being valid here indicates that whatever is in the token is also valid and can be used to retrieve the user object.

In either way, we get a token from the authorization header, verify the token, and then use it to retrieve a user object. OK. Which parts now are different for JWTs vs Cognito tokens?

• Well, verifying the token is different
• What field we might use to retrieve the user object may change

From this, we can create an abstract class/interface for the user session for what needs to happen. This sorta only works for tokens this way and we could further abstract things so that it's not reliant on a bearer token as the system for auth, but that can be for a later task if we have time.

BTW because we are using tokens this way, the backend does not maintain sessions, making it RESTful (ok not in the most technical sense but basically). This makes the backend slower (will be waiting on calls to other systems) and more reliant on other systems but it doesn't have to do as much anymore.

• Create user scheme/classes
• Create user session scheme/classes

Title

This task is somewhat of a design task. The goal here is to create a utility class or something of the sort that will generalize dealing with HTTP requests and responses to make it easier on anyone who needs to make them.

Here's an example of one I made from Happy Hats: https://github.com/hack4impact-calpoly/happy-hats/blob/173baba2ae7f17eb92ad839cf7fef506d7d6b378/frontend/src/utility/request-helpers.js

Some of the code I have in there is decent and other stuff is not so much. For now, you don't need to worry about authorization headers and stuff. You can take it out or leave it in there... up to you.

• Create new file
• Code it lol
• Create unit tests

Related to #22

The endpoint and information expected by the frontend can be found in #22.

• Create GET endpoint
• Make some mock data
• Create interface FormBasicView (data of one form + a form ID for each)
• Create interface FormBasicViewList (list of those. Just one field for now: forms).
• Send back 200 of list
• Create unit test(s)

• Install react-router-dom
• Standard page component
• BrowserRouter
• Homepage route (fine if page is blank)
• Login page route (fine if page is blank)

Take a look here and here for some inspiration. Feel free to take a different approach of this doesn't seem logical.

For the user schema (represented as a TS interface appropriately typed), we want to imagine the info the frontend would receive when a user logs in. This should at least include:

• Name
• Email
• User ID (just type as a string | number for now)
• if user is logged in (boolean)
• type of user/role (admin vs volunteer vs none)
• If user is approved
• cognito session (just specify as object for now)

Instead or in addition to storing role, can use different object types instead.

How the user is stored (whether we use Redux vs React Context vs something else) is still up for deciding. Feel free to contant @bglossner

• Create concept of a "user"
• Create hook for retrieving the user in any component
• Create setters to modify the user
• Create getter for if user is authenticated (just if they are logged in)

Currently BLOCKED on getting AWS Account for using Amplify.

Don't worry about it working with the backend for now. You can reference this file for help.

• Installed necessary dependencies in frontend
• Sign up page done
• Sign up page logs the new Cognito session Amplify gives back
• Login page done
• Login page redirects to /home upon successful login
• After login, console.log the new cognito session Amplify gives back.

BLOCKED ON #9

Each of these functions should expect req, res, and next as input, process something in someway and add anything necessary to the request or send it forward, and appropriately error on failure of something.

These functions should use concept in #9 for user session, where it doesn't rely on underlying implementation of the user session but understands it can call any functions that an implementation must define.

• Function for determining if user is authenticated (amplify example)
• Function for determining if user is an admin (amplify example)