Enforce Submission Requirements (`requireGithub`, `requireDemoVideo`, etc.)

[Benjtalkshow]

Enforce Submission Requirements (requireGithub, requireDemoVideo, etc.)

Objective

Dynamically adjust the SubmissionForm validation rules based on the hackathon's specific submission configuration. Required fields must be enforced at both the schema level and the UI level — validation must be conditional and data-driven, not hardcoded. Users should always have a clear, upfront visual signal that a field is required before they attempt to submit.

---

Technical Implementation

Target File

• components/hackathons/submissions/SubmissionForm.tsx

Hook

• Use useHackathonData() from @/lib/providers/hackathonProvider to access currentHackathon submission settings
• All boolean requirement flags (requireGithub, requireDemoVideo, etc.) must be read directly from the hackathon context — never hardcoded or assumed

Logic Mapping

Schema Validation — submissionSchema (Zod)

• Modify submissionSchema to conditionally enforce required fields based on the hackathon's requirement flags
• If requireGithub is true, the schema must treat the absence of a GitHub link in the links array as a validation failure — the error should be surfaced at the links field level, not as a generic form error
• If requireDemoVideo is true, the schema must enforce that videoUrl is a non-empty, valid URL
• Where Zod's static schema cannot cleanly express the conditional logic (e.g., checking for a specific link type within an array), inject validation errors manually using form.setError() in the appropriate step handler rather than contorting the schema
• The validation approach — schema-level vs. manual injection — should be chosen based on what produces the cleanest, most maintainable code for each field

Step Validation — handleNext (Step 2)

• In handleNext at Step 2, before allowing progression, explicitly check currentHackathon.requireGithub
• If true and no GitHub link is present in form.watch('links'), block progression and inject a clear, field-level validation error directing the user to add their GitHub repository link
• Apply the same pattern for any other require* flags that gate step progression

Form Submission — onSubmit

• Perform a final validation pass in onSubmit that re-checks all require* flags against the current form values before the submission payload is constructed and dispatched
• This acts as the last line of defense — if a user somehow bypasses step-level validation, onSubmit must catch it before any API call is made
• Validation errors caught at this stage must be surfaced as field-level errors, not silent failures

UI — Required Field Indicators

• Dynamically append an asterisk (*) to the label of any FormField whose corresponding require* flag is true
• Affected fields include at minimum: videoUrl (when requireDemoVideo is true) and the GitHub entry in the links section (when requireGithub is true)
• The * must be driven by the flag values from useHackathonData() — it must not be hardcoded on the label
• Include a brief legend or helper text near the form (e.g., "* Required for this hackathon") so users understand what the asterisk means without ambiguity
• Required field indicators must be visible before the user attempts to submit — they are a proactive signal, not a post-submission error state

---

⚠️ Caution

This is a production environment — not a sandbox.

• Code must be performant, accessible, and clean
• No dummy data — all require* flags must be sourced from useHackathonData(); never hardcode which fields are required
• AI-generated code will be scrutinized; poorly structured or "hallucinated" code will result in immediate issue closure
• Follow the existing design system: shadcn/ui, Tailwind, Framer Motion
• Strictly no any types in schema definitions or validation logic

---

Testing & Verification

Automated Tests

npm run lint    # Ensure code quality
npm run build   # Verify no breaking changes in routing or types

Manual Verification

• Set requireGithub: true and attempt to proceed at Step 2 without a GitHub link — confirm progression is blocked with a clear, field-level validation error on the links field
• Set requireGithub: true and add a valid GitHub link — confirm progression is allowed and no erroneous validation error is shown
• Set requireDemoVideo: true and attempt to submit without a videoUrl — confirm the field fails validation with a clear, actionable error message
• Set requireDemoVideo: false — confirm videoUrl is not required and the form submits successfully without it
• Verify the asterisk (*) appears on videoUrl label when requireDemoVideo is true and is absent when false
• Verify the asterisk (*) appears on the GitHub link label when requireGithub is true and is absent when false
• Attempt to bypass step-level validation and submit directly — confirm onSubmit catches and blocks the submission with appropriate field errors
• Confirm all validation errors are surfaced as field-level errors, not generic form-level alerts
• Test with all require* flags set to false — confirm no fields are marked required and the form submits successfully with only the base required fields
• Confirm no TypeScript any types are present in the schema or validation logic
• Provide video evidence

[linear]

BOU-115

[coderabbitai]

🔗 Related PRs

#376 - Fix hackathon [merged]
#380 - Feat/minor ux fixes [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Anuoluwapo25]

Hi maintainer, I'd like to take on this issue as i'll fully implement what is requested as i'm a fullstack web3 developer with experiences.

[Samuel1505]

I would like to work on this issue, kindly assign me

[Jopsan-gm]

Hello maintainers 👋

I’ve reviewed this issue and the relevant parts of the codebase. I’m a junior full-stack developer with hands-on experience contributing to real-world open source projects across both Web2 and Web3 contexts. My work includes JavaScript/TypeScript-based stacks, React on the frontend, Node.js on the backend, as well as contributing to blockchain-related repositories, including smart contract logic and protocol-level features.

I’m comfortable reading and understanding existing codebases, reasoning about on-chain and off-chain interactions, and delivering clean, focused implementations aligned with the project’s conventions. I’m used to working through GitHub workflows, iterating based on feedback, and prioritizing maintainability and clarity.

This issue aligns well with my experience, and I believe I can provide a solid and reliable solution. If it’s still available, I’d be happy to take it.

[KevinMB0220]

Hi, I’m Kevin a full-stack and smart contract engineer building on Stellar. I specialize in designing and shipping scalable, secure systems end-to-end, from Soroban smart contracts to production-ready backend infrastructure and user-facing applications.

I’ve worked on complex architectures involving automated agents, cross-chain logic, and data indexing, focusing on reliability, performance, and clean standards. My approach is very product-driven: I don’t just build contracts, I build complete systems that solve real user problems and can scale in production.

I’m especially interested in infrastructure, security, and automation creating tools and frameworks that make it easier for other developers to build safely and efficiently on Stellar.

[DioChuks]

I have experience with React & can dynamically adjust the SubmissionForm validation rules based on the hackathon's specific submission configuration. Required fields will be enforced at both the schema level and the UI level, validation will be conditional and data-driven, not hardcoded. Users would always have a clear, upfront visual signal that a field is required before they attempt to submit.