| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
* extract Blog component from BlogPage (paginated) and extract Article
component from ArticlePage to avoid `Cannot read properties` errors due
to fallback route
* fix sitemap build (cjs not supported)
* fix eslint warnings (react/jsx-no-literals)
* update `start` script since I'm using standalone output
* update `postbuild` script since we need to copy public and static
files to standalone directory (Next.js does not handle it itself
because we should use a CDN...)
|
| |
|
|
|
|
|
| |
It does not make sense to re-export an existing object through a hook.
On some pages both the hook and the object was imported...
It is better to use the CONFIG (previously settings) object directly
and by doing it we avoid potential errors because of conditional hooks.
|
| |
|
|
|
|
| |
* reuse Theme provider logic
* move DOM mutation from provider to hook
* add a script to init theme before page load
|
| |
|
|
|
|
|
| |
To be honest, next-themes was working fine. However since I use a theme
provider for Prism code blocks, some code is duplicated between this
app and the library. So I prefer to use a custom Provider without the
options I don't need.
|
| |
|
|
|
|
|
|
|
|
| |
Since the local storage key is not meant to change between the
components, it should be set directly inside the app file. So
both the local storage and the data attribute should be handle
in a provider.
I also added a custom document because we need a script to
retrieve the stored value in local storage earlier to avoid
flashing on hydration.
|
| | |
|
| |
|
|
|
|
| |
Next expect a default export for pages so only those components should
use default exports. Everything else should use named exports to
reduce the number of import statements.
|
| |
|
|
|
|
| |
Using paths aliases starting with "@" can be confusing and can lead to
conflict with existings modules. I prefer to use relative paths to
avoid extra configuration in tools because of these aliases.
|
| | |
|
| |
|
|
|
| |
It prevents to rerender the common components between pages (header,
footer...).
|
| |
|
|
|
| |
Since I'm using new components, I will also rewrite the GraphQL queries
so it is easier to start from scratch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* build(deps): add use-ackee hook package
* chore: create a context provider for Ackee
The provider allows users to change the 'detailed' settings.
* chore: add a select menu to choose which info to share with Ackee
* chore: add a tooltip for askee settings
* chore: replace default select styles with custom styles
* chore: register user choice in localstorage
* chore: replace Matomo with Ackee in legal notice
|
| |
|
|
|
| |
I do not use all Matomo features so I was searching a lightweight
analytics tools. I will give a try to Ackee.
|
| |
|
|
|
|
| |
I though the previous package would track all visits with the provided
but it seems that I need to add trackPageView on all pages. So I
decided to use another package.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The previous method was not working so I tried a different approach.
Translation is loaded but I'm still getting warnings:
* Plurals for locale undefined aren't loaded
* Text content did not match
I can't figure how to fix them...
|
| | |
|
| | |
|
| |
|
|
| |
I can now insert header/footer on each pages.
|
| | |
|
| |
|
