It's that time of year again to tinker with the blog cough cough. Due to the upgrade of Gatsby, the repository received too many dependency warnings. At the same time, I realized some drawbacks of the all-encompassing framework, so I decided to abandon Gatsby and switch to Next.js.
Gatsby vs Next.js#
Both are page building frameworks in the React ecosystem, and they both provide static site generation (SSG) functionality. As a simple blog, static exporting is sufficient to meet my needs.
In terms of fetching page data, the difference between Gatsby and Next.js lies in the fact that Next.js allows data to be fetched from any data source by simply returning the corresponding value in the specified lifecycle function getStaticProps. However, Gatsby's data source is based on graphql, but many implementations rely on plugins, heavily relying on the community and official work.
The current article content is saved through the local file system, and using Gatsby and Next.js is essentially equivalent. However, Next.js far surpasses Gatsby in terms of TypeScript support.
Using Templates#
Originally, I wanted to reproduce the previous setup using Next.js and then make changes. However, I found that using MDX to build articles would result in better display effects than pure markdown.
But during the integration process, I found that using MDX in Next.js cannot be well customized if it is not handled by Next.js as a pages. However, when rendering using next-mdx-remote or mdx-bundler, new Function() needs to be used.
Although I eventually solved this problem, I didn't find it very elegant. While looking for a solution, I came across a template. This template also uses tailwindcss, and recently I have been using a similar library called windicssbecause tailwind didn't have JIT mode before.
So I decided to use this template instead. I think many of the layouts are great, but some of the features and page display styles still need improvement, especially the homepage, which is too simple.
Content Management#
In the final version of Gatsby, I used Netlify CMS to manage content, which basically formed the structure of JAMStack. However, in terms of user experience, it was still lacking as a content management system.
I also tried using Notion for content management, but it was somewhat inferior to using markdown directly.
Using Additional Content Management#
Now the goal is to use the inspiration from Sukka's article Using Next.js + Hexo to Rebuild My Blog to integrate hexo with Next.js or combine it with contentlayers.
contentlayer#
This package has great ambitions and aims to integrate various content sources, whether it's local files like MDX, markdown, JSON, plain text, or CMS.
However, some of its target features are still a work in progress. But it may be possible to integrate with Notion in the future, which I think would be great.
hexo#
Hexo is not only a static site generator, but its internal database also exposes a series of APIs for directly manipulating local articles.
For this part, you can refer to Sukka's article and the official hexo documentation. One advantage of hexo is that it can persist data based on the file system, which can save some time and resources during the build process.
At the same time, some of the integrated features of hexo, such as generating RSS and sitemap, can simplify the existing code for this part. There are also many useful features provided by the hexo CLI.
Integrating i18n#
Actually, internationalization seems to have little impact on my small blog, but I haven't used it in my work so far. Maybe it's paving the way for future English articles? Will there be any?
next-translate#
Actually, if you look at the commit history of the repository, you will know that I initially chose next-i18next for i18n, but found that I had to manually add props to all dynamic routes, which was very troublesome. So I ended up using next-translate.
The plan for the future is to add an additional lang attribute to the frontmatter of the articles to identify the language. Then, display a language tag in the article list to indicate the language of the article content. In the future, additional handling may be done for bilingual articles and language switching.
However, it seems that the formatting of time strings still varies according to the reader's language, which needs to be improved.
Doing string translation work takes a lot of time
Domain Name Resolution#
Mounting on GitHub or Vercel looks a bit low, so I spent a lot of money bought a enpitsulin.xyz domain name and then bound it to blog.enpitsulin.xyz in the Vercel console. Then, I added the resolution settings in the Alibaba Cloud console according to the records provided by Vercel, and waited for a while.
But it seems that I still need to use a VPN now, so I will adjust this part later.
And the root domain name has been filed and kept for future learning purposes.