Notification client frontend spike

[dblatcher]

What's changed?

Creates a separate vite / react subproject for a new notifications client, with a similar pattern to the v2-fronts tools and adds the routing in the scala app to serve the new frontend to a /notifications page.

The react app is currently just a Hello World using Stand Components, but can serve as a space to iterate on the new UI without interfering with the fronts-tool, or needing to re-implement the backend services and infrastructure (user auth, CAPI access etc) available from the facia-tool project.

In the long term, we would probably want to separate this sub-project and relocate it in its own repo and backend.

Implementation notes

As of dd9f36c, the TODO's would be:

• have separate controller(s) for serving the notifications client and its assets
• set up a config class for the data that gets injected into the page for the client-side config
• make the user data available to the client app
• have the client App make at least one request to the existing backend (maybe fetching a list of recently published Articles?) as a proof of concept
• configure eslint and some example unit-tests (maybe vitest rather than jest?)

Checklist

General

• 🤖 Relevant tests added
• ✅ CI checks / tests run locally
• 🔍 Checked on CODE

Client

• 🚫 No obvious console errors on the client (i.e. React dev mode errors)
• 🎛️ No regressions with existing user interactions (i.e. all existing buttons, inputs etc. work)
• 📷 Screenshots / GIFs of relevant UI changes included

[github-actions]

Deploy build 9640 of cms-fronts::facia-tool to CODE

All deployment options

• Deploy build 9640 of cms-fronts::facia-tool to CODE
• Deploy parts of build 9640 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Unless a comment is added or the “stale” label removed, this will be closed in 3 days