Over the past two weeks, I migrated specific parts of the Bloom After platform from vanilla HTML and JavaScript to Next.js. This included the clinic, NGO, and directory components, as well as the moderation pages for clinics and specialists. It took some problem solving, but the codebase is now much cleaner and easier to maintain. Here is a rundown of what I did.
Migrating Clinic, NGO, and Directory Components
Outside of the moderation pages, I migrated the directory, clinic, and NGO components to Next.js. I restructured these components to work efficiently within the React ecosystem and implemented image optimization to improve page load times.
Reusing Components
For the moderation queue, the old Clinic and Specialist edit pages were basically the same but written in two separate HTML files. If a button needed a change, it had to be updated in multiple places. To fix this, I created a single React component called SubmissionEditRenderer. Now, by passing a type="clinic" or type="specialist" prop, the component automatically knows whether to show a website link or a consultation mode. This cut down the code a lot and will make it much easier to add new directory categories later.
Fixing the TypeScript Errors
The old data had a mix of snake_case and camelCase properties, which can easily cause bugs. I set up strict TypeScript interfaces (AdminSubmissionItem and AdminAPiResponse) to map out the nested objects properly. I also updated the types so the frontend knows exactly what kind of data to expect from the backend. This cleared out all the any warnings in ESLint.
Handling API Errors
There were some environment issues where live API calls were failing. This left me with a blank screen or error state while I was trying to build the UI. To keep moving, I set up the error boundaries to use fallback mock data (like Grace Medical Centre and Dr. Funmi Adeyemi). If the API fetch fails, the app catches the error, logs it to the console for debugging, and shows the mock data instead. This way, I could keep working on the layouts and buttons without being blocked by backend configuration issues.
Moving from Netlify to Vercel
The project ran into deployment issues with Netlify, mostly around API routes, missing environment variables, and CORS errors. Because of this, the engineering lead made the decision to move the deployment to Vercel. Once that switch was made, the build process was much smoother and the Next.js routing worked exactly as expected.
Conclusion
Overall, these updates make the platform much more stable. The code is strictly typed and easier to read, there are fewer bugs to worry about and adding new features to these components in the future will take a lot less time.
Top comments (0)