momesana / react-ts-webpack-template Goto Github PK

Us react-intl to introduce i18n capabilities for the application. Do it the way we have done it in the yumlet client

DoD:

• context to expose the selected locale, supported locales and switcher function
• use our usual config for the eslint plugin
• use scripts to extract the languages
• the high cohesion/loose coupling architectural pattern should be applied

Rationale:
Supporting dark themes is a common requirement in web applications these days.

Dod:

• use a very simple theme object with just a few attributes based on Antd's well-thought out theme seed token, namely:

• colorPrimary

• colorLink

• colorBgContainer

• colorBgElevated

• colorText

• colorTextSecondary

• colorWhite

• the theme info is made accessible to the app via a context. The context exposes a function to set the theme to either "system", "light" or "dark", the set of available themes ("system"| "light"| "dark" for now), and the currently selected value

• the value should be stored in the local storage.

• the browser when loading (that is before the theme kicks in) should use the browser preference for the color-scheme

• pass down the theme via styled-components

• in global styles the theme variables should be turned into css variables of the same name as well (css variables are easier to use but don't let you access the value in js to for example apply transformations. We'd like to have both available)

• derive css variables based on that theme object

• apply patterns of high cohesion and loose coupling (the theming infrastructure should all be in just one folder expoing a context provider that will wrap the app)

• the selected theme needs to be stored in localstorage lest it is lost during a reload. Before even react loads the preferred color scheme should be defined via css. When react is up and running we look into local storage to get the value for theme. If it doesn't exist or is set to system, we default to browser meaning we'll use the color scheme to whatever the browser tells us is the preferred scheme. If the value exists in the local storage we set it to that overriding the system.

• for testing purposes introduce a simple select (just the standard html select) with these three options so the user can change them at will.

Add facilities (this should merely be scripts in package.json) that help up analyse the created bundle via https://github.com/webpack-contrib/webpack-bundle-analyzer. No need to pollute our dependencies with it as it can be just used via pnpm dlx.

DoD

• it should be possible to create a statistics file by issuing pnpm bundle-stats
• it should be possible to launch the analysis tools issuing pnpm show-bundle-analysis.
• both should be achievable by issuing pnpm analyse-bundle

Rationale
The idea is to have a most minimal entry point to already be in a react context and lazily start bootstrapping the actual app. This is important for apps where the actual bundle grows in time and might take more than a few seconds to load. While the app hasn't loaded yet any errors (also fetch errors) will lead to a blank page and the user is wondering why he is staring at a blank content.

Therefore we'd like to achieve these things:

• load the most basic bootstrapping environment that has only react and a react errror boundary to display possible erros when lazy loading the app. Also This must be wrapped in supsense with suspense using a loading indicator as a fallback. Keep in mind that again we don't use things like styled-components here as we'd like to keep the size of the entry point to a minimum. With this in place the loading can be showin in react and also errors will be displayed using the minimal error boundary. The user won't see a blank page in case of errors (unless the main bundle couldn't be fetched or caused an error).

In spirit, this is the render initial route as soon as possible aspect of the PRPL pattern.

DoD:

• entry point of the app is the minimal bootstraping file bootstrap.tsx
• entry bundle (main bundle) must be as small as humanly possible. This must be verified using our bundle analyzer. Set maxEntryPointSize to a reasonably small value and show a warning if it has been exceedd (see the performance setting in the webpack docs: https://webpack.js.org/configuration/performance/)
• entry bundle lazyloads src/index.tsx which again lazyloads src/App.tsx.