Legislation Bills Explorer

What was awkward

The API exposes legislation data, but its raw responses are not an easy way to find a bill. The page has to build query parameters correctly, keep pagination stable, show loading and error states, and work on screens smaller than a desktop table.

How the data reaches the page

A typed service sits between the API and the interface. It validates inputs, builds query parameters, handles variations in the response, and gives the components one consistent model.

Normal browsing asks the server for one page at a time. Search can retrieve a wider result set and filter it in the browser, so combinations of title, status, source, dates, member, bill number, and year remain usable.

Choices in the code

• The service normalizes different API response shapes before the UI receives them.
• The table shows fewer columns and changes its controls on smaller screens instead of shrinking a desktop grid.
• The details modal shows English and Irish titles, moves focus correctly, and reports loading errors.
• Favourites stay in the current browser. The interface does not imply an account or a save operation on the server.
• Error boundaries and separate request states keep an API failure from collapsing the whole page.

What the tests cover

Local verification covers table behavior, details, filters, favourites, API transformation, and the main browser journeys. Playwright scenarios run in Chromium, Firefox, and WebKit, with an accessibility audit in Chromium and semantic grid checks in all three browsers.

What it leaves out

This is a frontend prototype over a public API. Favourites stay in the current browser, and the interface keeps API failures visible instead of presenting stale data as current.