Happenly Progressive Web Application - Know what's on

The Challenge

The assignment defined Happenly as an events dashboard on top of Google Calendar data. The app needed to:

• Fetch upcoming events from a Google Calendar feed,
• Let users filter events by city,
• Control how many events are displayed,
• Expand and collapse event details,
• Provide basic charts that visualize key aspects of the events,
• And continue to be useful offline as a Progressive Web App.

Behind that, there was a second challenge: design the app in a way that’s testable. The feature set was expressed in Gherkin feature files, so the UI and logic had to be structured to support Cucumber scenarios, Jest unit tests, and Puppeteer end-to-end tests.

Objectives and Success Criteria

Within this brief, I set a few concrete goals:

• Make filtering feel intuitive
  Typing into the city field should surface suggestions quickly, and users should understand immediately when there are no events for a location.

• Keep the event list under control
  Let users specify how many events to show, so they can switch between a broad overview and a narrow focus.

• Balance overview and detail
  Show a compact list by default, with expandable panels for details and a dedicated charts view for bigger-picture insight.

• Behave like a PWA
  Cache essential assets and data so previously loaded events remain available offline, and support “Add to Home Screen” for a native-like feel.

• Back everything with tests
  Use BDD-style scenarios to define behavior, Jest for unit tests, and Puppeteer for end-to-end flows, so the app feels reliable from both a user and developer perspective.

I considered the project successful if:

• Users could discover and filter events without confusion,
• The app remained usable when offline (at least for cached data),
• The charts added value instead of feeling decorative,
• And the test suite gave confidence when refactoring or adding behavior.

• Front-end structure (React + Vite)
  The UI is split into focused components:

  • city search and suggestions,
  • number-of-events control,
  • event list and expandable event cards,
  • and a charts view that uses Recharts.
    Vite handles fast local development and optimized builds.

• Events data & backend integration
  A custom Node.js function deployed as an AWS Lambda serves as a lightweight backend. It:

  • authenticates with the Google Calendar API,
  • fetches upcoming events,
  • normalizes them into a front-end-friendly format,
    and exposes them via a simple HTTP endpoint.

• PWA shell & offline behavior
  A custom service worker configured with Workbox:

  • precaches the core shell and key assets,
  • caches event responses for reuse when offline,
  • and handles fallbacks when the network is unavailable.

• Charts and analytics
  The charts view uses Recharts to plot:

  • the number of events over time,
  • and distribution across locations or other dimensions derived from the data.
    This gives users a compact visual overview, not just a long list.

• Testing infrastructure

  • Jest for unit tests around pure logic and smaller components,
  • Puppeteer for end-to-end tests that drive a headless browser through key user flows,
  • Cucumber + Gherkin feature files to describe behavior in human-readable scenarios and align tests with user stories.

Phase 1 – Defining user stories and BDD scenarios

I started not with components, but with Gherkin feature files. For each core feature (filtering by city, showing/hiding details, specifying number of events, offline behavior, PWA installation, charts), I wrote scenarios in the form:

Given … When … Then …

This clarified:

• the default states (e.g. showing events from all cities when no filter is applied),
• expected responses to edge cases (no events in a city, invalid number of events),
• and what users should see when offline.

Key learning: Writing behavior in plain language first makes it easier to design both UI and tests in a consistent way.

Phase 2 – Building the main event list

With the behavior defined, I built the core event list:

• A controlled city input with suggestion dropdown,
• A number-of-events input with validation and helpful messages,
• A list of events, limited to the current “number of events” setting.

This was backed by a data-fetch layer that calls the AWS Lambda endpoint and normalizes the response into the format the UI expects.

Key learning: Keeping data fetching and UI concerns separated made it easier to test and iterate on either side.

Phase 3 – Expandable event details

Next, I implemented expandable/collapsible event cards:

• By default, cards show only high-level info,
• A “Show details” button reveals the full description and extra metadata,
• The same button toggles to “Hide details” to collapse the panel again.

This pattern maps directly to BDD scenarios about default collapsed state and user interaction, and it improves scan-ability when many events are visible at once.

Key learning: Simple expand/collapse behavior can significantly reduce information overload when working with long lists.

Phase 4 – Charts and analytics

Once the list felt solid, I added the charts view using Recharts:

• One chart shows how many events occur on upcoming dates,
• Another can show distribution of events across cities or other dimensions derived from the Google Calendar data (depending on what’s available).

The charts respond to the same data source as the list, so they stay in sync with what the user is seeing.

Key learning: Visualizations don’t have to be complex to be useful; even simple count/distribution charts add value over a plain list.

Phase 5 – PWA features and offline behavior

I then focused on the PWA aspects:

• Added a manifest and icons for installability,
• Used Workbox to generate a service worker that:
  • precaches essential assets and shell UI,
  • caches responses for events data,
  • falls back gracefully when the network is unavailable.

This allowed scenarios like:

• seeing a friendly message when opening the app offline for the first time,
• revisiting previously loaded events while offline without errors.

Key learning: Thinking through first-time vs. returning offline usage is important to avoid confusing states.

Phase 6 – Testing with Jest, Puppeteer and Cucumber

Finally, I wired the test stack:

• Jest for unit tests of pure logic (e.g. filtering, limiting, validation),
• Cucumber to link Gherkin scenarios to step definitions,
• Puppeteer to drive a real browser against the built app:
  • typing into the city filter,
  • expanding event details,
  • changing the number of events,
  • verifying messages in offline-like conditions.

Key learning: Having tests that reflect the original BDD scenarios gives a strong sense of alignment between requirements and implementation.

• Unit tests (Jest)

  • Validate core logic such as:
    • filtering events by city,
    • limiting the number of visible events,
    • handling invalid input values.
  • Run quickly and provide fast feedback during development.

• BDD scenarios (Cucumber)

  • Gherkin feature files describe behavior like:
    • default event list when no city is selected,
    • what happens when a city has no events,
    • showing and hiding event details,
    • offline usage with and without cached data.
  • These scenarios act as living documentation and guide the implementation.

• End-to-end tests (Puppeteer)

  • Launch a headless browser and simulate real interactions:
    • typing into the city filter,
    • selecting from suggestions,
    • changing the number of events,
    • toggling details.
  • Confirm that UI, network calls and state updates all work together.

• Manual testing

  • Exploratory passes in the browser for:
    • responsiveness on different viewport sizes,
    • basic keyboard navigation and focus handling,
    • PWA install prompts and behavior when launching from the home screen.

If I revisit the project, I’d like to extend automated tests around more complex edge cases (for example, stale caches and chart behavior when data is missing or partial).