Flicktionary React frontend - A dictionary for flicks.

The Challenge

The course provided a RESTful movie API (which I had also built as a separate project) and asked for a modern client-side app that could:

• let users browse a catalog of movies,
• show rich details like genres, directors and descriptions,
• support registration, login and profile updates,
• and allow users to manage a list of favorite movies.

The challenge on the client side was to turn this into a cohesive, snappy SPA: screens that feel like a native app, clear navigation, and an interface that stays responsive even as more data and views are added.

At the same time, I wanted the codebase to be maintainable: a clear folder structure, small reusable components, and patterns that would scale if the project grew.

Objectives and Success Criteria

I translated the brief into a few concrete goals:

• Smooth movie browsing
  Provide a responsive movie grid with posters and titles, plus intuitive navigation to detailed views.

• Full auth flow on the client
  Implement registration and login, handle API tokens and protect user-only views (favorites, profile).

• Useful search & filtering
  Allow users to search by title and filter by metadata (such as genre or director) so large catalogs stay manageable.

• Favorites as a true feature, not a demo
  Let users add/remove favorites and see those changes reflected both in the UI and in the API.

• Deployed SPA
  Ship a production build of the React app and connect it to the live API.

I considered the project successful if someone could land on the app, register, explore a few films, favorite some of them and come back later to find their watchlist exactly as they left it.

• Routing & views:
  React Router handles navigation between the main views: login/registration, movies list, movie detail, favorites and profile. The URL structure stays clean (/movies, /movies/:id, /profile), while the app never fully reloads.

• Components vs. views:
  The views (or pages) are responsible for data fetching and wiring, while smaller components handle presentation (movie cards, forms, nav bar, layout wrappers). This keeps logic and layout separated.

• Data layer & API integration:
  A small set of helper functions wraps the REST API calls (e.g. fetching all movies, a single movie, user data, or updating favorites). The React views call these helpers instead of using fetch directly, which makes the code easier to read and maintain.

• Authentication flow:
  After login, the client stores the API token and includes it in subsequent requests to protected endpoints. Routes that require authentication are gated in the UI (for example, favorites and profile), and the app redirects unauthenticated users back to the login screen.

• Styling & layout:
  Bootstrap and React Bootstrap provide the basic grid, layout and components (navbar, cards, buttons), while SASS is used for custom theming and fine-tuning. Styles are organized into partials so that variables and mixins can be reused.

• Build & deployment:
  Parcel bundles the React code, SASS and static assets into an optimized build. The production bundle is deployed as a static site, pointing to the live API.

Phase 1 – Scaffolding the SPA

I started by setting up a small React project with Parcel, installing React Router, Bootstrap and React Bootstrap. The first step was to get a minimal layout working:

• a top-level navigation bar,
• placeholder views for Movies, Favorites, Profile, Login and Register,
• and basic routing between them.

Getting the skeleton in place early made it easier to reason about navigation and where each piece of functionality would live.

Phase 2 – Connecting to the API

Next, I created a simple API helper module to talk to the Flicktionary RESTful backend. This included:

• functions to fetch all movies or a single movie by ID,
• endpoints for user registration, login and profile updates,
• and endpoints for managing favorites.

By centralising this logic, I could later change details such as base URLs or headers without touching every component.

Key learning: Even in small apps, a thin data layer makes the codebase easier to evolve.

Phase 3 – Auth flow and protected views

With the API connected, I implemented the full auth flow:

• Registration and login forms with validation and error states.
• Storing the token after successful login and including it in subsequent requests.
• Conditionally rendering navigation items and views depending on whether the user is logged in.
• Redirecting unauthenticated users away from protected pages.

This phase was where the client truly became “aware” of the backend’s rules about who can access what.

Phase 4 – Movies, details and favorites

Once users could authenticate, I focused on the core movie experience:

• A movie list view with cards showing poster, title and a short description.
• A movie detail view showing extended info (description, genre, director).
• A simple favorites mechanism, letting users add/remove movies from their watchlist and see that list in a dedicated view.

I aimed for a straightforward pattern: interactions like favoriting trigger an API call, and on success, update local state so the UI feels immediate.

Phase 5 – Polishing, documentation and deployment

The final phase was about polishing and making the app ready to share:

• refining layouts for mobile vs. desktop,
• improving error messages and loading states,
• adding documentation in the app to explain key features and flows,
• and building a production bundle for deployment.

Key learning: For SPAs, perceived quality often comes down to “small” details like loading states, empty states and clear copy – not just whether the data loads.

• Manual testing of core flows:

  • registering a new user, logging in and logging out;
  • browsing the movies list and opening detail views;
  • adding and removing favorites;
  • updating profile details and confirming they persist;
  • trying to access protected views while logged out.

• Cross-device checks:
  I tested the app on different viewport sizes to ensure the Bootstrap-based layout stayed usable on mobile, tablet and desktop.

• Runtime checks with PropTypes:
  I used PropTypes on key components to catch obvious type mismatches during development (for example, expecting a movie object but getting null).

If I revisit this project, my next step will be to add automated tests – starting with component tests for key views (using React Testing Library) and a small number of end-to-end tests to cover critical flows like login and managing favorites.