In [[ https://github.com/wmde/fundraising-application/blob/main/doc/adr/021_Single_or_Multi_Page_Application_Architecture.md |ADR 21 ]] we decided move the Fundraising Application PHP-based backend to an API. This task is an outline of the migration path.
There are 3 main points where the client-side code relies on the server-side code:
1. **I18N** - We need to integrate the application messages (and other content) into the build process of the frontend code and deploy the built frontend code whenever the messages change. {T285231} tracks how to do this and is the first and most important step to moving to the new architecture.
2. **"Application variables"** - The server "renders" its template variables into an HTML data attribute where the client-side code picks it up. The section "Migrating application variables" outlines the different approaches of getting rid of those.
3. **Routing** - Currently, the server side does all routing. We can gradually migrate the frontend to a SPA by using Vue Router with all pages (entry points) that don't have application variables. This allows for a gradual migration, page by page.
**Migrating application variables**
* HTML <head> content - Move to i18n or index.html template. The <title> attribute does not need to be dynamic, every other content item can also stay static
* Bucket selection:
* replace code in `page_data_initializer` with a class that can translate URL parameter into bucket names.
* Add the parameters to API requests so they get stored on the server.
* Make the "spenden_ttg" cookie client-accessible (remove HTTP-Only attribute).
* If we ever want to do the bucket selection without banners, we need to port the bucket configuration and selection logic into the frontend.
* Prefill banner parameters (payment) into donation form, skip payment page if they are correct. Can be done with client side code that takes the parameters from the URL. Open question for UX: How should the application behave when the banner sends invalid values (or malicious users put in invalid values in the URL)? See {T262925} for an example
* Donation/Membership confirmation page - Go to the confirmation page component if the donation was successful. Instead of deleting the store when the donation was successful, keep the data in memory/session store until the user leaves the page.
* Insert Donor information on membership form - Copy donor information from donation store to membership store when transitioning from donation success page to membership page
* static page content - We compile the HTML content from fundraising-frontend-content (`i18n/LOCALE/pages/web`) is compiled into the bundle via [[ https://webpack.js.org/loaders/html-loader/ | html-loader ]] and lazy-loaded with current locale. Some HTML pages (use of funds, supporters list) are obsolete because they are already componentized and get their contents from JSON (see next item).
* JSON content from `i18n/LOCALE/data` (e.g. FAQ, use of funds, supporters list) - compile into component via `import "path/to/file.json"`. For small data files, compile in all files, for larger files (FAQ) use lazy loading based on locale setting.