West Midlands | 26 March SDC | Iswat Bello | Sprint 1 | Purple Forest/New Feature/Unfollow

[Iswanna]

Learners, PR Template

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

This PR enables users to un-follow accounts they are no longer interested in. This required a "Reverse Path" implementation in the database and a dynamic UI update on the profile page.

Key Changes:

• Backend Data: Created the unfollow function in data/follows.py using SQL DELETE logic with parameterized queries to prevent SQL injection.
• Backend API: Added a POST /unfollow/<target_username> endpoint. This matches the existing Frontend contract while maintaining security via @jwt_required.
• Frontend UI:
  • Updated the createProfile component to keep the follow button visible when is_following is true.
  • Implemented a text toggle to switch the button label between "Follow" and "Un-follow" based on user state.
  • Modified the handleFollow event handler to act as a "Smart Switch," calling either the follow or unfollow API depending on the current button state.

[nedssoft]

Iswat — this is a really clean, well-executed feature. What stands out most is how neatly your do_unfollow mirrors the existing do_follow: the same get_user lookup, the same None → 404 guard, @jwt_required on the door, and a properly parameterized DELETE targeting both follower and followee so you only remove the one relationship. That instinct to match the patterns already in the codebase is exactly what makes legacy work go smoothly. Your CHANGES-MADE.md write-up is a pleasure to read, too.

I've left one entirely optional question inline — a design thing to mull over, not a fix. You've met the task cleanly, so I'm marking this Complete. Lovely work. 🎉

[nedssoft]

Your "Smart Switch" works, and I like that you found a single handler for both directions. One thing to chew on — no change needed here, just a thought for future you: the handler decides which API to call by reading the button's visible text, button.textContent === "Un-follow". That quietly ties your logic to whatever the label happens to say. What do you think would happen to this if if someone later renamed the button to "Unfollow" (no hyphen), translated the page, or dropped an icon inside the button?

You already hold the real answer to "am I following this person?" in your data — profileData.is_following. Is there a way you could branch on that state instead of the on-screen wording? Something to explore when you're curious, not to change for this PR.

[Iswanna]

Thanks for the feedback. In the future, I'll try to use the data state (like a data-following attribute) to drive the logic so the frontend logic doesn't have to rely on what the UI is showing. Thanks for the suggestion.

[Iswanna]

Iswat — this is a really clean, well-executed feature. What stands out most is how neatly your do_unfollow mirrors the existing do_follow: the same get_user lookup, the same None → 404 guard, @jwt_required on the door, and a properly parameterized DELETE targeting both follower and followee so you only remove the one relationship. That instinct to match the patterns already in the codebase is exactly what makes legacy work go smoothly. Your CHANGES-MADE.md write-up is a pleasure to read, too.

I've left one entirely optional question inline — a design thing to mull over, not a fix. You've met the task cleanly, so I'm marking this Complete. Lovely work. 🎉

Thank you so much @nedssoft, for the review and for marking the task as complete! I made a conscious effort to mirror the existing do_follow pattern to ensure the codebase stays consistent and easy to maintain.

I will read the inline question to think about the suggested edge case.