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 SSG functionality. As a simple blog, static export 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 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, largely depending on the community and official work.
The current article content is saved through the local file system, and using Gatsby and Next.js is basically equivalent. However, Next.js far surpasses Gatsby in terms of TypeScript support.
Using Templates#
Originally, I wanted to reproduce the previous usage of 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 if MDX is not handled by Next.js as a pages page, it cannot be customized well in Next.js. 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. Then, while looking for a solution, I found a template. This template also uses tailwindcss, and recently I have been using a similar type of 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 rudimentary.
Content Management#
In the final version of Gastby, I used Netlify CMS to manage content, which basically formed the structure of JAMStack. But in terms of user experience, it was still a bit lacking. As a content management system, I don't think the user experience is very good.
I also tried using Notion for content management, but to some extent, it was not as good as 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 they are local file systems such as 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 Hexo official 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 RSS and sitemap generation, 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 effect on my small blog, but I haven't used it in my work, so 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 needed 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 front matter of the articles to indicate the language. Then, display a language tag in the article list to indicate the language of the article content. In the future, additional handling will be done for switching languages in bilingual articles.
However, it seems that the formatting of the time string still varies according to the reader's language, so this still needs improvement.
Doing string translation work is time-consuming
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 this part will be adjusted later.
And the root domain name has been filed and will be used for learning purposes in the future.