feat: DH11 Applications #196
Conversation
|
WalkthroughThe pull request introduces a comprehensive update to the application schema and related components for managing DH11 applications. It includes the creation of new database tables ( Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used🪛 Biome
🔇 Additional comments (7)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
✅ Deploy Preview for profound-kringle-30b3e4 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 26
🧹 Outside diff range and nitpick comments (9)
src/pages/welcome.tsx (1)
Line range hint
9-41: Approve new Content component with a suggestion.The new
Contentcomponent is a significant improvement, providing comprehensive information about DeltaHacks X and clear calls-to-action. The responsive design ensures good presentation across different devices.Consider adding an
aria-labelto the email link for better accessibility:- <a href="mailto: tech@deltahacks.com" className="text-sky-400"> + <a href="mailto: tech@deltahacks.com" className="text-sky-400" aria-label="Email tech@deltahacks.com"> tech@deltahacks.com </a>src/server/router/reviewers.ts (2)
76-79: LGTM with a minor suggestion: Consistent casing in Prisma queryThe update to use
dH11Applicationanddh11ApplicationIdin the Prisma query is correct and aligns with the PR objectives. However, there's a minor inconsistency in the casing:
dH11Applicationuses a capital 'H'dh11ApplicationIduses a lowercase 'h'Consider standardizing the casing for consistency, preferably using
dh11Applicationto match the camelCase convention used elsewhere.
Line range hint
40-40: Update missed reference todH10ApplicationIdThere's a remaining reference to
dH10ApplicationIdthat needs to be updated for consistency with the other changes in this file.Please apply the following change:
- dH10ApplicationId: { + dh11ApplicationId: {This will ensure all references are consistently updated to the new DH11 naming convention.
src/pages/dashboard.tsx (2)
Line range hint
1-524: Update hardcoded event references.The file contains hardcoded references to "DeltaHacks X" in various components. Consider updating these to "DeltaHacks 11" to match the current event and application schema.
Here are some examples of lines that may need updating:
- Line 46:
Hey {session ? session.user?.name : ""}, we can{"'"}t wait to see you at Deltahacks X!- Line 301:
<title>Dashboard - DeltaHacks X</title>Consider using a constant or configuration value for the event name to make future updates easier.
Line range hint
1-524: Clean up commented-out code sections.The file contains several large blocks of commented-out code, particularly in the
CheckedIncomponent. To improve code readability and maintainability, consider removing these commented sections if they are no longer needed.If the commented code might be useful in the future, consider moving it to a separate file or documenting it elsewhere. This will help keep the main component file clean and easier to understand.
src/server/router/application.ts (4)
7-7: Rename the import todh11ApplicationSchemafor clarity.To improve code readability and avoid confusion, consider renaming the import to
dh11ApplicationSchemato clearly indicate that it represents the schema for the DH11 application.-import dh11schema from "../../schemas/application"; +import dh11ApplicationSchema from "../../schemas/application";
342-346: Improve error handling for missing previous application.Consider providing a more informative error message to indicate that the user does not have a previous DH10 application for autofill.
-if (!user || !user.dh10application) { - throw new TRPCError({ - code: "NOT_FOUND", - message: "No previous application found for autofill", - }); +if (!user?.dh10application) { + throw new TRPCError({ + code: "NOT_FOUND", + message: "No previous DH10 application found for autofill", + });
383-428: Remove commented out code.To improve code readability and maintainability, remove the commented out code for the
submitDh10mutation since it is no longer being used.-// submitDh10: protectedProcedure -// .input(applicationSchema) -// .mutation(async ({ ctx, input }) => { -// // make sure there is no existing application -// try { -// let gradDate = null; -// if (input.studyExpectedGraduation) { -// const possible = new Date(input.studyExpectedGraduation); -// if (!isNaN(possible.getTime())) { -// gradDate = possible; -// } -// } -// await ctx.prisma.dH10Application.create({ -// data: { -// ...input, -// birthday: new Date(input.birthday), -// studyExpectedGraduation: gradDate, -// User: { connect: { id: ctx.session.user.id } }, -// }, -// }); -// } catch (e) { -// if (e instanceof Prisma.PrismaClientKnownRequestError) { -// if (e.code === "P2002") -// throw new TRPCError({ -// code: "FORBIDDEN", -// message: "You have already submitted an application.", -// }); -// } -// } -// const user = await ctx.prisma.user.update({ -// where: { id: ctx.session.user.id }, -// data: { status: Status.IN_REVIEW }, -// }); -// await ctx.logsnag.track({ -// channel: "applications", -// event: "Application Submitted", -// user_id: `${user.name} - ${user.email}`, -// description: "A user has submitted an application.", -// icon: "📝", -// }); -// }),
Line range hint
429-459: Add logging and update user status after successful submission.To maintain consistency with the previous
submitDh10mutation, consider adding logging usingctx.logsnag.track()and updating the user's status toStatus.IN_REVIEWafter a successful DH11 application submission.submitDh11: protectedProcedure .input(applicationSchema) .mutation(async ({ ctx, input }) => { // aaaaaa try { let gradDate = null; if (input.studyExpectedGraduation) { const possible = new Date(input.studyExpectedGraduation); if (!isNaN(possible.getTime())) { gradDate = possible; } } await ctx.prisma.dH11Application.create({ data: { ...input, birthday: new Date(input.birthday), studyExpectedGraduation: gradDate, User: { connect: { id: ctx.session.user.id } }, }, }); + const user = await ctx.prisma.user.update({ + where: { id: ctx.session.user.id }, + data: { status: Status.IN_REVIEW }, + }); + + await ctx.logsnag.track({ + channel: "applications", + event: "DH11 Application Submitted", + user_id: `${user.name} - ${user.email}`, + description: "A user has submitted a DH11 application.", + icon: "📝", + }); } catch (e) { if (e instanceof Prisma.PrismaClientKnownRequestError) { if (e.code === "P2002") throw new TRPCError({ code: "FORBIDDEN", message: "You have already submitted an application.", }); } } }),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
- prisma/migrations/20241016042723_add_dh11_application_schema/migration.sql (1 hunks)
- prisma/schema.prisma (2 hunks)
- src/components/Applicant.tsx (3 hunks)
- src/pages/apply.tsx (6 hunks)
- src/pages/dashboard.tsx (2 hunks)
- src/pages/welcome.tsx (1 hunks)
- src/schemas/application.ts (2 hunks)
- src/server/router/application.ts (6 hunks)
- src/server/router/context.ts (1 hunks)
- src/server/router/reviewers.ts (3 hunks)
🧰 Additional context used
📓 Learnings (1)
src/components/Applicant.tsx (2)
Learnt from: fvcci PR: deltahacks/portal#191 File: src/components/Applicant.tsx:145-180 Timestamp: 2024-10-06T16:35:06.464Z Learning: In the `ApplicationContent` component within `src/components/Applicant.tsx`, not all fields in the education section are `FormInput` components; some fields use different component types, so refactoring should account for this diversity.Learnt from: fvcci PR: deltahacks/portal#191 File: src/components/Applicant.tsx:145-180 Timestamp: 2024-10-08T21:54:39.143Z Learning: In the `ApplicationContent` component within `src/components/Applicant.tsx`, not all fields in the education section are `FormInput` components; some fields use different component types, so refactoring should account for this diversity.
🪛 Biome
src/pages/apply.tsx
[error] 467-467: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/schemas/application.ts
[error] 181-181: Avoid redundant double-negation.
It is not necessary to use double-negation when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant double-negation(lint/complexity/noExtraBooleanCast)
🔇 Additional comments (23)
src/server/router/context.ts (1)
11-11: Confirm the project name change is intentional and consistent.The project name in the LogSnag initialization has been updated from "deltahacks-portal" to "deltahacks-11". This change aligns with the PR title mentioning "DH11 Applications".
To ensure consistency across the codebase, let's verify if this project name is used elsewhere:
✅ Verification successful
To ensure all instances are correctly identified, let's run an updated search:
Project name change is consistent across the codebase with no remaining instances of "deltahacks-portal".
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining occurrences of "deltahacks-portal" and new occurrences of "deltahacks-11" echo "Searching for 'deltahacks-portal':" rg "deltahacks-portal" --type ts --type tsx --type js --type jsx echo "Searching for 'deltahacks-11':" rg "deltahacks-11" --type ts --type tsx --type js --type jsxLength of output: 343
Script:
#!/bin/bash # Search for any remaining occurrences of "deltahacks-portal" and new occurrences of "deltahacks-11" echo "Searching for 'deltahacks-portal':" rg "deltahacks-portal" -g "*.ts" -g "*.tsx" -g "*.js" -g "*.jsx" echo "Searching for 'deltahacks-11':" rg "deltahacks-11" -g "*.ts" -g "*.tsx" -g "*.js" -g "*.jsx"Length of output: 344
prisma/migrations/20241016042723_add_dh11_application_schema/migration.sql (5)
7-8: LGTM: Enum creation looks good.The creation of the "YesNoUnsure" enum type is well-defined and follows best practices. It provides a clear set of options for fields that require a ternary response.
56-65: LGTM: DH11Review table structure looks good.The DH11Review table is well-structured with appropriate fields for storing review data. The use of foreign keys to link to User and DH11Application tables ensures data integrity.
67-68: LGTM: Unique index creation is appropriate.The creation of a unique index on the "dH11ApplicationId" column of the "User" table is correct. This ensures a one-to-one relationship between users and DH11 applications.
13-54: Consider adding constraints and validations to DH11Application table.The DH11Application table structure looks comprehensive. However, consider the following suggestions:
- Add CHECK constraints for fields like "previousHackathonsCount" to ensure non-negative values.
- Consider using an ENUM type for "tshirtSize" to restrict possible values.
- Verify if "studyEnrolledPostSecondary" should have a NOT NULL constraint.
- The "discoverdFrom" column has a typo. It should be "discoveredFrom".
To verify the usage of ARRAY types and ENUM types in your schema, run:
#!/bin/bash # Description: Check for ARRAY and ENUM type usage in the schema rg --type sql 'ARRAY|ENUM' prisma/
70-77: Verify the cascade behaviors for foreign key constraints.The foreign key constraints are correctly established, but please verify the following cascade behaviors:
User -> DH11Application: ON DELETE SET NULL, ON UPDATE CASCADE
This allows a user's application to be deleted without deleting the user.DH11Review -> DH11Application: ON DELETE NO ACTION, ON UPDATE CASCADE
This prevents deletion of an application if it has reviews.DH11Review -> User: ON DELETE RESTRICT, ON UPDATE CASCADE
This prevents deletion of a user if they have submitted reviews.Ensure these behaviors align with your application's requirements.
To verify the foreign key constraints in your schema, run:
✅ Verification successful
Cascade behaviors for foreign key constraints are correctly established as specified in the migration file. No issues found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for foreign key constraints in the schema rg --type sql 'FOREIGN KEY' prisma/Length of output: 1933
src/pages/welcome.tsx (1)
Line range hint
1-103: Summary of welcome page updatesThe changes to the welcome page significantly improve the user experience and reflect the transition to DeltaHacks X (DH11):
- The new
Contentcomponent provides comprehensive information about the event and clear calls-to-action.- The
getServerSidePropsfunction has been updated to handle DH11 applications, ensuring proper user flow.These changes align well with the PR objectives and enhance the overall functionality of the welcome page.
src/server/router/reviewers.ts (3)
15-15: LGTM: Correct renaming of application ID fieldThe renaming from
dH10ApplicationIdtodh11ApplicationIdis correct and consistent with the PR objectives. The type definition and naming convention are appropriate.
62-62: LGTM: Consistent update of input schemaThe input schema for the
getApplicationprocedure has been correctly updated to usedh11ApplicationId. This change is consistent with the previous renaming and maintains the optional nature of the input.
Line range hint
1-191: Summary of changes and recommendationsThe updates from DH10 to DH11 have been largely implemented correctly. Key points:
- The
ApplicationForReviewschema has been updated appropriately.- Input schemas and Prisma queries have been modified to reflect the new DH11 structure.
- A minor casing inconsistency was noted in the Prisma query.
- One reference to
dH10ApplicationIdwas missed and should be updated.Overall, the changes align well with the PR objectives. Please address the noted issues to ensure full consistency across the file.
src/pages/dashboard.tsx (1)
489-489: LGTM: Updated application reference to DH11.The change from
dh10applicationtodh11applicationin the include statement is correct and aligns with the updated application schema for DeltaHacks 11.To ensure consistency across the codebase, let's verify that all references to the application have been updated:
#!/bin/bash # Search for any remaining references to dh10application rg 'dh10application' --type typescriptprisma/schema.prisma (2)
167-224: New 'DH11Application' model is well-definedThe
DH11Applicationmodel is thoughtfully structured, capturing all necessary information for the application process. The fields are appropriately typed, and defaults are set where needed.
226-238: 'DH11Review' model relationships are correctly establishedThe
DH11Reviewmodel correctly references theDH11ApplicationandUsermodels, with relationships properly defined. This setup will facilitate effective management of application reviews.src/schemas/application.ts (2)
183-183: Ensure 'linkToResume' field handles null values correctlyThe
linkToResumefield is now defined asz.string().url().nullish(). Ensure that this allows fornullvalues appropriately, as applicants might not provide a resume link. If you want to accept empty values, consider using.nullable()instead of.nullish().Double-check if
.nullish()behaves as intended in this context.
191-191: Ensure 'underrepresented' field captures intended dataThe
underrepresentedfield uses theYesNoUnsureenum. Verify that this aligns with the application's requirements and that it provides meaningful data for analysis. If more detailed information is needed, consider expanding the options or allowing applicants to specify.Confirm that the current options are sufficient and comply with data collection policies.
src/components/Applicant.tsx (1)
170-170:⚠️ Potential issueRemove misplaced
optionalkeywordThe
optionalkeyword is placed outside of any JSX component, which will cause a syntax error. It should be passed as a prop to theFormInputcomponent.Apply this diff to fix the syntax error:
)} - optional <FormInput + optional label="Previous Hackathons Count" text={data?.previousHackathonsCount.toString()} />Likely invalid or redundant comment.
src/server/router/application.ts (2)
336-340: Verify the existence of thedh10applicationrelationship.Ensure that the
dh10applicationrelationship exists in theUsermodel and is correctly included in the Prisma query.✅ Verification successful
Verified the existence of the
dh10applicationrelationship and its correct inclusion in the Prisma query.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the `dh10application` relationship in the `User` model. # Test: Search for the `dh10application` relationship in the `User` model. # Expect: The relationship should be defined. rg --type prisma 'dh10application' -A 5 -B 5Length of output: 75
Script:
#!/bin/bash # Description: Verify the existence of the `dh10application` relationship in the `User` model. # Search for the `dh10application` relationship within .prisma files. rg 'dh10application' --type-add 'prisma:*.prisma' --type prisma -A 5 -B 5Length of output: 740
349-382: Ensure all required fields are mapped correctly.Double-check that all the required fields from the DH10 application are correctly mapped to the corresponding fields in the DH11 application autofill object. Verify that no important information is missing or incorrectly mapped.
src/pages/apply.tsx (5)
133-133: Verify the word count calculation in the 'FormTextArea' componentThe calculation
{150 + 1 - currentLength}for the remaining words might be off by one. Typically, the remaining word count is calculated as{maxWords - currentLength}. Please ensure this calculation accurately reflects the intended word limit.
180-180: LGTM on updating the mutation to 'submitDh11'The mutation has been correctly updated to
submitDh11, reflecting the new application process.
423-459: Form fields updated correctly for 'Long Answer' sectionThe 'Long Answer' section fields have been updated appropriately with new IDs, labels, error handling, and current length calculations. This aligns with the new application requirements.
785-785: LGTM on updating the Prisma include to 'dh11application'The Prisma query now includes
dh11application, correctly aligning with the updated application schema.
801-801: LGTM on redirect logic after application submissionThe redirect condition correctly checks
userEntry.dh11applicationto determine if the user has submitted an application, ensuring proper navigation.
|
|
||
| const logsnag = new LogSnag({ | ||
| token: env.LOGSNAG_TOKEN, | ||
| project: "deltahacks-portal", | ||
| project: "deltahacks-11", | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider improving LogSnag initialization for better maintainability and error handling.
While the current implementation works, here are some suggestions to enhance it:
-
Use an environment variable for the project name to improve maintainability:
project: env.LOGSNAG_PROJECT_NAME,
-
Add error handling for LogSnag initialization:
let logsnag: LogSnag | null = null; try { logsnag = new LogSnag({ token: env.LOGSNAG_TOKEN, project: env.LOGSNAG_PROJECT_NAME, }); } catch (error) { console.error("Failed to initialize LogSnag:", error); }
-
Consider importing only the necessary parts of the LogSnag module:
import { LogSnag } from "@logsnag/node";
These changes would make the code more robust and easier to maintain in the future.
| -- AlterTable | ||
| ALTER TABLE "User" ADD COLUMN "dH11ApplicationId" STRING; |
There was a problem hiding this comment.
💡 Codebase verification
Missing Foreign Key Constraint for "dH11ApplicationId"
It appears that the "dH11ApplicationId" column added to the "User" table does not have a foreign key constraint referencing the "DH11Application" table. If this relationship is intended, please add the appropriate foreign key constraint to ensure referential integrity.
- File:
prisma/migrations/20241016042723_add_dh11_application_schema/migration.sql
🔗 Analysis chain
Consider using snake_case for column names.
While the addition of the "dH11ApplicationId" column to the "User" table is correct, consider using snake_case for column names to follow SQL conventions. For example, "dh11_application_id" would be more standard.
Also, ensure that this column is intended to create a one-to-one relationship between User and DH11Application.
To verify the relationship, run the following script:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any other references to DH11Application in the User table or vice versa
rg --type sql 'User.*DH11Application|DH11Application.*User'
Length of output: 1089
Script:
#!/bin/bash
# Description: Verify the existence of the DH11Application table in the migration files
rg --type sql 'CREATE TABLE\s+"DH11Application"'
Length of output: 158
Script:
#!/bin/bash
# Description: Check for foreign key constraints on dH11ApplicationId in the User table
rg --type sql 'ALTER TABLE\s+"User".*ADD\s+FOREIGN KEY\s+\("dH11ApplicationId"\)\s+REFERENCES\s+"DH11Application"'
Length of output: 116
Script:
#!/bin/bash
# Description: Check for inline foreign key constraints on dH11ApplicationId in the User table's CREATE TABLE statement
rg --type sql 'CREATE TABLE\s+"User".*FOREIGN KEY\s+\("dH11ApplicationId"\)\s+REFERENCES\s+"DH11Application"'
Length of output: 111
src/pages/welcome.tsx
Outdated
| include: { dh11application: true }, | ||
| }); | ||
|
|
||
| // If submitted then go to dashboard | ||
| if (userEntry && userEntry.dh10application !== null) { | ||
| if (userEntry && userEntry.dh11application !== null) { |
There was a problem hiding this comment.
💡 Codebase verification
Remaining references to dh10application found
Several references to dh10application still exist in the codebase:
src/server/router/application.ts:include: { dh10application: true }, if (!user || !user.dh10application) { const dh10App = user.dh10application;prisma/schema.prisma:dh10application DH10Application? @relation(fields: [dH10ApplicationId], references: [id])
Please update these references from dh10application to dh11application to ensure consistency across the codebase.
🔗 Analysis chain
Approve changes to getServerSideProps with a verification request.
The update from dh10application to dh11application correctly aligns with the new application version. This change ensures that users are properly redirected based on their DH11 application status.
Please verify that this change from DH10 to DH11 is consistent across the entire codebase. Run the following script to check for any remaining references to dh10application:
This script will help ensure that all necessary updates have been made consistently.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining references to dh10application
# Test: Search for dh10application references
echo "Searching for dh10application references:"
rg --type-not sql 'dh10application'
# Test: Compare occurrences of dh10application and dh11application
echo -e "\nComparing occurrences:"
echo "dh10application occurrences:"
rg --type-not sql 'dh10application' | wc -l
echo "dh11application occurrences:"
rg --type-not sql 'dh11application' | wc -l
Length of output: 761
src/pages/dashboard.tsx
Outdated
| @@ -501,7 +501,7 @@ export const getServerSideProps = async ( | |||
| } | |||
|
|
|||
| // If submitted then do nothing | |||
| if (userEntry && userEntry.dh10application !== null) { | |||
| if (userEntry && userEntry.dH11ApplicationId !== null) { | |||
There was a problem hiding this comment.
💡 Codebase verification
Inconsistent Casing in DH11 Application References
The search revealed inconsistent casing for dh11application and dH11ApplicationId across the codebase. Please standardize the casing to ensure consistency and prevent potential bugs.
Affected Files:
src/server/router/reviewers.tssrc/server/router/application.tssrc/pages/welcome.tsxsrc/pages/dashboard.tsxsrc/components/Applicant.tsxsrc/pages/apply.tsx
🔗 Analysis chain
LGTM: Updated application check to use DH11ApplicationId.
The condition has been correctly updated to check for the existence of a DH11 application using the dH11ApplicationId field.
Let's verify the casing consistency of the application references:
This will help us ensure that the casing is consistent across the codebase and aligns with Prisma's naming conventions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all references to dh11 or DH11 in application-related fields
rg -i 'dh11.*application' --type typescript
Length of output: 73
Script:
#!/bin/bash
# Search for all references to dh11 or DH11 in application-related fields within TypeScript files
rg -i 'dh11.*application' --glob '*.ts' --glob '*.tsx'
Length of output: 1877
| hackerKind String[] @default([]) | ||
| alreadyHaveTeam Boolean | ||
| workshopChoices String[] @default([]) | ||
| discoverdFrom String[] @default([]) |
There was a problem hiding this comment.
Typo in field name 'discoverdFrom'
The field name discoverdFrom appears to be misspelled. It should be discoveredFrom.
Apply this diff to correct the typo:
- discoverdFrom String[] @default([])
+ discoveredFrom String[] @default([])📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| discoverdFrom String[] @default([]) | |
| discoveredFrom String[] @default([]) |
| @@ -123,11 +124,12 @@ | |||
| ) { | |||
| throw new TRPCError({ code: "UNAUTHORIZED" }); | |||
| } | |||
| // TODO: Use Status from DH11 Application instaed of User | |||
There was a problem hiding this comment.
Remove the TODO comment and update the status retrieval logic.
Since the DH11Application model is now being used, update the status retrieval logic to use the status field from the DH11Application model instead of the User model.
-// TODO: Use Status from DH11 Application instaed of UserCommittable suggestion was skipped due to low confidence.
src/server/router/application.ts
Outdated
| await ctx.prisma.dH11Application.delete({ | ||
| where: { id: user.dH11ApplicationId }, | ||
| }); |
There was a problem hiding this comment.
Update the Prisma query to use the dH11Application relationship.
Modify the Prisma query to delete the DH11 application using the dH11Application relationship instead of the id field.
-await ctx.prisma.dH11Application.delete({
- where: { id: user.dH11ApplicationId },
-});
+await ctx.prisma.dH11Application.delete({
+ where: { userId: user.id },
+});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| await ctx.prisma.dH11Application.delete({ | |
| where: { id: user.dH11ApplicationId }, | |
| }); | |
| await ctx.prisma.dH11Application.delete({ | |
| where: { userId: user.id }, | |
| }); |
src/server/router/application.ts
Outdated
| user.dH11ApplicationId === null || | ||
| user.dH11ApplicationId === undefined | ||
| ) { |
There was a problem hiding this comment.
Update the property name to match the DH11Application model.
Change the property name from dH11ApplicationId to dH11Application to align with the DH11Application model.
-if (
- user.dH11ApplicationId === null ||
- user.dH11ApplicationId === undefined
-) {
+if (!user.dH11Application) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| user.dH11ApplicationId === null || | |
| user.dH11ApplicationId === undefined | |
| ) { | |
| if (!user.dH11Application) { |
src/server/router/application.ts
Outdated
| @@ -161,14 +163,14 @@ | |||
| .query(async ({ ctx }) => { | |||
| const user = await ctx.prisma?.user.findFirst({ | |||
| where: { id: ctx.session.user.id }, | |||
| include: { dh10application: true }, | |||
| include: { dh11application: true }, | |||
There was a problem hiding this comment.
Update the Prisma query to use the dH11Application model.
Modify the Prisma query to include the dH11Application model instead of the dh11application model.
-include: { dh11application: true },
+include: { dH11Application: true },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| include: { dh11application: true }, | |
| include: { dH11Application: true }, |
src/pages/apply.tsx
Outdated
| onChange={(val: SelectChoice[] | null) => | ||
| onChange(val?.map((v: SelectChoice) => v.value)) | ||
| } | ||
| value={workshops.filter((val) => | ||
| value?.includes(val.value as workshopType) | ||
| )} | ||
| isMulti={true} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix incorrect reference to 'workshops' in 'hackerKind' field
In the 'hackerKind' field, you're referencing workshops instead of hackerTypes when setting the value and filtering options. This could cause incorrect options to be displayed.
Please apply the following changes:
<CustomSelect
options={hackerTypes}
onChange={(val: SelectChoice[] | null) =>
onChange(val?.map((v: SelectChoice) => v.value))
}
- value={workshops.filter((val) =>
+ value={hackerTypes.filter((val) =>
value?.includes(val.value as hackerType)
)}
isMulti={true}
/>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| onChange={(val: SelectChoice[] | null) => | |
| onChange(val?.map((v: SelectChoice) => v.value)) | |
| } | |
| value={workshops.filter((val) => | |
| value?.includes(val.value as workshopType) | |
| )} | |
| isMulti={true} | |
| onChange={(val: SelectChoice[] | null) => | |
| onChange(val?.map((v: SelectChoice) => v.value)) | |
| } | |
| value={hackerTypes.filter((val) => | |
| value?.includes(val.value as hackerType) | |
| )} | |
| isMulti={true} |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (12)
src/components/Background.tsx (1)
16-16: Remove or document the commented-out code.The commented-out gradient div code is no longer in use. To maintain code cleanliness, it's generally better to remove unused code. If there's a specific reason to keep it (e.g., for future reference), consider adding a comment explaining why it's being kept or move it to a separate document for future reference.
If you decide to remove it, you can use this diff:
- {/* <div className="pointer-events-none light-gradient dark:dark-gradient absolute inset-0 -left-[50%] -top-[50%] h-[200%] w-[200%] -rotate-12 animate-slow-bg" /> */}If you decide to keep it, add a explanatory comment:
+ {/* Gradient background - kept for reference in case we need to revert <div className="pointer-events-none light-gradient dark:dark-gradient absolute inset-0 -left-[50%] -top-[50%] h-[200%] w-[200%] -rotate-12 animate-slow-bg" /> */}src/components/NavBar.tsx (1)
38-40: LGTM: User name capitalization added.The
capitalizeclass has been added to the user's name display, which will improve the presentation by capitalizing the first letter of each word in the name. This is a good UI enhancement.Consider adding a comment explaining the purpose of the
capitalizeclass for better code maintainability. For example:<strong className="font-bold capitalize"> + {/* Capitalize the first letter of each word in the user's name */} {session?.user?.name} </strong>src/pages/killswitch.tsx (1)
22-22: Commented code update notedThe commented-out header text has also been updated from "DeltaHacks X" to "DeltaHacks XI". Consider removing this commented code if it's no longer needed.
src/pages/checkin.tsx (1)
199-199: LGTM: Page title updated correctly.The event name has been successfully updated from "DeltaHacks X" to "DeltaHacks XI" in the page title. This change is consistent with the PR objective of updating the event branding and is important for SEO and user experience.
For consistency, consider using the full event name "DeltaHacks XI" instead of the abbreviated "DH XI" in other parts of the application, if applicable.
src/server/router/application.ts (4)
330-379: LGTM: getPrevAutofill procedure implementedThe
getPrevAutofillprocedure is well-implemented, providing a smooth transition from DH10 to DH11 applications. It correctly maps the fields and handles type conversions where necessary.Consider adding a more specific error message when no DH10 application is found:
if (!user || !user.dh10application) { throw new TRPCError({ code: "NOT_FOUND", - message: "No previous application found for autofill", + message: "No DH10 application found for autofill. You may proceed with a new application.", }); }
380-425: Remove commented-out submitDh10 procedureThe
submitDh10procedure is commented out and no longer needed as we're transitioning to DH11. To maintain a clean codebase, it's recommended to remove this commented-out code.Remove the entire commented-out
submitDh10procedure (lines 380-425).
Line range hint
426-456: LGTM: submitDh11 procedure implemented with minor improvements neededThe
submitDh11procedure is correctly implemented for creating DH11 applications. It handles date conversions and includes appropriate error handling for duplicate submissions.
- Remove the comment "aaaaaa" on line 429 as it doesn't provide any meaningful information.
- Consider adding a status update for the user after successful submission, similar to the DH10 implementation:
await ctx.prisma.dH11Application.create({ data: { ...input, birthday: new Date(input.birthday), studyExpectedGraduation: gradDate, User: { connect: { id: ctx.session.user.id } }, }, }); + +await ctx.prisma.user.update({ + where: { id: ctx.session.user.id }, + data: { status: Status.IN_REVIEW }, +}); + +await ctx.logsnag.track({ + channel: "applications", + event: "DH11 Application Submitted", + user_id: `${ctx.session.user.name} - ${ctx.session.user.email}`, + description: "A user has submitted a DH11 application.", + icon: "📝", +});
467-474: LGTM: deleteApplication procedure updated for DH11The
deleteApplicationprocedure has been correctly updated to handle DH11 applications instead of DH10. The changes are consistent and maintain the existing error handling and logging.Consider updating the status to a more appropriate value after deleting the application:
await ctx.prisma.user.update({ where: { id: ctx.session.user.id }, - data: { status: Status.IN_REVIEW }, // Replace with the correct status + data: { status: Status.NOT_APPLIED }, });src/pages/scanner.tsx (2)
Line range hint
1-624: Consider refactoring for improved maintainability.The file contains multiple large components (FoodManagerView, SponsorView, HackerView, EventsView) in addition to the main Scanner component. To improve maintainability and readability, consider splitting these into separate files.
Here's a suggested file structure:
src/ components/ FoodManagerView.tsx SponsorView.tsx HackerView.tsx EventsView.tsx pages/ scanner.tsxThis separation will make the codebase more modular and easier to maintain.
Line range hint
280-286: Address TODO comments and remove commented-out code.There are TODO comments and commented-out code sections in the file. These should be addressed to improve code quality and readability.
- On lines 280-286, there's a TODO comment about checking image rendering code. This should be resolved and the comment removed.
- On lines 619-624, there's a commented-out component
RedirectToDashboard. If this is no longer needed, it should be removed.Please review these sections, implement the necessary changes, and remove the comments and unused code.
Also applies to: 619-624
src/pages/apply.tsx (1)
423-459: LGTM! Long answer questions updated for DeltaHacks XIThe long answer questions have been appropriately updated for DeltaHacks XI. The new questions cover a range of topics that should help in evaluating applicants.
For consistency, consider updating the word count limit comment on line 133 to match the new questions:
- {150 + 1 - currentLength} words left + {150 - currentLength} words leftThis small change makes the word count more intuitive and consistent with the actual limit.
prisma/schema.prisma (1)
236-236: Specify 'onDelete' Behavior for 'reviewer' RelationThe relation
reviewerin theDH11Reviewmodel does not specify anonDeletebehavior. For clarity and to prevent unintended cascading deletions, consider explicitly setting theonDeleteattribute.Apply this diff to specify the delete behavior:
- reviewer User @relation(fields: [reviewerId], references: [id]) + reviewer User @relation(fields: [reviewerId], references: [id], onDelete: NoAction)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (15)
- prisma/schema.prisma (2 hunks)
- src/components/ApplicationsTable.tsx (1 hunks)
- src/components/Background.tsx (1 hunks)
- src/components/DHBranding.tsx (1 hunks)
- src/components/NavBar.tsx (2 hunks)
- src/pages/_app.tsx (2 hunks)
- src/pages/apply.tsx (8 hunks)
- src/pages/checkin.tsx (3 hunks)
- src/pages/dashboard.tsx (7 hunks)
- src/pages/killswitch.tsx (1 hunks)
- src/pages/login.tsx (1 hunks)
- src/pages/me.tsx (1 hunks)
- src/pages/scanner.tsx (1 hunks)
- src/pages/welcome.tsx (3 hunks)
- src/server/router/application.ts (6 hunks)
✅ Files skipped from review due to trivial changes (3)
- src/components/ApplicationsTable.tsx
- src/pages/login.tsx
- src/pages/me.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- src/pages/welcome.tsx
🧰 Additional context used
🪛 Biome
src/pages/apply.tsx
[error] 467-467: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (30)
src/components/Background.tsx (2)
11-16: Verify the design change with the team.The switch from a gradient background to a static image represents a significant visual change. Ensure that this alteration aligns with the overall design direction of the project and has been approved by the design team.
To help with the design review, you could generate a visual diff of the component. While we can't do this automatically in this environment, you might want to create before and after screenshots for the design team to review.
11-15: 🛠️ Refactor suggestionConsider optimizing the background image implementation.
While the switch from a gradient to an image can provide more visual interest, there are several points to consider:
The image is currently hosted on Imgur. For production use, it's recommended to host the image on a more reliable and controllable platform, preferably your own content delivery network (CDN).
The empty
altattribute may pose accessibility issues. Consider adding a descriptive alt text or, if the image is purely decorative, usealt=""explicitly.For performance optimization, consider implementing lazy loading for the image or using a responsive image technique.
Here's a suggested implementation that addresses these points:
<img src="/assets/background.png" srcSet="/assets/background-small.png 1x, /assets/background.png 2x" className="opacity-25 -rotate-6" alt="Decorative background pattern" loading="lazy" />This assumes you've moved the image to your own hosting and created multiple sizes for responsiveness. Adjust the paths as necessary.
To ensure the image file exists in your project, you can run:
This will search for background image files in the
public/assetsdirectory.src/components/DHBranding.tsx (1)
13-13: Verify branding and date changesThe branding has been updated from "HacksX" to "HacksXI", and the event dates have changed from "January 12-14" to "January 10-12". These changes appear to be intentional updates for the next iteration of the DeltaHacks event.
Please confirm that these updates are correct:
- The event is now "DeltaHacksXI"
- The new event dates are January 10-12
If these changes are accurate, no further action is needed. If any adjustments are required, please let me know, and I'll be happy to assist with the necessary modifications.
Also applies to: 16-16
src/components/NavBar.tsx (3)
26-26: LGTM: Event name updated correctly.The event name has been properly updated from "DeltaHacks X" to "DeltaHacks XI", which is consistent with the new event details.
28-28: LGTM: Event date updated correctly.The event date has been properly updated from "January 12-14" to "January 10-12", which aligns with the new event details.
Line range hint
26-40: Summary: NavBar component updated with new event details and improved user name display.The changes in this file are well-implemented and align with the expected updates for DeltaHacks XI:
- Event name updated to "DeltaHacks XI"
- Event date changed to "January 10-12"
- User name display enhanced with capitalization
These modifications improve the accuracy of the event information and enhance the UI. No functional changes or potential issues were introduced.
src/pages/_app.tsx (4)
54-54: LGTM: Title updated correctlyThe title has been appropriately updated to reflect the new hackathon version.
59-59: LGTM: Open Graph title updated correctlyThe Open Graph title has been appropriately updated to match the new hackathon version, ensuring consistency with the main title.
75-75: LGTM: Twitter title updated correctlyThe Twitter title has been appropriately updated to match the new hackathon version, ensuring consistency across all metadata.
Line range hint
54-75: Verify hackathon version consistency across the codebaseThe changes to update the hackathon version from "DeltaHacks X" to "DeltaHacks XI" have been correctly implemented in this file. However, it's important to ensure that this update has been consistently applied throughout the entire codebase.
To verify the consistency of the hackathon version across the codebase, you can run the following script:
This script will help identify any places where the old version might still be present and confirm that the new version has been updated consistently.
✅ Verification successful
✅ Hackathon Version Successfully Updated Across Codebase
All instances of "DeltaHacks X" have been successfully replaced with "DeltaHacks XI". No remaining references to the previous version were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any remaining instances of "DeltaHacks X" and list all occurrences of "DeltaHacks XI" echo "Searching for any remaining instances of 'DeltaHacks X':" rg -i "DeltaHacks X" --type-not svg echo -e "\nListing all occurrences of 'DeltaHacks XI':" rg -i "DeltaHacks XI" --type-not svgLength of output: 3718
src/pages/killswitch.tsx (2)
16-16: Update confirmed: DeltaHacks X to XIThe title has been correctly updated from "DeltaHacks X" to "DeltaHacks XI", reflecting the new event iteration.
Line range hint
1-85: Explain the killswitch functionalityThe purpose and functionality of this "killswitch" page are not clear from the code. Could you provide more context on when and how this page is used? This information would be helpful for future maintenance and understanding of the application flow.
src/pages/checkin.tsx (3)
35-38: LGTM: Event name updated correctly.The event name has been successfully updated from "DeltaHacks X" to "DeltaHacks XI" in the welcome message. This change is consistent with the PR objective of updating the event branding.
Line range hint
172-178: LGTM: Event name updated correctly in NoRSVP component.The event name has been successfully updated from "DeltaHacks X" to "DeltaHacks XI" in the NoRSVP component message. This change is consistent with the PR objective of updating the event branding.
Line range hint
1-265: Summary: Event branding successfully updated.All changes in this file have been reviewed and approved. The event name has been consistently updated from "DeltaHacks X" to "DeltaHacks XI" in the welcome message, NoRSVP component, and page title. These changes align with the PR objective of updating the event branding.
src/server/router/application.ts (3)
7-7: LGTM: New import added for DH11 schemaThe addition of the
dh11schemaimport is appropriate for the transition to DH11 applications.
166-172: LGTM: Status procedure updated for DH11The changes in the
statusprocedure correctly update the references from DH10 to DH11 Application. The null check forDH11Applicationis appropriate and maintains the existing error handling.
Line range hint
1-493: Overall LGTM: Successful transition to DH11 with minor improvements neededThe file has been successfully updated to handle DH11 applications instead of DH10. The changes are consistent throughout the file, with appropriate updates to procedures, error handling, and data structures.
Key points:
- The
getPrevAutofillprocedure provides a smooth transition from DH10 to DH11 applications.- The
submitDh11procedure replaces the oldsubmitDh10procedure with correct implementation.- Other procedures like
status,deleteApplication, andgetStatusCounthave been updated accordingly.Remaining tasks:
- Complete the transition in the
getStatusCountprocedure as per the TODO comment.- Remove the commented-out
submitDh10procedure.- Make minor improvements in error messages and status updates as suggested in previous comments.
Overall, the transition to DH11 applications is well-implemented with only minor refinements needed.
src/pages/scanner.tsx (2)
Line range hint
1-624: Overall assessment: Minor update with room for improvement.The main change (updating the event name in the title) has been implemented correctly. The existing functionality appears to be working as intended. However, there are opportunities to improve code organization and cleanliness:
- Consider splitting the large view components into separate files for better maintainability.
- Address the TODO comments and remove any unnecessary commented-out code.
These refactoring suggestions will help improve the overall quality and maintainability of the codebase.
508-508: Title updated to reflect the current event.The page title has been correctly updated from "Check In - DeltaHacks X" to "Check In - DeltaHacks XI". This change ensures that the title accurately represents the current event.
Let's verify if there are any other occurrences of "DeltaHacks X" in the file that might need updating:
✅ Verification successful
Title update verified successfully.
No remaining instances of "DeltaHacks X" were found in
src/pages/scanner.tsx, ensuring the title now correctly reflects "DeltaHacks XI".🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining occurrences of "DeltaHacks X" in the file rg --type typescript "DeltaHacks X" src/pages/scanner.tsxLength of output: 94
Script:
#!/bin/bash # Description: Check for any remaining occurrences of "DeltaHacks X" in src/pages/scanner.tsx without specifying file type rg "DeltaHacks X" src/pages/scanner.tsxLength of output: 89
Script:
#!/bin/bash # Description: Check for any exact occurrences of "DeltaHacks X" in src/pages/scanner.tsx rg -F "DeltaHacks X" src/pages/scanner.tsxLength of output: 92
src/pages/dashboard.tsx (2)
134-134: LGTM: Updated DeltaHacks referenceThe text has been correctly updated to reference DeltaHacks XI.
464-464: LGTM: Updated dashboard titleThe dashboard title has been correctly updated to reference DeltaHacks XI.
src/pages/apply.tsx (3)
512-516: LGTM! HackerKind field now supports multiple selectionsThe
hackerKindfield has been updated to support multiple selections, which is a good improvement. This change allows applicants to identify with multiple hacker types, providing more comprehensive information.
759-760: LGTM! Application closed message updatedThe application closed message has been appropriately updated for DeltaHacks XI. The new message clearly communicates that applications are closed and encourages potential applicants to consider next year's event.
Line range hint
1-811: Overall assessment: DeltaHacks XI application form successfully updatedThe changes made to the application form for DeltaHacks XI are comprehensive and appropriate. Key updates include:
- New long answer questions tailored for DH11.
- Updated form submission logic (
submitDh11).- Support for multiple selections in the
hackerKindfield.- Removal of the McMaster Experience Ventures Program checkbox.
- Updated application closed message.
These changes effectively transition the application process from DH10 to DH11. The suggested improvements are minor and should be easy to implement. Remember to verify the backend changes to ensure smooth integration with the updated form.
Great job on updating the application form for DeltaHacks XI!
🧰 Tools
🪛 Biome
[error] 467-467: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
prisma/schema.prisma (5)
168-224: Inconsistent Field Naming in 'DH11Application' ModelThe
DH11Applicationmodel contains fields likeDH11Reviewthat are using PascalCase, while other field names follow lowerCamelCase. To maintain consistency, consider renamingDH11Reviewtodh11Review.Additionally, there's a misspelled field
discoverdFromwhich has been previously noted.
201-201: Typo in Field Name 'discoverdFrom'As previously mentioned, the field name
discoverdFromis misspelled. Please correct it todiscoveredFrom.
192-201: Verify Array Fields with Default Empty ListsFields such as
socialText,hackerKind,workshopChoices, anddiscoverdFromare defined as arrays with a default value of empty lists. Ensure that this aligns with the application's data handling and that the frontend and backend properly handle cases where these arrays might be empty.
205-205: Ensure Compliance with Data Privacy Policies for 'underrepresented' FieldThe field
underrepresentedcollects sensitive demographic information. Please ensure that collecting, storing, and processing this data complies with relevant privacy laws and regulations, such as GDPR or HIPAA, and that users provide informed consent.
63-63: Review the Uniqueness Constraint on 'DH11ApplicationId'The field
DH11ApplicationIdin theUsermodel is marked as@unique. Confirm that each user should have at most one associatedDH11Application. If users can have multiple applications, consider removing the uniqueness constraint.
| @@ -13,13 +13,13 @@ const KillSwitch: NextPage = () => { | |||
| return ( | |||
| <> | |||
| <Head> | |||
| <title>Welcome - DeltaHacks X</title> | |||
| <title>Welcome - DeltaHacks XI</title> | |||
There was a problem hiding this comment.
Clarify the purpose of this page
There seems to be a contradiction between the updated title/header mentioning "DeltaHacks XI" and the message stating "DeltaHacks has passed away peacefully." This might be confusing for users. Please clarify the intended message and purpose of this page.
Also applies to: 22-22, 71-73
| // TODO: Use Status from DH11 Application instaed of User | ||
| const statusCount = ( | ||
| await ctx.prisma.user.groupBy({ | ||
| by: ["status"], | ||
| where: { | ||
| dH10ApplicationId: { | ||
| DH11ApplicationId: { |
There was a problem hiding this comment.
Address TODO and complete DH11 transition
The TODO comment indicates that the status should be retrieved from the DH11 Application instead of the User model. However, the implementation still uses the User model with only the DH11ApplicationId field updated.
- Remove the TODO comment once addressed.
- Update the query to use the DH11Application model for status retrieval.
Here's a suggested implementation:
-// TODO: Use Status from DH11 Application instaed of User
const statusCount = (
- await ctx.prisma.user.groupBy({
- by: ["status"],
+ await ctx.prisma.dH11Application.groupBy({
+ by: ["status"],
where: {
- DH11ApplicationId: {
- not: null,
- },
+ id: {
+ not: null,
+ },
},
_count: {
status: true,
},
})
).map((val) => {
return {
status: val.status,
count: val._count.status,
};
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // TODO: Use Status from DH11 Application instaed of User | |
| const statusCount = ( | |
| await ctx.prisma.user.groupBy({ | |
| by: ["status"], | |
| where: { | |
| dH10ApplicationId: { | |
| DH11ApplicationId: { | |
| const statusCount = ( | |
| await ctx.prisma.dH11Application.groupBy({ | |
| by: ["status"], | |
| where: { | |
| id: { | |
| not: null, | |
| }, | |
| }, | |
| _count: { | |
| status: true, | |
| }, | |
| }) | |
| ).map((val) => { | |
| return { | |
| status: val.status, | |
| count: val._count.status, | |
| }; | |
| }); |
| @@ -63,11 +63,11 @@ const Accepted: React.FC = () => { | |||
| <div> | |||
| <h1 className="text-2xl font-semibold leading-tight text-black dark:text-white sm:text-3xl lg:text-5xl 2xl:text-6xl"> | |||
| Hey {session ? session.user?.name : ""}, we can{"'"}t wait to see you at | |||
| Deltahacks X! | |||
| DeltaHacks XI! | |||
There was a problem hiding this comment.
Update event dates for DeltaHacks XI
The text has been updated to reflect DeltaHacks XI, which is great. However, the dates mentioned (January 12 - 14, 2023) seem to be incorrect, as the PR description indicates this is for DeltaHacks 11 (XI) in 2024.
Please update the dates to reflect the correct year and confirm the exact dates for DeltaHacks XI.
Also applies to: 70-72
| We are pleased to inform you that your registration for DeltaHacks XI | ||
| has been confirmed. Please look for an Attendee Package in your email | ||
| with important information about the event in the coming days. | ||
| Registration will take place at{" "} |
There was a problem hiding this comment.
Update Attendee Package link for DeltaHacks XI
The RSVPed component has been updated with more detailed information about DeltaHacks XI, which is great. However, there's an inconsistency in the Attendee Package link.
The link to the Attendee Package PDF still references DeltaHacks X:
<Link
className="w-full md:w-48"
href="/DeltaHacks_X_2024_Attendees_Package.pdf"
>
Attendee Package
</Link>Please update this link to reference the correct Attendee Package for DeltaHacks XI.
Also applies to: 338-341
| @@ -486,7 +486,7 @@ | |||
|
|
|||
| const userEntry = await prisma.user.findFirst({ | |||
| where: { id: session.user.id }, | |||
| include: { dh10application: true }, | |||
| include: { DH11Application: true }, | |||
There was a problem hiding this comment.
Verify the change in default application status
The updates to reference DH11Application instead of dh10application are consistent with the transition to DeltaHacks XI. However, there's a significant change in the default status:
The default status has been changed from "APPLIED" to "ACCEPTED":
return {
props: {
status: "ACCEPTED" as const,
killed: killed,
},
};This change might have unintended consequences. Please verify if this is the intended behavior and consider the implications of automatically setting all new applications to "ACCEPTED" status.
Also applies to: 504-504, 513-519
| @@ -177,7 +177,7 @@ const ApplyForm = ({ | |||
| mutateAsync: submitAppAsync, | |||
| isSuccess, | |||
| isError, | |||
| } = trpc.application.submitDh10.useMutation({ | |||
| } = trpc.application.submitDh11.useMutation({ | |||
There was a problem hiding this comment.
💡 Codebase verification
Missing Backend Implementation for submitDh11 Mutation
The submitDh11 mutation is used in src/pages/apply.tsx but no corresponding implementation was found in the backend. Please ensure that the backend includes the submitDh11 mutation and handles the new form data appropriately.
🔗 Analysis chain
LGTM! Form submission updated for DeltaHacks XI
The mutation for application submission has been correctly updated from submitDh10 to submitDh11. This change aligns with the new event.
To ensure the backend is ready for this change, please verify that:
- The
submitDh11mutation exists in the backend API. - The backend can handle all the new form fields, especially the new long answer questions.
You can use the following script to check for the existence of the submitDh11 mutation:
If the script doesn't find any matches, you may need to update the backend to include the new mutation.
Action Required: Re-verify the submitDh11 mutation in the backend
The previous script encountered an error due to an unrecognized file type. Please use the updated script below to check for the existence of the submitDh11 mutation:
Action Required: Re-verify the submitDh11 mutation across the entire codebase
The initial search in the server/ directory was unsuccessful because the directory does not exist. Please use the updated script below to search for the submitDh11 mutation across all TypeScript files in the repository:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for the existence of submitDh11 mutation
rg --type typescript 'submitDh11.*Mutation' server/
Length of output: 88
Script:
#
#!/bin/bash
# Check for the existence of submitDh11 mutation in .ts or .tsx files
rg 'submitDh11.*Mutation' server/ --glob '*.ts' --glob '*.tsx'
Length of output: 112
Script:
#
#!/bin/bash
# Search for the existence of submitDh11 mutation in all .ts and .tsx files
rg 'submitDh11.*Mutation' --glob '*.ts' --glob '*.tsx'
Length of output: 124
| /> | ||
|
|
||
| <FormDivider label="Survey" /> | ||
|
|
||
| <FormInput | ||
| label="What are your social media links?" | ||
| id={"socialText"} | ||
| errors={errors.socialText} | ||
| errors={errors?.socialText && errors.socialText[0]} |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Simplify error handling using optional chaining
You can simplify the error handling for socialText by using optional chaining:
- errors={errors?.socialText && errors.socialText[0]}
+ errors={errors.socialText?.[0]}This change improves readability and handles undefined cases more elegantly.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| errors={errors?.socialText && errors.socialText[0]} | |
| errors={errors.socialText?.[0]} |
🧰 Tools
🪛 Biome
[error] 467-467: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
| DH11Application DH11Application? @relation(fields: [DH11ApplicationId], references: [id]) | ||
| DH11ApplicationId String? @unique | ||
|
|
||
| DH11Review DH11Review[] |
There was a problem hiding this comment.
Inconsistent Field Naming Conventions in 'User' Model
The fields DH11Application, DH11ApplicationId, and DH11Review in the User model use PascalCase naming, which is inconsistent with the lowerCamelCase convention used elsewhere in the schema (e.g., emailVerified, typeformResponseId). To maintain consistency and improve readability, consider renaming these fields using lowerCamelCase.
Apply this diff to rename the fields:
- DH11Application DH11Application? @relation(fields: [DH11ApplicationId], references: [id])
- DH11ApplicationId String? @unique
- DH11Review DH11Review[]
+ dh11Application DH11Application? @relation(fields: [dh11ApplicationId], references: [id])
+ dh11ApplicationId String? @unique
+ dh11Review DH11Review[]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| DH11Application DH11Application? @relation(fields: [DH11ApplicationId], references: [id]) | |
| DH11ApplicationId String? @unique | |
| DH11Review DH11Review[] | |
| dh11Application DH11Application? @relation(fields: [dh11ApplicationId], references: [id]) | |
| dh11ApplicationId String? @unique | |
| dh11Review DH11Review[] |
| model DH11Review { | ||
| id String @id @default(cuid()) | ||
|
|
||
| score Float | ||
| comment String | ||
|
|
||
| reviewerId String | ||
| applicationId String | ||
|
|
||
| application DH11Application @relation(fields: [applicationId], references: [id], onDelete: NoAction) | ||
| reviewer User @relation(fields: [reviewerId], references: [id]) | ||
| } |
There was a problem hiding this comment.
Inconsistent Field Naming in 'DH11Review' Model
In the DH11Review model, the field names use PascalCase (DH11Application) whereas the convention elsewhere is lowerCamelCase. To maintain consistency, consider renaming fields to follow the lowerCamelCase convention.
Apply this diff to rename the fields:
In the `User` model:
- DH11Review DH11Review[]
+ dh11Review DH11Review[]
In the `DH11Review` model:
- application DH11Application @relation(fields: [applicationId], references: [id], onDelete: NoAction)
+ application dh11Application @relation(fields: [applicationId], references: [id], onDelete: NoAction)Committable suggestion was skipped due to low confidence.
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (2)
src/data/applicationSelectData.ts (1)
271-277: LGTM with a minor suggestion for consistency.The
orientationsconstant is well-structured and consistent with other constants in the file. It provides inclusive options for sexual orientation, including a "Prefer Not to Answer" option for privacy.Consider adjusting the capitalization of "Prefer Not to Answer" to match the other options:
- "Prefer Not to Answer", + "Prefer not to answer",src/pages/apply.tsx (1)
475-475: Simplify error handling using optional chainingYou can simplify the error handling for
socialTextby using optional chaining:- errors={errors?.socialText && errors.socialText[0]} + errors={errors.socialText?.[0]}This change improves readability and handles undefined cases more elegantly.
🧰 Tools
🪛 Biome
[error] 475-475: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- src/data/applicationSelectData.ts (2 hunks)
- src/pages/apply.tsx (22 hunks)
- src/schemas/application.ts (2 hunks)
🧰 Additional context used
🪛 Biome
src/pages/apply.tsx
[error] 475-475: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/schemas/application.ts
[error] 181-181: Avoid redundant double-negation.
It is not necessary to use double-negation when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant double-negation(lint/complexity/noExtraBooleanCast)
🔇 Additional comments (7)
src/schemas/application.ts (2)
121-122: LGTM: New enums enhance type safetyThe addition of
StatusandYesNoUnsureenums is a good practice. They provide standardized options for application status and three-state questions, enhancing type safety and consistency throughout the application.
124-207: Overall assessment of schema changesThe new
dh11schemaintroduces several improvements and changes:
- More specific long-answer questions
- Flexibility in fields like
hackerKindandworkshopChoices- Addition of new fields like
dietaryRestrictionsandunderrepresented- Changes in demographic data collection (
gender,race,orientation)While these changes allow for more diverse responses, some have removed important validations. It's crucial to balance flexibility with data integrity and consistency. Consider implementing the suggested validations and refactors to ensure data quality while maintaining the improved flexibility of the new schema.
Additionally, thorough testing of the new schema is recommended to ensure it meets all the application requirements and maintains backwards compatibility where necessary.
🧰 Tools
🪛 Biome
[error] 181-181: Avoid redundant double-negation.
It is not necessary to use double-negation when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant double-negation(lint/complexity/noExtraBooleanCast)
src/data/applicationSelectData.ts (1)
Line range hint
271-297: Overall assessment: Good additions with minor improvements needed.The new constants
orientationsandrepresentation(after fixing the typo) are valuable additions to the application's data selection options. They follow the general structure of the file and provide important information for user profiles.The suggested improvements will ensure consistency across the file and prevent potential bugs or confusion that could arise from the typo. Once these minor issues are addressed, the changes will be fully aligned with the existing codebase structure and naming conventions.
src/pages/apply.tsx (4)
38-39: LGTM! Imports updated for DeltaHacks XIThe imports have been correctly updated to include new data structures for orientations and representation, which aligns with the transition to DeltaHacks XI.
431-467: LGTM! Long answer questions updated for DeltaHacks XIThe long answer questions have been appropriately updated for DeltaHacks XI. The new questions cover a range of topics including teamwork, goals, personal interests, and hypothetical scenarios, which should provide a well-rounded view of applicants.
Line range hint
588-662: LGTM! New fields added for diversity and inclusionNew fields for underrepresented groups and orientation have been added to the form. This is a positive change that promotes diversity and inclusion in the event.
182-182: Verify backend updates for DeltaHacks XIThe frontend has been updated to use
submitDh11mutation and queryDH11Application. Please ensure that corresponding changes have been made in the backend:
- The
submitDh11mutation is implemented in the backend API.- The
DH11Applicationtable or model exists in the database schema.Also applies to: 844-844
✅ Verification successful
Backend updates for DeltaHacks XI are verified
The
submitDh11mutation is implemented in the backend API, and theDH11Applicationmodel exists in the database schema.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for the existence of submitDh11 mutation and DH11Application model rg 'submitDh11|DH11Application' --type typescriptLength of output: 86
Script:
#!/bin/bash # Check for the existence of submitDh11 mutation and DH11Application model with correct file types rg 'submitDh11|DH11Application' --type ts --type tsxLength of output: 82
Script:
#!/bin/bash # Check for the existence of submitDh11 mutation and DH11Application model in .ts and .tsx files rg 'submitDh11|DH11Application' --glob '**/*.ts' --glob '**/*.tsx'Length of output: 1112
| birthday: z.coerce.date().refine( | ||
| (date) => { | ||
| const now = new Date(); | ||
| const diff = now.getTime() - date.getTime(); | ||
| const age = Math.floor(diff / (1000 * 60 * 60 * 24 * 365.25)); | ||
| return age >= 13; | ||
| }, | ||
| { | ||
| message: "You must be at least 13 years old", | ||
| } | ||
| ), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider optimizing the age calculation logic
The current age calculation method might not be the most accurate due to its simplification of year length. Consider using a more precise calculation method or a dedicated library like date-fns for accurate age determination.
Here's an example of a more accurate calculation:
const age = now.getFullYear() - date.getFullYear();
const m = now.getMonth() - date.getMonth();
if (m < 0 || (m === 0 && now.getDate() < date.getDate())) {
age--;
}
return age >= 13;This method accounts for the exact birth date, providing more accurate results.
| longAnswerIncident: z | ||
| .string() | ||
| .min(1, "An answer is required for this question") | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), | ||
| longAnswerGoals: z | ||
| .string() | ||
| .min(1, "An answer is required for this question") | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), | ||
| longAnswerFood: z | ||
| .string() | ||
| .min(1, "An answer is required for this question") | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), | ||
| longAnswerTravel: z | ||
| .string() | ||
| .min(1, "An answer is required for this question") | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), | ||
| longAnswerSocratica: z | ||
| .string() | ||
| .min(1, "An answer is required for this question") | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Refactor duplicate validation logic for long answer fields
All long answer fields (longAnswerIncident, longAnswerGoals, longAnswerFood, longAnswerTravel, longAnswerSocratica) have identical validation logic. To improve maintainability and reduce code duplication, consider creating a reusable schema for long answers.
Here's a suggested refactor:
const longAnswerSchema = z
.string()
.min(1, "An answer is required for this question")
.refine((value) => value.split(/\s/g).length <= 150, {
message: "Must be less than 150 words",
});
// Then in your schema:
longAnswerIncident: longAnswerSchema,
longAnswerGoals: longAnswerSchema,
longAnswerFood: longAnswerSchema,
longAnswerTravel: longAnswerSchema,
longAnswerSocratica: longAnswerSchema,This approach centralizes the validation logic, making it easier to maintain and update in the future.
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }), | ||
| socialText: z.array(z.string()).default([]), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding validation for socialText entries
The socialText field has been changed to an array of strings without any validation. To ensure data integrity and consistency, consider adding validation for each entry in the array. For example, if these are meant to be social media links:
socialText: z.array(z.string().url()).default([]),Or if they should follow a specific pattern:
socialText: z.array(z.string().regex(/^@[\w]+$/)).default([]),This will help maintain data quality and prevent potential issues with invalid entries.
src/schemas/application.ts
Outdated
| .nullish(), | ||
| linkToResume: z.string().url().nullish(), | ||
| tshirtSize: z.enum(["XS", "S", "M", "L", "XL"]), | ||
| hackerKind: z.array(z.string()).default([]), |
There was a problem hiding this comment.
Reintroduce validation for hackerKind and workshopChoices
The hackerKind and workshopChoices fields have been changed from enums to arrays of strings without validation. This removes the type safety and data validation present in the previous schema. To maintain data integrity and prevent invalid inputs, consider using an array of enums:
hackerKind: z.array(z.enum([
"Front-end",
"Back-end",
"Design",
"iOS Development",
"Android Development",
"Hardware",
"Machine Learning",
"Graphics Programming",
"Data Analysis",
"Game Development",
"Writer",
"Product Manager",
"Other",
])).default([]),
workshopChoices: z.array(z.enum([
"React/Vue.js",
"Blockchain",
"Machine Learning",
"Android Development",
"iOS Development",
"Web Development",
"Intro to AR/VR",
"Game Development",
"Interview Prep",
"Intro to UI/UX Design",
"Hardware Hacking",
"Computer Vision with OpenCV",
])).default([]),This approach maintains flexibility while ensuring only valid options are accepted.
Also applies to: 187-187
| gender: z.string(), | ||
| race: z.string(), | ||
| orientation: z.string(), |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding validation for demographic fields
The gender, race, and orientation fields have been changed to unconstrained string types. While this allows for more flexibility, it may lead to inconsistent data and complicate analysis. Consider reintroducing some form of validation:
For gender, you might want to keep an enum with common options and an "Other" field:
gender: z.union([
z.enum(["Man", "Woman", "Non-binary", "Prefer not to say"]),
z.string().refine(val => val.toLowerCase() === 'other', {
message: 'If not selecting a predefined option, please enter "Other"'
})
]),For race and orientation, consider using a predefined list of options with the ability to add custom entries:
race: z.union([
z.enum(["Asian", "Black", "Hispanic", "White", "Mixed", "Other"]),
z.string().min(1, "Please specify your race")
]),
orientation: z.union([
z.enum(["Heterosexual", "Homosexual", "Bisexual", "Pansexual", "Asexual", "Other"]),
z.string().min(1, "Please specify your orientation")
]),These approaches balance flexibility with data consistency, facilitating easier analysis while still allowing for diverse responses.
| interests: z | ||
| .string() | ||
| .refine((value) => value.split(/\s/g).length <= 150, { | ||
| message: "Must be less than 150 words", | ||
| }) | ||
| .transform((string) => (!!string ? string : null)) | ||
| .nullish(), |
There was a problem hiding this comment.
Remove redundant double-negation in interests transform
The transform function for the interests field contains a redundant double-negation. This can be simplified without changing the logic:
interests: z
.string()
.refine((value) => value.split(/\s/g).length <= 150, {
message: "Must be less than 150 words",
})
- .transform((string) => (!!string ? string : null))
+ .transform((string) => (string ? string : null))
.nullish(),This change maintains the same functionality while improving code clarity.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| interests: z | |
| .string() | |
| .refine((value) => value.split(/\s/g).length <= 150, { | |
| message: "Must be less than 150 words", | |
| }) | |
| .transform((string) => (!!string ? string : null)) | |
| .nullish(), | |
| interests: z | |
| .string() | |
| .refine((value) => value.split(/\s/g).length <= 150, { | |
| message: "Must be less than 150 words", | |
| }) | |
| .transform((string) => (string ? string : null)) | |
| .nullish(), |
🧰 Tools
🪛 Biome
[error] 181-181: Avoid redundant double-negation.
It is not necessary to use double-negation when a value will already be coerced to a boolean.
Unsafe fix: Remove redundant double-negation(lint/complexity/noExtraBooleanCast)
src/data/applicationSelectData.ts
Outdated
| orientations, | ||
| represenation, |
There was a problem hiding this comment.
Update export statement to use correct constant name.
The export statement includes the new constants, but it carries over the typo in "represenation".
Please update the export statement to use the correct constant name:
export {
// ... other exports
orientations,
- represenation,
+ representation,
};This change ensures consistency with the corrected constant name suggested in the previous comment.
Committable suggestion was skipped due to low confidence.
src/data/applicationSelectData.ts
Outdated
| const represenation: SelectChoice[] = [ | ||
| { value: "YES", label: "Yes" }, | ||
| { value: "NO", label: "No" }, | ||
| { value: "UNSURE", label: "Unsure" }, | ||
| ]; |
There was a problem hiding this comment.
Fix typo and adjust structure for consistency.
There are several issues with the represenation constant:
- There's a typo in the constant name: "represenation" should be "representation".
- The structure is inconsistent with other constants in the file.
- The use of uppercase values is inconsistent with other constants.
Please apply the following changes:
-const represenation: SelectChoice[] = [
- { value: "YES", label: "Yes" },
- { value: "NO", label: "No" },
- { value: "UNSURE", label: "Unsure" },
-];
+const representation: SelectChoice[] = [
+ "Yes",
+ "No",
+ "Unsure",
+].map((v) => ({ value: v, label: v }));This change aligns the representation constant with the structure and naming conventions used throughout the file.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const represenation: SelectChoice[] = [ | |
| { value: "YES", label: "Yes" }, | |
| { value: "NO", label: "No" }, | |
| { value: "UNSURE", label: "Unsure" }, | |
| ]; | |
| const representation: SelectChoice[] = [ | |
| "Yes", | |
| "No", | |
| "Unsure", | |
| ].map((v) => ({ value: v, label: v })); |
| Applications are closed for DeltaHacks XI. If you did not | ||
| get to apply, we hope to see you next year! |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider making the applications closed message configurable
The message for closed applications is currently hardcoded. Consider making this message configurable, perhaps by storing it in the database or a configuration file. This would allow for easier updates in future events without requiring code changes.
Would you like me to propose a solution for making this message configurable?
* feat: updated schedule for DH10 (#179) * chore: setup using google api * chore: use google api * feat: make calendar work * feat: add schedule button --------- Co-authored-by: Arian Ahmadinejad <35879206+arian81@users.noreply.github.com> Co-authored-by: Arian Ahmadinejad <ahmadinejadarian@gmail.com> * chore: hide logout on schedule * chore: add caching * chore: add attendee package button * feat: add event locations to schedule (#182) * decoupled a lot of functionality in schedule.tsx * fixed getDefaultCurrentDate refactor * cleaned up schedule.tsx from merge * added location to the description * removed console.logs * added location to subheading of events * doing some cleanup * removed removeResourceLabel since description is now unviewable * removed removeResourceLabel since description is now unviewable * making pop viewable again because it needs to be * support 5 colour option * fixing tooltip * fix: disable pop up * added circles in agenda view --------- Co-authored-by: Rachelle DeMan <demanr@mcmaster.ca> Co-authored-by: Krish <krish120003@gmail.com> Co-authored-by: Arian Ahmadinejad <ahmadinejadarian@gmail.com> * fix: schedule login hot fix * fix: hotfix update z indexing on mobile, add sign in button * fix: uncomment out appointmentTooltipRender (#184) * decoupled a lot of functionality in schedule.tsx * fixed getDefaultCurrentDate refactor * cleaned up schedule.tsx from merge * added location to the description * removed console.logs * added location to subheading of events * doing some cleanup * removed removeResourceLabel since description is now unviewable * removed removeResourceLabel since description is now unviewable * making pop viewable again because it needs to be * support 5 colour option * fixing tooltip * fix: disable pop up * added circles in agenda view * uncommented out tooltip render --------- Co-authored-by: Rachelle DeMan <demanr@mcmaster.ca> Co-authored-by: Krish <krish120003@gmail.com> Co-authored-by: Arian Ahmadinejad <ahmadinejadarian@gmail.com> * feat: Create LICENSE * chore: cleanup old components (#187) Remove Google Analytics, Logrocket and unused files. Also mark routers for deprecation. * feat: add posthog * refactor: make drawer component (#189) * created Drawer component * decoupled Drawer out of welcome page * decoupled Drawer out of dashboard, grade, me, and scanner pages * change ApplicationTable button text from View Application to View * remove unused files * cleaning up file dependencies * removed navigation file * feat: DH11 Applications (#196) * feat: DH11 application and review tables * fix: update logsnag project * feat: add user to dh11 applications * feat: use DH11 Applications * fix: update routes to refer to dh11 * feat: prisma db migration * fix: remove broken migrationi * feat: change from DH10 to DH11 everywhere * fix: form is submittable * fix: improve errors * fix: don't refetch autofill * fix: more better errors for form * fix: typos * fix: add better errors * fix: more typos * fix: custom socials form handling (#198) * refactor: rearrage files * feat: add react icons * fix: imports * feat: fixes to form, review endpoint and ui update * fix: imports * fix: update routing and style consistency for dh11 (#199) * fix: disable outdated pages * fix: update routing to use DH11 status, capitalize name * fix: update modal styling * fix: readable dark button text color * feat: use same button as dashboard * feat: match dark and light primary colors * fix: restore original background * fix: match text styling with dashboard * fix: routing TS errors * feat: create prisma migration (#200) * fix: MLH form fields and resume are optional, change form persist key for DH11 (#201) * feat: update socials and info about DH11 (#202) * fix: update DH11 socials * fix: update hackathon length * fix: improve UX with link behavior, spelling, education labels and word count (#203) * fix: open links in new tab * fix: spelling of lookout * fix: add optional to education labels * fix: make word count ux better * fix: show word count on grading page instead of words left --------- Co-authored-by: Krish <krish120003@gmail.com> * feat: add resume upload (#204) * feat: DH11 application and review tables * fix: update logsnag project * feat: add user to dh11 applications * feat: use DH11 Applications * fix: update routes to refer to dh11 * feat: prisma db migration * feat: backend for uppy signed url upload * fix: remove unnecessary validation, store at root * fix: cleanup packages * feat: basic upload component * feat: add endpoint for getting resume files * feat: handle uppy upload responses * fix: handle empty string dates * feat: connect uppy to react form * fix: prettier formatting * fix: add missing types * fix: make form mobile friendly again * fix: remove migration * fix: add missing libraries --------- Co-authored-by: Krish120003 <krish120003@gmail.com> * fix: posthog rewrite using netlify * feat: add posthog submission tracking * feat: use netlify redirects for posthog, add identification and apply event capture (#205) * feat: add posthog identify * fix: upgrade posthog * fix: pnpm lock * fix: use posthog suggested event naming * fix: add missing space * feat: add logsnag track for dh11 application * fix: correct host * fix: add posthog on server * fix: use component to identify in posthog * fix: use consistent id --------- Co-authored-by: Arian Ahmadinejad <ahmadinejadarian@gmail.com> --------- Co-authored-by: Krish <krish120003@gmail.com> Co-authored-by: Felix Fong <fongf2@mcmaster.ca> Co-authored-by: Rachelle DeMan <demanr@mcmaster.ca>
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
Refactor