This will render all relative dates present on the pages again in the browser, so that they show the correct relative values to the current time. As this leads to a DOM that differs from the server-rendered DOM, we need to use suppressHydrationWarning for the rendering locations. Without that, we would get some React errors, leading to e.g. broken navigation.
As we now base all rendering on authorDateIso, the redundant old variants that contained the pre-rendered relative date string have been removed from the staticProps, reducing the size of the data blob that will be served to the frontend.
Flow to test (might be easier with libfaketime, but I didn't get that to be respected in the Next.js build):
Set system time to a value that is close to the latest BCR commit that added a new module
pnpm run build && pnpm run export (The static pages now have some old dates baked in)
Reset system time to now
Serve out directory via static file server (e.g. npx serve) and view in browser
CLOSES #27
This will render all relative dates present on the pages again in the browser, so that they show the correct relative values to the current time. As this leads to a DOM that differs from the server-rendered DOM, we need to use
suppressHydrationWarningfor the rendering locations. Without that, we would get some React errors, leading to e.g. broken navigation.As we now base all rendering on
authorDateIso, the redundant old variants that contained the pre-rendered relative date string have been removed from thestaticProps, reducing the size of the data blob that will be served to the frontend.Flow to test (might be easier with
libfaketime, but I didn't get that to be respected in the Next.js build):pnpm run build && pnpm run export(The static pages now have some old dates baked in)outdirectory via static file server (e.g.npx serve) and view in browser