This repository contains the second version of the CLIC's website.
The website's code is located in the /app directory. It uses NextJS, a React-based framework to provide a single page application, coupled with SCSS for styling.
The React components are located in the components directory, while the website pages are in the pages directory (see NextJS's documentation about routing).
To fetch data from Directus, it should be done on server-side, using the directus() to generate a handle to call Directus' API (https://docs.directus.io/guides/sdk/getting-started.html) object in directus.ts. To achieve that, the page's file must also export a getServerSideProps() function. The directus object is not usable on client side, since its token is restricted to the server.
To store and provide dynamic content, we use the service Directus, which acts as a content management server.It is ran separately from the website in the infrastructure. See its documentation.
All the assets should be managed by Directus when pertinent/possible. For example, the CLIC's logo is stored in the Association entry of Directus, instead of having its SVG in the assets/ directory.
However, the background of the website is not managed by Directus, since it is not considered a content of the website. Note: In this example, the background svg is imported in the .tsx using NextJs default image loader, instead of the SVGR loader. This is because the background is handled by the CSS background properties, which require the image's url, instead of content.
To import SVG files from the assets/ directory, they should be imported into the .tsx file, and used as React components. They have no type declaration, but you can add any attributes appliable to a <svg> tag. Note: as for all React components, the class attribute is renamed to className.
I18n is achieved via a coupling of a homemade API and Directus's own i18n management.
When fetching data, you need to add a few parameters in the Directus' API call. In the fields attribute, you need to specify which field from the queried objects you need, and which fields from the translations. To simplify this, you can use the queryTranslations object in locales.ts as query parameters, or for extending your query parameters ({<your params>, ...queryTranslations}). The latter does not work if your initial parameters do already contain a fields entry.
For small or dynamic pieces of text, like date formatting, or titles not bound to a specific entries (like the News title in the /news page). It contains a dictionary of specific words/sentences for each used locale, as well as options to format them (e.g. capitalization).
The current locale can be recovered either from the context parameter in getServerSideProps() (context.locale) or a router yielded by useRouter() in a React component (router.locale). Transitions between locales can either be achieved by using a router or a link, see the documentation.
It is recommended to use VSCode, with the following extensions:
You will also need:
After installing all dependencies, you need to run:
npm install
npm run prepareImportant note: If your UID/GID is not 1000, you need to export them as USER_ID/GROUP_ID environment variables for the containers to work. See .env.example.
Afterwards, refer to this document to setup a local Directus instance.
The development is done in the /app directory for the website, or from Directus admin UI, on http://localhost/directus.
In order to run the server, use docker and run the compose file at the root of the project:
docker compose upNote: For VSCode users, there are two tasks, under Terminal > Run tasks..., to both start and stop the server. The start task is automatically run when you open the directory.
When editing the website, modifications will immediately be visible, without reloading the page or restarting the server.
All services are ran behind a Caddy reverse proxy, mounted on port 80. The associated config is found in the /caddy directory (note: this is not the production config).
The code must be formatted with Prettier (using npx prettier --write <directory>). This will be checked by a hook upon commit.
The commit message must follow conventional commits convention. This is both checked by a local hook and by the CI.
Style scss must be imported into code files and classnames must not be referenced in clear.
After a push on the main branch, the website is automatically built into a docker image, and pushed to GHRC. When opening or pushing to a pull-request on the main branch, the images are also built, but not pushed, for sanity check.
The rest of the deployment is done by a dedicated repository.