Reading view

There are new articles available, click to refresh the page.

面向产品设计的 Web 前端分享会(分享会记录)

最近听说部门里面的产品或本地化运营对 Web 前端相关的内容比较感兴趣,正好我有相关的实践经验,所以在公司做了一个 Web 前端相关的分享会。分享内容包含:

  1. 使用 Devtools:介绍 Chrome 浏览器内的模拟、编辑和审查工具;
  2. 网页和部署:介绍 HTML, CSS, JavaScript, React,以及网站的部署和托管;
  3. 网页性能指标:介绍网页性能常用指标和测量工具;
  4. 资源分享:分享浏览器插件、网站和课程推荐。

与以往不同的是,这次分享会中加入了互动环节。我做了一个代码 Playground,尝试帮助观众了解 React,以及 React Props 的概念,并留了两个小任务,给观众尝试去实践对 React 项目进行编码。

完整的分享内容内容请继续浏览本文。

使用 Devtools

这个章节主要介绍 Chrome Devtools 一些可能不为人知的功能,来帮助我们提高日常工作中的效率和解决一些问题。先介绍 Devtool 里面「模拟」相关的功能。

模拟设备和屏幕尺寸

在 Devtool 里打开设备工具栏,在这里除了能够自由调整网页宽高,还能够模拟各种主流设备的屏幕。

甚至还能读取到网页里面的断点样式,提供快捷切换各种断点的方式。

需要注意的是,这里模拟的设备是会带上 UA 的,所以如果想在电脑里调试一些做了移动端特化处理的网站(比如访问主域名时,判断到是手机设备,则会跳到移动端的专门网站),是需要用到这个功能的。

模拟伪类

Devtools 还可以帮助我们排查各种交互状态下的样式问题,最常用的是,比如说我们想仔细排查某个元素的悬停和按下状态的样式,则可以在选中元素之后,勾选对应的伪类选项。

模拟媒体

在渲染面板(需要手动开启,浏览器默认是没有打开这个面板的)能够模拟部分系统设置,比如亮暗模式、打印模式、高对比度和减少动态效果等。

与之对应地,可以扩展一个概念叫做 CSS 的媒体查询,CSS 还可以探测到很多用户设备的属性或者设置,比如设备指针精度、视窗比例、当前是否全屏模式、设备方向等…

能探测的内容很多,但实际能用起来的可能只有寥寥数个,最全面的信息可以取 MDN 上查看。

编辑网页文字样式

Devtools 还提供了一个新的字体编辑器,能够让我们实时更改网页中的字体家族、字体大小、字重等属性。

编辑网页内容

我们在 Devtools 控制台里面执行代码document.designMode = 'on' 后,就可以实时在本地修改网页文字内容了,就跟平常打字一样。很适合用在测试文案长度的场景。最后也会分享一个浏览器插件,能够对网页做更多的编辑。

审查 React 组件

最后介绍一个审查 React 组件的方法,有时候我们想看某个元素是不是用的组件库,或者这个组件包含了什么属性之类的,可以下载 React Developer Tools,然后点选网页中的任意元素,进行审查。

网页和部署

接下来我介绍一下网页构成和网站部署相关的内容。

通常来说,HTML, CSS, JavaScript 是构成网站的三个要素。其中:

  • HTML 用来用于定义网页的结构和内容,可以用来创建网站的各个部分,比如标题、段落、图片、链接等。
  • CSS 用来定义网页的样式和布局,这个可能会是咱们设计师比较熟悉的部分,我们能够利用 CSS 来定义 HTML 元素的各种样式,控制它们的布局和位置。
  • JavaScript 用来实现各种功能逻辑和操作交互。比如响应点击事件、动态修改网页内容,根据条件执行动画效果或展示特定内容等。

CSS 预处理器

上述的三种语言,都有各自对应的语法规则。而 CSS 预处理器,则改进了原有的 CSS 语法,使我们能使用更复杂的逻辑语法,比如使用变量、代码嵌套和继承等。

简单来说,CSS 预处理器能让我们写样式代码的过程更顺畅,使代码有更良好的可读性和扩展性,帮助我们更好地维护代码。

举个简单的例子,比如原本的 CSS 语法中要求我们给每一个元素写样式时,必须以花括号开始和结尾,而且每一条样式规则直接都要以分号隔开,而 Stylus 则能够让我们跳出这个限制。直接用换行和缩进来代替。

CSS 框架

另一个值得一提的概念是 CSS 框架。CSS 框架则提供了一套预设样式,比如颜色板、字体梯度,布局和断点设定等;以及一些常用组件,如导航栏、对话框和页脚等。

简单来说,就是提供了一批开箱即用的样式,便于开发者快速启动项目,同时也会保留高度自定义的空间,用于支持各种各样的需求。通常 CSS 框架都会包含使用某个 CSS 预处理器,甚至内置了一些图标库,主打一个 “开箱即用”。

这里稍微介绍一下一个 CSS 框架:Tailwind CSS。是一个高度定制化的 CSS 框架,通过大量的预定义类名,使开发人员快速构建和设计网页界面。

与其他 CSS 框架相比,有一个显著的特点是 Tailwind CSS 本身不会包装一个组件出来,比如按钮、输入框的样式,没有预设好的。取而代之的是,Tailwind CSS 将各种原子级的 CSS 类名包装起来,比如:

  • 设置左右两边的 Padding,用 px-[...] 类名来实现;
  • 设置一个元素为块级元素, 用block 类名来实现…

如果想要在 TailwindCSS 中,使用打包好的组件,达到开箱即用的效果,可以通过各种官方/非官方的模版或组件生态来进行。比如:

React

接下来介绍另一个概念:React。这是一个用于构建 Web 和原生交互界面的库(是的,它能够用来做 App,不仅仅是网页)。而且引入了 JSX 语法,将 HTML 和 JS 结合起来,以一种更直观和易于理解的方式描述界面的结构和内容。

React 有一点和我们的设计稿很像,就是它的组件思维。在构建用户界面时,React 主张先把内容分解成一个个可以复用的组件(把具体的交互、功能逻辑写在组件里面)。然后在页面中将各个组件连接起来,使数据流经它们。

下图引用了官网中的一个例子,其中:

  1. 完整的应用,可以理解为由多个组件拼接成的完成网页;
  2. 搜索组件,用来获取用户输入;
  3. 数据列表,会根据用户搜索来过滤和展示内容;
  4. 每个列表的表头;
  5. 表格内每条数据。

现在我们用一个具体例子来简单介绍下 React 的组件。

在上图中,展示了一个页面页面 App.jsx 包含了 Profile、Gallery 和 FAQ 组件,以及 Profile.jsx 组件的代码。右侧是输出页面,展示了三个组件拼接而成的页面效果示意图,其中 Profile 组件模块里展示的内容,是和 Profile.jsx 文件内代码一一对应的。

上述的组件只是将一个模块包装起来,使其能够被其他地方复用。但组件内容是固定的。接下来会为大家展示如何向组件传递 Props,实现上文提到的一句话 “使数据流经他们” 。

在上图中,我们先将一些 Props 传递给组件 Profile(比如这里传递了图片的地址、人物姓名和描述),然后在 Profile 组件内接收这些 Props,并在组件代码内使用这些数据。

现在,我们就做出了一个可以复用的组件了,可以根据不同的内容来展示相关的人物信息。

大家有没有觉得这种做法有点熟悉?是的,在 Figma 中,我们的组件里面也有类似的做法。Figma 组件同样同样传递字符串、布尔和组件等内容。

实际上 React 组件可以传递的参数不仅仅只是上面例子中的字符串和布尔值,还能传递数值、函数、对象、Node 类型甚至另一个组件等。

我做了一个简单的 Playground,提前封装好了一个 Profile 组件,会传递一些字符串、布尔值(是否展示网站标签)以及数值(圆角大小),帮助大家更好地理解。

🛝 Playground

我做了一个 🛝 Playground ,大家可以在里面看到这个组件的具体的情况,实际看一遍代码可能会帮助理解 React 的组建和 Props 概念。

同时我也写了两个小任务给到大家去尝试,大家可以在上面的编辑器中自由尝试。

发布网站

到了这里,相信大家对构建一个网站已经有了初步的认识,接下来我为大家介绍下如何将构建好的网站发布的互联网当中,能够真正地被世界各地的人们浏览。

方法一:部署到服务器

这是比较传统的方法,先将项目相关的文件放进服务器里面(比如阿里云 ECS,或轻量服务器等)。然后在服务器内安装 NGINX,索引到项目文件夹,定义好首页、端口、404 等场景,最后将域名解析到服务器 IP。之后我们的网站就能在互联网上被人们访问了。

方法二:托管到服务商

这种是相对省心的方法,将我们项目所在的 GitHub 仓库,链接到服务商的托管服务当中。等于是由服务商来帮我们部署、发布项目,不用自己来配置服务器的各种内容了。下图列举了几种常见的网站托管服务商,分别是:Vercel,Github Pages 和 Netlify。

以 Vercel 来举例,除了能够托管网站之外,对每一次发布进行管理,甚至能够是对不同代码分支进行独立发布,还能收集网站访问数据等。

网页性能

接下来为大家介绍网页性能相关的内容。通常一个网站性能好不好,我们能够在体验时主观地感受到,比如打开时很慢、滚动时卡顿,或者点击按钮后很久才响应等等。但如果要准确地判断到网页的性能到底如何,是需要依赖具体指标的。

下面介绍三个常用的指标,分别是:FCP(首次内容绘制)、LCP(最大内容绘制)以及 CLS(积累布局偏移)。

FCP(首次内容绘制)

FCP 是一个关键指标,用来测量页面从开始加载到第一个页面内容在屏幕上完成渲染的时间。越快的 FCP 时间能够让用户感知到网页有在正常运行,而不是停滞、无响应。

这里提到的 “内容” ,指的是文本、图像(包括背景图像)、<svg>元素或非白色的<canvas>元素。如下图所示,FCP 出现在第二帧。

LCP(最大内容绘制)

LCP 指的从页面开始加载到可视区域内可见的「最大图像」或「文本块」完成渲染的时间。

这里提到的「最大图像」或「文本块」,具体来说是包含<img>元素、内嵌在<svg>元素内的<image>元素、块级文本等。

而测量方式,则是在页面加载过程中,记录视窗内的元素的渲染大小,取尺寸最大的元素,回溯这个元素被完整渲染的时间。注意,如果元素的有一部分在视窗外,在视窗外的部分不会参与到尺寸比较当中。

如下图所示,LCP 发生在第二帧,因为这个时候渲染尺寸最大的文本块被渲染出来了。后续帧当中,可能渲染出了一些图片,但尺寸都比文本块小,所以文本块依然是这个视窗内的最大元素。

CLS(积累布局偏移)

CLS 是指可视区域内发生的最大布局偏移分数。简单来说就是测量页面在加载时,元素的位置出现意外的偏移情况,如果元素尺寸大,而且位置偏移比较远,那么 CLS 分数就会显著增高。

这个指标会跟实际的用户操作或者体验有直接相关,所以应该也会是咱们设计师需要重点关注的内容,因为有时候布局偏移,是会比较影响用户获取信息、或者进行操作,甚至引发一些不可挽回的损失。

然后我来介绍一下测量网页性能的工具吧。我自己用过这两个,发现其实没啥差别,大家看喜好使用即可:

两个工具都能模拟桌面设备或者移动设备,记录多项关键指标的数据,并给出改进建议。

观察页面性能情况,不仅仅是前端技术人员要做的事情,了解到设计师也是可以参与到其中的。

比如 Guillaume Granger,他会比较想控制页面中 JavaScript 的数量,所以它提到,他会将所有用了 JavaScript 相关信息记录在表格当中。之后每次在网页中使用 JavaScript 时,都会跟之前的记录进行比对,判断重要性,决定是否在这个位置上使用 JavaScript。

开发者 Thomas Kelly 则提出了当意识到页面性能出现瓶颈时,需要做的事情,比如:

  • 制定一个目标,团队一起往这个目标前进;
  • 高频收集页面性能数据;
  • 尝试用不同方式来解决同一个问题;
  • 与同伴分享对性能的一些新发现…

资源分享

最后来分享一下相关的资源吧,包含两个插件、三个学习网站以及一个 React 课程。

插件:VisBug

介绍一个谷歌官方出品的插件:VisBug,主要用来帮助用户在浏览网页时进行调试和设计,包括编辑和可视化页面的 CSS,尺寸和字体等元素。

插件:Motion DevTools

Motion DevTools 是一个检查网页动效的插件,可视化和分析用户交互设计中的滚动、动画效果,并支持实时编辑、预览或导出等功能。

网站推荐

接下来介绍三个在国内外拥有较高知名度和影响力的设计师和开发人员。他们的观点、经验分享往往能给我带来一些新的启发。尤其是他们对钻研新技术的热情,是非常强烈的。

课程推荐

最后强烈推荐一门 React 课程——The Joy of React,这个课程我在年初的文章也有提到过,是以互动式课程的形式,由浅入深地讲解 React。从基础的组件 props 和 JSX 知识,到 Hooks、API 设计等等,讲述非常清晰,强烈推荐。

分享会感想

分享完之后感觉效果可能还不错,大家都有各自的收获。而且分享会中也不时有人提出相关问题,我也一一进行解答了。

或者也有对我分享内容的一些补充,比如我在分享完 Devtools 环节的时候,有同事也分享了一个在 Application — Cookie 面板里快速切换网页语言的方法。

后面了解到大家对于 CSS 和 React 那块听的比较迷糊,因为原本没有实践过的话,会对这些没有什么概念。而且大家好像对 🛝Playground 没有什么兴趣,并没有人对里面的内容有什么提问和看法之类的,可能到这一步都比较迷糊?🤔

指标那块倒是有不少同事关心,问了几个问题,比如有哪些方法来去改进几个指标的数据,或者在设计过程中是否可以提前避免性能问题等等。

总体来说和之前的分享会相比,这次分享会的参与度比较不错。

用 Next.js 重构个人网站 (一):概述

封面图:Maxime Bourgeois

我的个人网站从 2017 年底(大四上学期的期末)进行 “研发”,2018 年初部署运行,现在已经过去了 5 年。中途经过大大小小近 300 次迭代和内容更新。

从原本只是用来放置我做 Side Project 成果的内容,到后来变成我对外展示的窗口,用来展示我在实际工作中的项目,以及设计博客和翻译的文章等。LRD.IM 的页面布局、风格样式、内容、功能等等随着我的设计生涯发展有着很大变化。

个人网站的发展过程图

互联网档案馆 Internet Archive 保留了 2019 年之后的存档。之后每一次改版我也会在该网站留下存档。不知 5 年后又会是啥样呢。🤔

唯一不变的是,它仍然是用纯粹的 HTML + CSS + JavaScript 来实现的。访问我的网站就像是打开一个文件夹,浏览器只是将我的 html 打开而已。

网站内部没有组件,没有数据源。改动一个公用的地方,如页面顶部导航栏或博客的文章添加一个模块时,我需要在编辑器里打开数十个 html 文件逐个修改。

自己一直有想着改造一波,但自己当前的水平,想做出一个现代化的个人网站还差很多。所以这个计划也就一直搁置,自己日常中最多是观察下其他优秀的个人网站及其实现方式,储备点灵感。

直到两个动机和一个条件的出现,我觉得是时候了。

动机和条件

动机:迭代频率

最开始我的博客页面只是一个列表,点击里面的文章都会跳转到 Medium 平台里面。后面我觉得这样做体验巨差,原因:

  • 自己创作的内容全部都放在别的平台上面去了。这是一个令我太不舒服的感受。我的想法是可以放到其他平台内,获取一点点流量和 SEO 的优势,但自己的站点是最优先的;
  • Medium 需要科学上网才能较好访问。读者的体验未必会好,从稳定性上考虑也不利于长期发展;
  • Medium 一直没有进步。感觉这几年这个平台在原地踏步,或者甚至是下坡路。这是我作为长期用户的主观感受。

所以后面我将 Medium 的文章导出成 HTML 文件(平台的功能),作出相应的调整后贴回自己的网站上面,这样文章就能又回到自己那儿了。

但这个转换的过程并不简单,Medium 导出的 HTML 是带有他们的一些标签和样式的,当时我是将每一篇文章的 HTML 都筛掉没用的内容,然后 CSS 里编写了一套自己的格式文本的样式,使其适应网站的设计风格。由于步骤太多我甚至还将做法记录了下来,发布文章之前任何一步有纰漏都会出问题。

Github 中我对 Medium 导出文章的处理方法

这套混乱的秩序维持了至少一年半,这期间我的每一篇文章都经过这样的处理。包括后面添加的「目录功能」、「博客功能区」等有新增或调整代码的时候,我都要在每一篇文章(40+ 篇)的对应位置里增删改。

这种手动、机械式、重复的工作不仅导致迭代网站的时间成本极高,也很容易出错

比如某篇博客的功能区,本身应该所有页面的这块内容都应该长得一样,只是日期不同,但就是因为我将数十个 html 文件逐个修改的时候出现了纰漏,导致某些页面的样式异常。

博客功能区异常和正常的对比
我将某段代码复制到该页面时可能某个地方出现了疏漏,就出现了样式异常。
这次重构我抛弃了 HTML,改成了用 MDX 来支持我的博客内容。之后的文章会介绍到我是如何用 mdx-bundler 来重构整个博客功能模块。以及我为了提升阅读体验所做的工作。

动机:体验问题

我对网站里面有一个非常刺眼的体验问题一直耿耿于怀。

暗色主题下刷新页面会出现闪烁
原本的做法下,亮/暗主题色的切换功能是写在 JS 文件里面。而用户在跳转页面时会重新加载一次文件,偶尔会出现令人难以接受的闪烁。

留意页面切换时的背景色闪烁问题。

我也带着这个问题咨询了前端工程师朋友,他认为如果将网站做成 SPA,应该就能解决这个问题。

单页应用(英语:single-page application,缩写SPA)是一种网络应用程序或网站的模型,它通过动态重写当前页面来与用户交互,而非传统的从服务器重新加载整个新页面。 — — 维基百科

而且对于主题色,其实最好是能给用户手动来切换,并且记录上次更改后的结果。但这个功能要做在静态网站上,而且想到有代码更改的话又得将数十个 html 文件逐个修改,实在是没有研究的动力了。

条件:离职之后

2022 年 11 月我从欢聚离职,回到老家,暂时离开城市和朋友圈。有充足的时间给我去学习这方面的知识,以及去做相关的实践。

技术栈

这次的重构我的个人网站并不是一时兴起,平常自己也会了解相关的资讯。既然选择了行动,就已经做好跳出舒适圈的准备,接触一些以往从没有实践过的内容。

Next.js

整个 2022 年,通过 Next.js 构建的网站挤满了我的推特信息流。时不时都会看到有些设计师/开发者在推特上发布自己的个人网站。也发现许多充满设计感的网站都是通过 Next.js 来做的,比如 LinearPipeFeyFrame.io 等。

设计的较好的网站截图示意

在一众先驱者的引导之下,我也去了解了下相关介绍,甚至还看了点 Next.js 初学者教程,里面大部分内容我大部分都能够 Get 到。感觉上手难度不大,又有这么多大佬级的网站做背书,于是乎,就是你了 — — Next.js!

Tailwind CSS

我选择使用 Tailwind CSS 的原因主要有两个:

第一个是这个网站做得很好看,包括它给出来的 Template,这让我有了进一步了解的兴趣;

第二个原因是这确实有效解决了在迭代原网站时让我烦恼的地方:

  1. 我基本上再也不用绞尽脑汁去想某一个元素的类名(还得是英文的,时间久了想不起来哪个样式用在哪);
  2. 在实际写代码的过程中也不用经常在页面和 CSS 文件中来回切换了。现在写反馈效果、媒体查询、深色样式时很方便;
  3. 最关键:我再也不用维护一个 2,000+ 行的层叠样式表了!重构后的 CSS 文件轻量了很多,因为都写进网页和组件中了。
使用 TailwindCSS 前后的代码量对比

Mdx-bundler

之前将 Medium 文章迁移过来的时候,就发现了 HTML 的做法只适合有富文本编辑器的平台。而像我这样式的多数在代码编辑器里面书写的话,可能 Markdown 更合适。

然后我是在 Tailwind CSS 的 Protocol 模版介绍当中了解到原来 MDX 是可以让 Markdown 和 Next.js 联动起来,然后也在 Josh 介绍自己的博客时。也有介绍到相关内容,于是就选择了 mdx-bundler 来实现我的博客模块。

Protocol 和 Josh 博客的截图

MDX 允许我们安装各种插件来增强博客的能力。比如支持到 Github Markdown 语法的插件 remark-gfm 和代码高亮插件 Rehype Pretty Code 等。

remark-gfm 和 Rehype Pretty Code 的截图

而且还能嵌入自己编写的 React 组件,这是让人感到惊奇的能力。这意味着我的博客文章可以不仅是图文、视频和 iframe 了,还能有一些互动元素,有很大的想象空间。

过程概述

由于我属于边做边学,所以整个重构的过程并非从头到尾一次性完成的。而是一个螺旋式上升的过程。

路线图:核心功能(设定通用布局和主要的样式、数据源和遍历、mdx-bundler 渲染博客文章) -> 填充内容(填充列表所需的文本、配图、URL等数据、用 Markdown 重写博客文章,并填入元数据、填充作品详情的内容) -> 带着过程中遇到的卡点和问题,在课程或其他开发者博客中学习理论知识 -> 将理论知识运运动到实际网站开发当中,解决问题和优化代码。
插图素材来自 egghead.io

第一步:核心功能

当时先完成核心或通用的功能部分(遇到难搞的功能先记录并跳过),然后将原站点的所有内容填充进去。
这时确保网站在本地环境中基本能正常跳转和响应点击,深色模式和响应式等适配工作需要完整做好,因为这方面是相对简单的工作。具体来说:

  1. 先学会 Tailwind CSS 和 Next.js 的配合使用,设定好通用的布局和主要样式。以及调试主要页面之间的路由跳转;
  2. 开始构建主要页面,学会运用数据源和循环遍历来呈现页面内容(完整的内容先不填充,确保循环能跑通,数据能正常获取);
  3. 尝试使用 mdx-bundler 来读取博客列表和渲染 Markdown 文章。这个模块特别重要,当时花了不少时间。

第二步:内容填充

这时会带着早些时候记录下来的问题和卡点,去耐心查阅并参考尝试其他开发者博客里面他们的实现方案,同时也进入 The Joy of React 课程当中系统地学习一遍 React 的基础内容。具体来说:

  1. 填充所有数据源和遍历中用到的内容,如某个字段的文本、配图的 URL 等;
  2. mdx-bundler 跑通之后,我用 Markdown 重写了所有的博客文章,并且每篇文章都填入相应的元数据;
  3. 填充所有作品详情页里的内容。

第三步:填坑优化

有了知识储备之后,最后再回头把原有的一些卡点和问题填补上,或者优化下原本的代码。甚至会改良下组件的命名、文件夹结构等等,这些会参考到其他开发者他们所总结出来的的最佳实践。

  1. 带着过程中遇到的卡点和问题,在其他开发者博客或课程中学习理论知识;
  2. 解决之前的卡点和问题,完成所有功能,以及边缘场景的处理;
  3. 看看原有代码有没有哪些地方可以改良;
  4. 重复「学习→解决→改良」步骤,直到网站达到了我认为能够部署的标准。

解决问题的方法

做一个网站实属不容易。尤其像我一样在自己的能力之外,选择用框架来实现,过程更加是绝非一帆风顺。不止跳出了舒适圈,甚至还跳进了「痛苦圈」。

技术方面的指引我不敢乱写,倒是可以分享下在这次重构的过程中,我用到的几个解决问题的方法:

搜索引擎和编程社区

一些广泛的问题我会找 Google 来帮忙,比如我想看看别人是怎么做亮/暗模式切换的,我会搜索类似 “next.js darkmode switch”,搜索结果中可能会出现一些开发者的博客、Stack Overflow 或 Github Issue 中提出相似问题的人,这些内容是我可以拿来参考的。

搜索+实践的示意图

ChatGPT

在去年 12 月 ChatGPT 横空出世,当时有看到很多推文有展示它的神奇功力。我甚至觉得它很多的回答比人来回答还要好,很清晰和有条理,让人感到意外。

我也利用上这股强大的力量,用 ChatGPT 来解决一些具体的问题。比如现在博客文章里面的目录,会查找页面内所有的H2 H3标签并生成为一个列表,这就是我向 ChatGPT 提出我的需求之后,它来帮我写出来的。

ChatGPT 帮我实现博客文章目录功能的回答

另外我也会让 ChatGPT 帮忙解释某段代码的意思或作用。我从搜索引擎或编程社区里获得的一些解决方案,有时候某些语句自己没看懂的时候,会需要 ChatGPT 来帮忙解释一下,好让我针对自己网站的特点作出些许改造,或者了解报错原因和解决方法。

Joy of React

即便 ChatGPT 能解决部分具体的问题,但也不是万能的。实际开发中有些特别具体的问题,始终还是要靠自己。我对 JavaScript 掌握的程度是属于半滴水(半桶水都算不上),对 React 以及里面的 JSX 语法更是完全没了解过。

简单的内容靠查阅文档 + 观察规律可以学会,比如我通过看其他人的案例,我大概知道了每个组件里面都要有一个export、return()里面只能有一个子标签、JSX 里面有一个特殊的标签是<> ... </>等等...

但稍微再具体一点的问题,比如根据某个条件来更改样式,或者甚至想直接做一个需要传递参数来改变展示方式的组件,这些特别个性化的内容想要光靠搜索引擎和 ChatGPT,效率太低了。很可能搜半天还是一头雾水,浪费光阴。

刚好在今年 1 月 24 日,前端大佬 Josh W. Comeau 发布了 The Joy of React 的教程,这是一份面向初学者的 React 教程。在里面我能系统地学到一些 React 相关的知识,或者课程中会用到的 JavaScript 的基础等。

Joy of React 课程介绍页
The Joy of React 的课程封面

这门课程对我的网站重构项目起了很大的帮助,学习后我弄清楚了一些 React 的运行规则,也确实做出了一些实用的组件,改进了页面的代码质量。之前一直卡住的、很具体的问题也在学习之后得到了解决。

这份 $50 左右的课程干货满满,作者也很用心地安排了每个章节会有互动性的练习,也会附带一些视频解说(有 CC 字幕和视频摘要)。后续我可能会出一篇文章来回顾下我在这个课程内学到的内容,记录下这段激情澎湃的青葱岁月。

请教专业人士

好吧,如果有些问题确实难搞,自己用尽所有的方法都没法解决,同时也在这个问题上耗费了很长时间的时候,我会咨询一些前端工程师朋友。

工作几年我一直和前端工程师的关系都也还行,所以有时候问到些问题他们也乐意帮我解答(还因为我的问题在他们眼里其实非常基础…)。

除了现实中认识的朋友以外,其实也可以咨询网络上的一些开发者。如果一个开发者将他的经验分享出来后,其他人使用过程中遇到问题,大部分都乐意帮忙解决的。

联系两位站长后帮忙解决问题的邮件

未完待续…

这一篇文章记录了重构我的个人网站 LRD.IM 时的经历,计划后面会有多几篇文章来记录具体我做到某个模块时的一些过程,或者说重构之后一些我认为比较有意思的改良等等,算是给这次重构计划一个交代。

本文于 2023 年 02 月 21 日首发于 LRD.IM
❌