Hi!這裡是 Jing Tech 前端技術週報!除了 Substack 電子報外,也可以在筆者的部落格 jing-tech.me 與 instagram: jing.tech 關注前端大小事!
本週的深度閱讀本來想分享 Web Component,但發現要了解這個主題,弄髒自己的手比看完一堆文章還要來得有效,所以本週就花了一點時間在建立專案框架,並且打算以部落格系列文章的形式發佈,之後會在進行分享。而深度閱讀這個區塊則可能會看當週學習了什麼進行代替。
本週熱點與選讀
文章
文內詳細地介紹如何建立一個整潔的 React 應用,涵蓋了組件抽象化、錯誤處理、API 串接與資料型別驗證等主題,很貼近實務上的最佳實踐,非常適合剛接觸 React 的讀者們。
Stop Lazy Loading Product and Hero Images
文章建議不要對首要產品圖片或首圖做懶加載 (Lazy Load),因為這種做法可能會影響 UX 外,也對 LCP 和網頁的效能造成負面影響。文內也提到了一些標準去衡量是否對圖片做懶加載。筆者的公司先前在瀏覽器開始支持loading=lazy
屬性後,也在所有的程式碼的img 元素
加上此屬性,導致一些首圖載入時間變更長,進而影響了用戶體驗和 LCP,直到近期才把它修正回來。Non-code contributions are the secret to open source success
貢獻一個開源程式專案不一定要對程式做貢獻,有時候幫忙加強文檔可讀性、新增測試案例或是修正錯字都是非常好的起手式,如果想要對開源程式碼貢獻但不知道如何下手,非常推薦這篇文章!筆者當初也有在 React 新的文檔剛發佈不久時,剛好看到一個 Typo 並修正它,儘管這對履歷不會有什麼加分效果,但當 PR 被 Approve 時與看到 Dan 在 PR 底下回覆,當下是非常開心的!
On becoming a VP of Engineering
在軟體工程這個領域,前端的天花板相較於後端會來得矮一些,然而這系列文章的作者正式從前端出發一路當到 Honeycomb 的 VP,Honeycomb 公司是一間最近完成 D 輪融資的軟體監控公司,系列目前有兩個部分,第一部分主要是分享他是如何從前端工程師到 VP 的歷程,第二部分則是分享 VP 的日常以及管理團隊的感想。
React Labs: What We've Been Working On – February 2024
前陣子推特上有許多工程師反應 React 當前的問題,其中一點就是資訊沒有完全公開。而這週 React 發布了組織當前的最新狀態,首先是 React Forgot 已經在 Instagram 中進行實驗,並得到不錯的效果,也開始拓展到 Meta 內部的各產品中。React 19 也將在不久後推出,其版本會包含 Server Action、Web Component、Document Metadata (SEO) 等功能!
How To Center a Div - Josh Comeau
Josh Comeau 是筆者非常喜歡的技術部落客,他的文章都非常優質且有許多互動式的範例,這週他發布了新的文章是要如何置中,看似一個簡單的主題,依然可以讓筆者學到不少新的小技巧,也不經讚嘆 CSS 真的演變好多,非常推薦!
這篇文章分別將當前社群最多聲量的網頁開發進行套件簡單介紹與點出其各自的優點,且它們都各自提出方案解決同一個問題,就是網路鴻溝 (network chasm),期待之後這三個套件各自的發展!
Squeezing Last Bit Of JavaScript Performance For My Automation Game
作者是開發遊戲的獨立開發者,這篇文章清楚的紀錄他是如何透過一系列的優化將網頁效能從 21s 減少到 4s,分別從類的建構從 runtime 移出,減少重複建構的時間、將函式做快取、正確的選擇資料結構、以及使用 bitwise flag。
播客
Syntax - CSS Native
@scope
CSS 在這幾年有越來越多好用的新語法,其中 CSS 原生作用域將在不久後被各大瀏覽器支援,在先前我們要做樣式隔離,往往想到的就是 CSS-in-JS, CSS Module - BEM 等,CSS Scope 提供了原生的方式做樣式隔離,基本上用法非常直觀,非常推薦大家理解一下 (MDN)!
隨手記
SQL - Common Table Expression (
WITH .. AS ..
)本週在寫 CMU - Intro to Database System 的第一份作業時,其中有一題是「找出一位名字中包含 Cruise,並且出生於 1962 年的人物,然後確定哪些是他或她最受歡迎的作品」,而 DB 的結構如下
筆者一開始是將 people 與 crew 這兩張表進行 inner join 找出
title_id,在用該 id
inner joinratings 表裡的 title_id,並將 votes 進行降冪排列,最後在
inner join 一次 titles 表,列出前 10 筆最後歡迎的作品SELECT titles.primary_title, rating_cruise_crew.votes FROM titles INNER JOIN ( SELECT ratings.title_id, votes FROM ratings INNER JOIN ( SELECT crew.title_id, people.name, people.person_id FROM people INNER JOIN crew ON people.person_id = crew.person_id WHERE people.born = 1962 AND people.name LIKE "%Cruise%" ) AS cruise_crew ON ratings.title_id = cruise_crew.title_id ) AS rating_cruise_crew WHERE rating_cruise_crew.title_id = titles.title_id ORDER BY rating_cruise_crew.votes DESC LIMIT 10;
寫完之後發現太醜,思考有什麼可以優化的地方,發現可以將 inner join 做展平的動作
SELECT t.primary_title, r.votes FROM titles AS t INNER JOIN crew AS c ON t.title_id = c.title_id INNER JOIN people AS p ON c.person_id = p.person_id AND p.born = 1962 AND p.name LIKE "%Cruise%" INNER JOIN ratings AS r ON t.title_id = r.title_id ORDER BY r.votes DESC LIMIT 10;
相比於第一次寫的結果漂亮不少,就開心的跑去對答案,結果發現解答 (HW 1- Question 6) 執行的速度竟然快了一倍,新手如筆者理解完後,發現使用了 CTE (Common Table Expression),除了提高可讀性之外,資料庫會缓存 CTE 的結果,不會造成重複的計算。
待在 JS 的舒適圈太久,導致已經有一段時間沒有感受到寫法差異造成效率提升的驚喜感,很像是以前在學習 Python 或是 JS 時,每次找到一點可以優化的地方就非常高興,儘管這種優化在有經驗的人眼裡可能是常識,但對筆者來說則是對產生了 AHA 時刻!
本期內容就更新到這裡,感謝大家的閱讀,如果有任何問題或想法歡迎一起討論,也歡迎分享給更多人知道!你的每一份支持,都是我持續創作的動力!更多關於我的創作可以點擊這裡。