Posted on Jun 27

Building Ekehi: My Week in Reviews and a New Submissions Page

#webdev #react #frontend #devjournal

Week ending 27 June 2026 · Ekehi frontend (React + TanStack Router)

This week split into two halves: reviewing four teammates' pull requests so the resources section of the app could land cleanly, and shipping my own issue, the Submissions page. Here is what went into both.

Reviewing four PRs

Most of the team was finishing the detail-page work for the resources section, so a big part of my week was reading other people's code and helping it get to merge.

#163 — Build template detail page (MarionBraide). Merged.
#162 — Build guide detail page (Fhave). Merged.
#161 — Add training detail page (first-afk). Merged.
#156 — New Contributors page with responsive layout (first-afk). Merged.

Reviewing this many pages back to back was useful in a way I did not expect. The three detail pages (guide, training, template) all solve the same shape of problem: fetch one record by id, then render loading, error, and empty states around it. Seeing three takes on the same pattern made the house conventions obvious, the feature/*.types.ts plus *.service.ts plus *.query.ts split, the makeRequest wrapper, and the ApiError handling. I leaned on exactly those patterns a day later when I built my own page, which is the whole point of reviewing widely before you write.

What I focused on in reviews: consistent loading and error states, no stray fetch or localStorage calls (we route everything through the shared API layer), and accessible markup. The contributors page (#156) was the odd one out, more layout and responsiveness than data, so there the attention went to how it held up across breakpoints.

Shipping issue #148: the Submissions page

My own issue this week was #148 — Build the Submissions page, which closed today.

What I built:

A three-section form (About the opportunity, Programme details, About the organizer) that mirrors the legacy submission flow.
A data layer that fits the existing conventions: zod types, a service built on makeRequest, a useMetaQuery for the dropdown and checkbox options (gated on the access token), and a useCreateOpportunityMutation that posts to /opportunities. The submission is stored as pending for the team to review.
Loading, error, and success states, plus client-side validation that matches the old form's rules. Empty optional fields are dropped from the payload so the server's email and URL checks never receive blank strings.
Six tests covering loading, the meta error, the rendered form, required-field validation, the submitted payload, and the server-error path.

I also styled the form to match the Figma: a single rounded card with dividers between sections and softened fields, instead of three separate boxes.

A bug I caught along the way

While testing the page I noticed the navbar was invisible on every page except the home page. It was hard-wired for the dark hero on the landing page: white text, white logo, and an absolute overlay. On a white background it simply vanished.

I made the navbar theme-aware. On the home page it keeps the transparent, white treatment over the hero. On every other page it now renders as a solid bar with a dark logo, dark links, a purple active state, and a filled Sign-up button, and it takes up real layout space so it no longer floats over the content. That meant updating the navbar's existing tests to account for the new route-aware logic.

Also fixed: issue #157

Earlier in the week I closed #157 — Contributors page card-background SVGs fail to render on the production build. The cards looked fine in development but lost their background SVGs once built and deployed, the classic case of an asset that resolves under the dev server but not after the production bundle. I tracked down how those SVGs were referenced and fixed it so they render in the built output, not just locally. A reminder that "works in dev" is not the same as "works in the build," and that the production bundle is the only source of truth that matters.