Yesterday was read-only; browsing and viewing. Today was the write side. Users can now create projects, edit their own, delete them, and send collaboration requests. The platform went from a read-only directory to an interactive two-sided system in one day of building.
The Reusable ProjectForm Component
Before building the create and edit pages, I built ProjectForm, a single form component used by both. The create page uses it empty. The edit page uses it pre-filled with existing project data. Writing the form once and reusing it in two places means any change to the form, adding a field, changing validation, or updating styling, happens in one file, and both pages get it automatically.
The form has six fields: title, description, tech stack, roles needed, a status dropdown, and an is_open toggle. Tech stack and roles needed are plain text inputs where the user types comma-separated values, the same format the Django API expects and stores. Simple, no tag input library needed.
The form component accepts two props: initialValues for pre-filling in the edit case, and onSubmit, which is called with the form data when the user submits. The component handles its own field state and validation, checking required fields before calling onSubmit. Error messages appear below each field that fails validation.
The onSubmit prop pattern is the key architectural decision here. The form component doesn't know whether it's creating or editing. It just collects data and hands it to whoever is using it. The create page passes a function that calls the create API. The edit page passes a function that calls the update API. Same form, different behavior depending on which page uses it.
Create Project Page
The create project page is a protected page, ProtectedRoute wraps it, so unauthenticated users get redirected to login. It renders the ProjectForm with no initial values and an onSubmit handler that calls createProject from the projects service.
On successful creation, the API returns the new project object, including its ID. The page uses that ID to redirect to /projects/[id], the detail page of the just-created project. The user sees their new project immediately after creating it, which provides clear confirmation that the action worked.
Error handling on the create page covers two cases: network errors and validation errors from Django. If Django returns a 400 with field-specific errors. For example, if the title is too long, those errors are passed back to the form component and displayed under the relevant fields. If it's a general network error, a top-level error message is shown.
Edit Project Page
The edit page is more complex than the create page because it needs to fetch the existing project before rendering the form. It also needs to verify that the current user is actually the owner. If someone navigates directly to /projects/[id]/edit and they're not the owner, they should be redirected away rather than seeing a form they can't legitimately use.
The page fetches the project on the mount. If the fetch fails or the project doesn't exist, it shows an error. If the project exists but the current user is not the owner, compared by username since that's what the API returns, the page redirects to the project's detail page.
Once the ownership check passes, the form renders pre-filled with the existing project data. The initialValues prop receives the project fields mapped to the form field names. On submission, the page calls updateProject with a PATCH request, only sending the fields that were actually changed. The Django API handles partial updates correctly because the endpoint accepts PATCH.
On success, the page redirects to the project detail page. The detail page immediately shows the updated data because it fetches fresh data on mount.
Delete Project
Delete was partially wired up on the detail page yesterday; the button existed, but the flow wasn't complete. Today I finished it properly.
The delete flow uses a confirmation dialog, window.confirm for now, a proper modal in the polish phase. If the user confirms, the page calls deleteProject, shows a loading state on the button, and redirects to /dashboard on success. If the delete fails, the error is displayed, and the button returns to its normal state.
The redirect goes to the dashboard rather than the project list because the deleted project no longer exists. Redirecting to the list would show the list without the deleted project, which is fine, but the dashboard is more useful; the user can see their remaining projects immediately.
The Collaboration Request Flow
The apply page is the final piece of the user journey that makes DevCollab a platform rather than just a directory. A developer finds a project they want to join, clicks "Request to Collaborate", writes a message, and submits.
The apply page is protected. It fetches the project on the mount to display the project summary alongside the form, so the user can see what they're applying for while writing their message. This context matters: a message written knowing the project details is more relevant than one written blindly.
The form has a single field message with a character minimum. An empty or one-line message shouldn't be submittable because it's not useful to the project owner. The character minimum encourages genuine applications.
On submission, the page calls sendRequest from the requests service. Two error cases are handled explicitly. If the API returns a 400 saying the user has already sent a request, which can happen if someone navigates directly to the apply URL after already applying, the page shows a message and redirects back to the detail page. If the project is not accepting requests, is_open is false, the apply page redirects back to the detail page with a message.
On success, the page redirects to the project detail page. The detail page now shows the request status badge 'pending' because the request_status field in the API response reflects the newly created request. The "Request to Collaborate" button is gone, replaced by the pending badge. The user gets immediate visual confirmation that their request was sent.
Connecting the Write and Read Sides
Today's work closed the loop between the two sides of the platform. The complete user journey now works end to end:
User A registers, completes their profile, and creates a project. The project appears on the browse page. User B registers, browses, finds the project, reads the detail page, clicks apply, writes a message, and submits. User B's detail page now shows "Request Pending". User A goes to their dashboard and sees the incoming request. User A goes to Postman or tomorrow, the dashboard to accept or reject.
The only piece missing is the frontend for request management on the owner's side, that's the dashboard.
Where Things Stand After Day 93
The write side of the frontend is complete. Create, edit, delete, and apply all work with real data. The reusable ProjectForm keeps the form logic in one place. The apply flow handles edge cases, duplicate requests, and closed projects gracefully.
Tomorrow: dashboard page showing the user's projects and incoming requests, public profile page, edit profile page, and the sent requests page.