最近看到滿多年輕學生、考慮轉職者提問:未來 ChatGPT 會取代軟體工程師嗎? 看來這個議題已經造成不少 IT 領域學生的焦慮,我非常驚訝,讓我簡單談論一下這件事 # 個人經驗回顧 我在畢業前全心學習 web 前端與後端開發,2012 年畢業時,正逢智慧型手機快速發展,所有公司都在思考如何開發手機 app 來創造新機會,當時媒體的主要論述是:「web 已死!web 工程師都將失業,未來是 mobile app 的世界!」 當時年輕的我,看到這些媒體這樣分析,也是有點焦慮,但同時又有點不服氣,所以依然 100% 心思在研究 web 開發,不管媒體怎麼看衰。現在,10 年過去了,請問 web 職缺消失了嗎? # 媒體的習慣、網紅 YTer 的習慣 想像你住在一個非常小的島嶼國家上,往外走一下就看到海,國家全年365天基本沒什麼大事,每天就是太陽升起、太陽落下。如果你是島上的「新聞從業人員」,請問你每天能做什麼?你當然只能誇大你看到的每件事情。 看到海水漲潮,發新聞:「海水異常上漲!恐有釀禍危機!全國一半人口恐有水災、死亡風險!」 看到海水退潮,發新聞:「近三年最低點!海水不斷消退、國家水資源流失、重大警訊!我國恐成大型沙漠!」 世界上大多數事情本就「帶有波動性」,一下狀況好一下狀況壞,潮起又潮落,正如月有陰晴圓缺,這相當正常。 媒體、網紅,基本上需要吸引人們關注來過活,他總不能每天發新聞:「今天海水正常漲潮,沒什麼特別的。」、「今天海水退潮了,這很自然,不太重要。」 身為現代公民,你要有能力透過媒體吸收新知,但同時也要有能力保持冷靜、自行判斷,不要隨意被影響。你要能看出各種觀點背後相關的利益。 # AI 對職缺的影響 AI 當然對各行各業會有重大衝擊,但是目前也僅止於改善工作效率、優化流程而已。 AI 因為可以加強專業人員的生產力,所以會造成職缺變少一點,但要到「軟體工程師通通失業」、「就靠機器人寫完所有程式」這種程度,實在太誇大了 最後,程式設計已經是各種工作領域之中,最難被機器取代的職缺之一,如果真的被高階人工智能取代,那社會上已經沒有多少工作適合人做,大概會是「無條件基本收入」制度之類的社會 --- # 結論 太廢的技能、感覺問 google 或問 ChatGPT 就有的東西,可以不用學了,像死背課文一樣的任務再也不用做了 除此之外,該學什麼學什麼,不用想太多 上個時代,懂得善用 google 與網際網路的專業人士 vs 不懂得善用的專業人士,生產力有巨大差別 下個時代,懂得善用 AI 的專業人士 vs 不懂得善用的專業人士,生產力有巨大差別 除此之外,跟案主溝通、釐清功能規格、分析各種技術選擇、認識領域知識並設計軟體,是極度複雜的工作,你真的覺得一個機器人放在面前聊天幾分鐘,它就能通通做完給你? --- 以上,簡單看法分享
`React.StrictMode` 是一個好用的元件,用於突出顯示應用程式中的潛在問題。就像 `<Fragment>` 一樣,`<StrictMode>` 不會渲染任何額外的 DOM 元素。在這篇文章中,我們將深入探討什麼是嚴格模式、它是如何運作的,以及為什麼你應該考慮使用看看。 原文出處:https://dev.to/codeofrelevancy/what-is-strict-mode-in-react-3p5b --- ## 什麼是 React 中的嚴格模式? 嚴格模式是一組開發工具,可幫助您在程式碼中找到潛在問題。當您在 React 應用程式中啟用嚴格模式時,您實際上是在告訴 React 打開一堆額外的檢查👀 和警告,以便幫助您寫出更好的程式碼。這些檢查和警告可以捕獲以下內容: 1. 有副作用的元件 2. 已棄用或不安全的生命週期方法 3. 某些內置函數的不安全用法 4. 列表中的重複鍵  --- ## 啟用嚴格模式 在 React 應用程式中啟用嚴格模式非常簡單。您可以通過在主 `index.js` 文件中加入一行程式碼來實現: ``` import React from 'react'; import ReactDOM from 'react-dom'; ReactDOM.render( <React.StrictMode> <App /> </React.StrictMode>, document.getElementById('root') ); ``` ## 為應用程式的一部分啟用嚴格模式 您還可以為應用程式的任何部分啟用嚴格模式: ``` import { StrictMode } from 'react'; function App() { return ( <> <Header /> <StrictMode> <main> <Sidebar /> <Content /> </main> </StrictMode> <Footer /> </> ); } ``` 在這種情況下,嚴格模式檢查不會針對“頁首”和“頁腳”元件執行。但是,它們將在 `Sidebar` 和 `Content` 以及它們內部的所有元件上執行,無論它有多深層。 --- ## 嚴格模式只影響開發環境 請務必注意,嚴格模式對 React 應用程式的正式環境建置沒有影響。嚴格模式啟用的任何檢查或警告都不會出現在用戶看到的應用程式最終版本中。除此之外,嚴格模式會打開額外的檢查和警告,它可能會減慢您的開發環境速度。  --- ## 嚴格模式可以幫助你捕捉細微的錯誤 有時 React 應用程式中的錯誤可能很難追踪,特別是諸如 race conditions 或對元件狀態的不正確假設等細微問題。啟用嚴格模式的額外檢查和警告,您可以在這些錯誤導致嚴重問題之前發現它們。 --- ## 嚴格模式可以幫助您了解最新的最佳實踐 React 是一個快速發展的框架,最佳實踐會隨著時間而改變。啟用嚴格模式並留意它提供的警告和建議,您可以確保您的 React 程式碼遵循當前的最佳實踐。例如在渲染列表時使用 key 屬性,或者在 render() 中避免副作用。 --- ## 儘早發現潛在問題 嚴格模式可以在您的程式碼中發現可能在未來引起的問題,以免它們成為嚴重問題。比方說,它可以檢測並警告已棄用的生命週期方法以及對不再推薦的 [findDOMNode()](https://react.dev/reference/react-dom/findDOMNode) 的存取。   --- ## 防止常見錯誤 啟用嚴格模式,您可以避免一些隱晦的常見錯誤,例如:直接修改狀態而不是使用 setState()、使用未宣告變數。 --- ## 辨識不安全的生命週期 React Strict Mode 可以幫助辨識元件中不安全生命週期方法的使用。例如,它可以警告您使用 `componentWillUpdate` 和 `componentWillReceiveProps` 方法,這兩種方法都被認為是不安全的,將在 React 的未來版本中被刪除。  假設您有一個元件,它使用 `componentWillReceiveProps()` 來根據傳入的 props 更新其狀態: ``` class BlackMamba extends React.Component { constructor(props) { super(props); this.state = { venom: props.venom }; } componentWillReceiveProps(nextProps) { this.setState({ venom: nextProps.venom }); } render() { return <div>{this.state.venom}</div>; } } ``` 在常規模式下,該元件會按預期工作,但在“React.StrictMode”下,您會在控制台中看到一條警告: > 警告:BlackMamba 使用 `componentWillReceiveProps`,這被認為是一種不安全的生命週期方法。請使用靜態的 getDerivedStateFromProps 。 --- ## 過時的字串引用 API 用法 嚴格模式還可以警告您過時的字串 `ref` API 的使用。該 API 已被官方棄用。您應該使用更安全、更易於使用的 `createRef` API。  比方說,您有一個元件使用這樣的字串引用: ``` import { Component } from "react"; import { createRoot } from "react-dom/client"; class BlackMamba extends Component { componentDidMount() { this.refs.venom.focus(); } render() { return ( <> <h1>Black Mamba</h1> <input ref="venom" /> </> ); } } const root = createRoot(document.getElementById("root")); root.render(<BlackMamba />); ``` 您不會在控制台中看到任何錯誤。  當您像這樣在您的應用中啟用“React.StrictMode”時: ``` import { StrictMode, Component } from "react"; import { createRoot } from "react-dom/client"; class BlackMamba extends Component { componentDidMount() { this.refs.venom.focus(); } render() { return ( <> <h1>Black Mamba</h1> <input ref="venom" /> </> ); } } const root = createRoot(document.getElementById("root")); root.render( <StrictMode> <BlackMamba /> </StrictMode> ); ``` 您會在控制台中看到如下所示的警告: > Warning: A string ref, "venom", has been found within a strict mode tree. String refs are a source of potential bugs and should be avoided. We recommend using useRef() or createRef() instead. Learn more about using refs safely here: https://reactjs.org/link/strict-mode-string-ref  讓我們用 `createRef` API 修復它: ``` import { StrictMode, Component, createRef } from "react"; import { createRoot } from "react-dom/client"; class BlackMamba extends Component { constructor(props) { super(props); this.venom = createRef(); } componentDidMount() { this.venom.current.focus(); } render() { return ( <> <h1>Black Mamba</h1> <input ref={this.venom} /> </> ); } } const root = createRoot(document.getElementById("root")); root.render( <StrictMode> <BlackMamba /> </StrictMode> ); ``` 修理完成!  --- ## 過時的 Context API [舊版 Context API](https://legacy.reactjs.org/docs/legacy-context.html) 在 React 中已棄用,已被新的 Context API 取代。 React Strict Mode 可以幫助您檢測過時的 Context API 的任何使用情況,並鼓勵您切換到 [新 API](https://react.dev/reference/react/useContext)  --- 如果您還沒有使用嚴格模式,那絕對值得使用看看! 以上簡單分享,希望對您有幫助!
## 課程目標 - 認識 Lifecycle Hooks 與 Watchers ## 課程內容 來認識一下 Lifecycle Hooks - https://vuejs.org/guide/essentials/lifecycle.html 簡單來說,在 vue 執行階段,又可分為 `mounted` `updated` `unmounted` 等等,將近十個時間點 根據應用程式的需要,可以在這十個時間點,進行必要的檢查&執行特定任務 但是,實務上,除了 `mounted` 經常用來跑一些初始化任務之外,其餘的時間點,幾乎不會用到 所謂 Lifecycle Hooks 是一個有點過時的觀念!稍微讀一下就好,相關功能大多被 Watchers 取代了 --- 接著就來認識一下 Watchers - https://vuejs.org/guide/essentials/watchers.html 簡單講,在 Vue 中,所謂的 Reactivity 已經很好用了: 「某些變數在更新之後,其他相關變數、以及畫面 UI,會跟著自動更新」 除此之外,還可以進一步使用更進階功能: 「隨時監控某些變數,如果發現它們更新,就執行一些相關的任務」 這些任務我們稱之為 `副作用(side effects)` 關於 side effects 怎麼解釋,是一個比較困難的主題 這邊先不詳談,目前有點困惑沒關係,作業中會讓你練習一下,先有點小感覺就好 ## 課後作業 承接上一課的作業 這一課要來做自動儲存功能 請使用 Watchers 去監聽 `notes` 狀態 每次 `notes` 有更新,就自動儲存到 Local Storage 裡面! 接著,在 `mounted` 裡面檢查 Local Storage 如果有資料,就把資料更新到 `notes` 裡面 如此一來,就完成了自動儲存功能,連儲存按鈕都不用做! --- 提示:普通的 watchers 不夠用,要使用 Deep Watchers 這部份有點難解釋,你先知道:普通的 data 變數型態,例如字串、數字、布林,可以用普通的 watcher 但如果是陣列或物件型態的 data,就要使用 Deep Watchers 先知道這樣就好 --- 做出以上功能,你就完成這次的課程目標了!
## 課程目標 學會基本的 Selector API 用法 學會基本的 `.closest()` 的用法 ## 課程內容 課程到目前為止,要存取元素,都是使用 `document.getElementById` `.parentElement` `.children` 然後上上下下到處爬來爬去、找到目標元素 在網頁結構簡單的時候還好,一旦內容複雜起來,你會發現這樣寫,有點麻煩 其實,在學習 css 的時候,就有一套指定元素的方法了,如果能直接用 css 那套設定樣式的方法,來找到元素,那不是很方便嗎? ``` <div> <div id="wrapper"> 我想跟您說: <p> Hi, <span id="target">早上好</span> </p> <p> Hi, <span>中午好</span> </p> <p> Hi, <span>晚上好</span> </p> </div> </div> ``` ``` document.querySelector('#wrapper p span').style.color = 'red'; ``` 在 jsfiddle 試試看,會發現「早上好」變成紅字了 使用 `.querySelector()` 可以很方便的找到元素!如果找到多個元素,只會回傳第一個元素 接著試試這樣 ``` var spans = document.querySelectorAll('#wrapper p span'); for (span of spans) { span.style.color = 'red'; } ``` 在 jsfiddle 試試看,會發現三塊文字,都變成紅字了 使用 `.querySelectorAll()` 可以很方便的找到多個元素!接著就用陣列來處理即可! 以上兩種用法,是不是比之前的老方法方便許多呢? --- 有件事要提一下,老方法的 `.getElementById()` 只能用在 `document` 物件上 新方法的 `.querySelector()` `.querySelectorAll()` 除了可以用在 `document` 之外,還能用在一般 DOM 元素上喔! ``` var wrapper = document.querySelector('#wrapper') wrapper.querySelector('p span').style.color = 'red'; ``` 所以這樣寫也可以!是不是覺得更彈性、更強大、更好用了呢? 有了這些,可以完全取代 `document.getElementById` 與 `children` 的寫法! --- 接著來看看有什麼新方法可以取代 `.parentElement` 吧 ``` var target = document.querySelector('#target') target.closest('span').style.color = 'red'; ``` ``` var target = document.querySelector('#target') target.closest('p').style.color = 'red'; ``` ``` var target = document.querySelector('#target') target.closest('div').style.color = 'red'; ``` 在 jsfiddle 分別試試看,這三種程式碼,會讓哪些文字變紅色吧! `.closest()` 會回傳第一個找到的「祖先元素」 也就是順序為父元素、祖父元素、曾祖父元素,依此類推,不斷往上尋找,到找到第一個為止 實務上這個函式非常好用,可以完全取代 `.parentElement` 的寫法! ## 課後作業 接續前一課的作業,現在要來重構(refactor)程式碼 所謂的「重構」程式碼,就是程式的功能完全不變,但是讓程式碼更好讀、好維護 --- 請把作業中出現的 `.getElementById()` `.parentElement` `.children` 全部拿掉 通通使用本課教導的函式來改寫 改寫完之後,你會發現,原本的程式碼,如果不看 html,只看 JavaScript,只會看到 parentElement、children、跟一堆索引,到處爬,不知道在幹嘛 而在改寫之後,至少看起來比較像在寫 css 樣式的時候,會用 `span` `li` `button` 這些元素名稱來上下查找元素 光看 JavaScript 程式碼,會比原本好讀一些些! 單看這次作業,可能感覺還好。但在專案很大的時候,你不會想在程式碼看到全是 parentElement、children、跟一堆索引,你會希望有更多額外資訊 你會希望程式碼能更清楚表達:「目前到底是在找什麼元素」。所以實務上都是以新寫法為主的 不過呢,這依然是主觀問題。如果你喜歡整個職業生涯都用老寫法來做,應該也可以。高興就好囉! --- 完成這次重構,你就完成這次的課程目標了!
**舊的 React 文件幾乎沒什麼用,這大家都知道,因為它沒反映該框架的現代用法。在本文中,我們將探索它的新文件並討論它為何很棒。** 原文出處:https://dev.to/diogorodrigues/reacts-new-killer-documentation-focused-only-on-functional-components-jnk --- React Hooks 與 [2019 年初版本 16.8](https://reactjs.org/blog/2019/02/06/react-v16.8.0.html) 一起發布,迅速流行起來並在前端社區中得到廣泛採用。通過這個版本,使用基於類別的元件編寫的複雜性,被有狀態的功能元件所取代。雖然我們可以在文件中找到對這些新功能的很好解釋,但大多數範例都繼續使用類別。 現在,在發生革命性變化 3 年多之後,**React 發布了其文件的 BETA 版本,從其解釋中刪除了類別,專注於使用帶有互動範例的鉤子的現代開發方式。** > “一旦我們與現有的 React 文檔達到內容一致,我們的目標是將此網站切換為主要網站。舊的 React 網站將存檔在一個子域中,因此您仍然可以存取它。舊內容鏈接將重定向到存檔的子域,該子域將有關於過時內容的通知。” - [BETA React 文檔](https://beta.reactjs.org/) _P.S.重要的是,當我寫這篇文章時,新內容幾乎 100% 完成了。_ ## 你可以在新的 React 文檔中找到什麼 雖然這個 React BETA 文檔不是很廣泛,但我不會逐個主題地介紹它,我將在下面重點介紹它的一些主要優點。 ### Quick Start 真的是非常快速的開始 **對我來說,這是改善超多的部分,因為與舊版本不同,現在我們可以通過其文檔中的互動式程式碼範例來使用 React 程式碼。** 這不是很神奇嗎? 一個完整的介紹,非常簡單,解釋清楚,並且不需要為現在開始學習的人設置任何專案。  ### 很好地解釋了使用 React Effects 的最佳方式 就個人而言,我認為**他們為解釋 Effects 所做的工作非常出色。**這確實是我研究了很多的東西,肯定會幫助我使用 React 開發更好的程式碼。 有一些詳盡的頁面展示了[如何停止將 Effects 視為生命週期掛鉤](https://beta.reactjs.org/learn/lifecycle-of-reactive-effects),而是 [Effects 作為與外部系統的同步器](https://beta.reactjs.org/learn/synchronizing-with-effects)。發生這種混淆是因為我們習慣於將使用 useEffect 鉤子的功能組件與基於類別的元件生命週期進行比較,但這不再有意義了。 https://twitter.com/dan_abramov/status/1157250198659354624 **另一個令人驚嘆的內容是 [“你可能不需要 effect”](https://beta.reactjs.org/learn/you-might-not-need-an-effect) 主題,我們可以在其中了解如何刪除不必要的效果**通過許多用例和互動式程式碼示例。您可以在下面的影片中找到關於該主題的精彩摘要。 https://www.youtube.com/watch?v=bGzanfKVFeU&t=742s&ab_channel=BeJS ### 精通狀態管理 我知道這個標題聽起來太冒險了,但是這個 React BETA 文檔有很多內容是關於[如何更好地建置狀態,避免冗餘狀態相關的錯誤](https://beta.reactjs.org/learn/managing-state),等等。 > “良好地建置狀態可以區分一個易於修改和除錯的元件,以及一個經常產生錯誤的組件。” - React 文檔 查看 [管理狀態部分](https://beta.reactjs.org/learn/managing-state) 以及 [Referencing Values with Refs](https://beta.reactjs.org/learn/referencing-values-with-refs) 主題以更好地理解 React 中狀態的使用。 ### 更多你可以在新的 React 文檔中找到的知識 我想強調的其他一些內容是: - [React API 參考](https://beta.reactjs.org/apis/react) 部分包含所有內容,以便更快地諮詢程式碼片段。 - “[聲明式 UI 與命令式 UI 相比如何](https://beta.reactjs.org/learn/reacting-to-input-with-state#how-declarative-ui-compares-to-imperative )”主題展示瞭如何更好地編寫聲明式 React 元件。 - “[Render and Commit](https://beta.reactjs.org/learn/render-and-commit)” 了解渲染 React 元件過程中的步驟。 - “[排隊一系列狀態更新](https://beta.reactjs.org/learn/queueing-a-series-of-state-updates)”主題將解釋為什麼有時它不起作用以及如何解決它. - “[通過自定義掛鉤重用邏輯](https://beta.reactjs.org/learn/reusing-logic-with-custom-hooks)”了解如何在元件之間共享邏輯。 ## 結論 **從基礎主題到進階主題,這些文檔涵蓋了您學習如何使用最好的現代 React 建立用戶界面所需的一切。**如果您是 React 世界的新手,本文檔肯定會對您有很大幫助互動式範例。對於經驗豐富的 React 開發人員,本文檔匯集了幾個重要的進階概念,這些概念一定會幫助您建立更好的 UI 元件。
在 Web 開發世界中,有時感覺就像每天都有新的前端框架問世!大多數來去匆匆,但有一件事是肯定的:Svelte 將繼續存在。 不過,這並不意味著您應該放下一切並在今天學習!追逐最新潮流會讓您分心和不知所措。 這篇文章將一勞永逸地回答:**我應該學習 React 還是 Svelte?**。 您將看到一些程式碼範例,這些範例解釋了為什麼 React 開發人員會為 Svelte 瘋狂,但我們也必須實際一點。 React 已經存在了很長時間。有更多的套件、支援、職缺。 Svelte 還能取代 React 嗎?讓我們找出答案! - 原文出處:https://dev.to/mikehtmlallthethings/svelte-vs-react-which-framework-to-learn-in-2023-50gf --- * 📍 什麼是 React? * 📍 什麼是 Svelte? * 📍 React 和 Svelte 的 5 個區別 * Svelte 的捆綁包尺寸更小 * Svelte 更容易學習 * Svelte 使用純 HTML、CSS 和 JavaScript 進行編譯 * React 有更多的套件 * React 有 React Native * 📍 React 是庫還是框架? * 📍逐行比較 React 和 Svelte 專案 * 📍 Svelte 比 React 快嗎? * 📍 何時從 React 切換到 Svelte * 📍 結論 ### **What is React?** 讓我們從 React 開始。 React 是一個漸進式 JavaScript 前端框架(或函式庫,具體取決於您詢問的對象),可幫助您構建複雜的 Web UI。 它由 Facebook(現為 Meta)於 2013 年創建,能夠很快在前端 Web 開發領域站穩腳跟。 React 的核心是狀態和渲染狀態,這意味著要使用它,您必須添加其他庫來處理客戶端功能和路由。 ### **What is Svelte?** Svelte 也是一個前端 JavaScript 框架,但採用了更加一體化的方法。 Svelte 具有內建的狀態管理、路由和客戶端 (DOM) 功能。  React 需要第三方庫和工具,如 Redux、React Router、JSX,而 Svelte 內建了很多這樣的功能。它不太靈活,但更方便和一致。 它採用更幕後(魔術)風格的方法,它直譯非常基本的 JavaScript 程式碼並為您處理 UI 和狀態管理: ``` <script> let count = 0; function handleClick() { count += 1; } </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? 'time' : 'times'} </button> ``` Svelte 由紐約時報的開發人員 Rich Harris 於 2016 年創建,用於以高效的方式處理複雜的圖表和圖形。它從那裡成長為 React 和 Vue 之類的備受喜愛的競爭對手。 ### **React 和 Svelte 之間的 5 個區別** ### **1。 Svelte 的構建包大小要小得多** 我們在下面構建的相同(功能)應用程序。部署包大小在 React 是 41.2 kB,在 Svelte 是 2.1 kB。這幾乎減少了 **20x** 🤯 為了獲得這些數字,我構建了一個在 Svelte 和 React 中具有相同功能的應用程序。我們將在 React 與 Svelte 代碼分解部分深入研究這些應用程序。  我用 React 和 Svelte 構建了一個相同的應用程序。看看 Svelte 包小了多少! ### **2。 Svelte 更容易學習,因為它的語法簡單** Svelte 採用更幕後的魔術方法,允許您編寫非常少量的樣板或語法糖來完成複雜的綁定。模板語法只是帶有一些額外內容的 HTML,這與 JSX(React 等價物)有很大不同並且更容易學習。 React 變數宣告:  Svelte 變數宣告:  Svelte 看起來像純 JavaScript,但它具有與 React 完全相同的功能。更新 Svelte 變數將自動更新它所在的 UI 元素。 ### **3。 Svelte 符合純 HTML、CSS 和 JavaScript** Svelte 將您編寫的程式碼編譯成基本的 HTML、CSS 和 JavaScript。它不需要像 React 那樣與你的代碼捆綁在一起! React.js 需要存在於一個 bundle 中以完成所有正確的虛擬 DOM 比較和創建,Svelte 不使用虛擬 DOM 來處理 UI。相反,它選擇了基本的 JavaScript 元素創建函數,例如 document.createElement。 ### **4。 React 擁有更多為它構建的庫和包** React 已經存在了 3 年多,也是目前 JavaScript 框架事實上的王者👑。正因為如此,它擁有大量用戶和公司創建的軟件包。 用戶創建的包通常只是為了使路由和狀態管理更容易,或者添加滑塊、燈箱等。這些並不重要,因為 Svelte 具有可靠的選項,並且兼容/適應大多數 JavaScript 套件。 有點困難的是,要跟任何其他框架之前創建的 React 套件整合時不容易。我在 Solana 和以太坊上從事 Web3 專案時經常遇到這個問題。 ### **5。 React 有 React Native** React Native 是使用率最高和受支持最多的跨平台框架之一。它提供了使用 React 創建 iOS 和 Android 應用程式的能力。全部來自同一個代碼庫。由於其成熟度,它擁有大量的庫、支援和學習資源。 儘管有 Svelte 的替代方案,例如稱為 Svelte-native 的 NativeScript 改編版,但它們不具有與 React-native 相同的可靠性和功能。 ### **React 是函示庫還是框架?** 儘管 React 通常被稱為框架,但可以說,由於其範圍,它更像是一個函式庫。它專門負責管理 UI 的狀態並使其與應用程式中的資料狀態保持同步。 因此,它需要第 3 方函式庫來處理應用程式路由 (React Router)、UI 創建 (JSX) 和元件之間的狀態管理 (Redux)。 另一方面,Svelte 內建了上述所有功能,因此更像是一個完整的 UI 管理解決方案。 你可以看到大多數人都同意這是一個函式庫,但仍有一些爭論👇 https://twitter.com/htmleverything/status/1597574223148765185 ### **逐行比較 React 和 Svelte 專案** 比較兩種 Web 技術的最佳方法是深入研究並使用它們進行構建。構建完全相同的應用程序有助於了解每個庫/框架如何處理不同的功能。 讓我們看看: * 條件渲染 * 模板循環 * 更新狀態 * 事件掛鉤 ### **我們在建造什麼?** 編碼是一項口渴的工作,因此我們將構建一個簡單的網絡應用程序,允許用戶跟踪他們全天喝了多少杯水(或🍺)。 額外的好處是顯示每杯喝醉的歷史和時間。 我們將保持 UI 簡單,以更多地關注底層框架。 (見下面的用戶界面) https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark ### **React** 為了分解代碼,首先讓我們深入了解一些 React 概念和術語👇 React 有幾種類型的語法你需要學習。鉤子、狀態和模板 (JSX) 是主要的。 鉤子 - 允許您進入應用程序的生命週期 State - 允許您根據數據的變化更新 UI 元素。它將“狀態”(或更簡單的變量)更改與 UI 更新聯繫起來 模板 - 允許您直接在 HTML 中使用變量和 JavaScript React 組件的樣式通常由單獨的 .css(或 .scss)文件處理。 ### **React 代碼分解** https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark&view=editor 變數是使用 useState 掛鉤設置的,它允許更新變量並讓 UI 動態呈現這些更新。 `useEffect` 用於在加載應用程序時設置今天的日期。 JSX 模板使用基本的“{}”符號以及 HTML 中的標準 JavaScript 函數,允許顯示變量和循環數組(使用“.map”)。 ### **Svelte** Svelte 採用不同的方法,採用更“幕後魔術”的風格。邏輯看起來很像純 JavaScript。在後台,代碼做的事情幾乎與 React 代碼做的一樣。 Svelte 仍然有像 `onMount` 和 `onDestroy` 這樣的鉤子,但是簡單地分配一個變量並讓它完全響應並在模板 (HTML) 中可訪問不需要任何特殊的語法糖。 另一個很大的區別是您可以直接在 Svelte 組件中編寫 CSS/SCSS。這只是一個選項,因為您仍然可以像在 React 中一樣導入樣式,但我注意到大多數 Svelte 項目都使用樣式內組件。 ### **Svelte 代碼分解** https://codesandbox.io/embed/svelte-water-example-scrimba-2vsoid?fontsize=14&hidenavigation=1&module=%2FApp.svelte&theme=dark&view=editor 上面的代碼實例化了一個 cupsOfWater 數組,將新的日期變量設置為當前日期。 聲明一個函數來創建一個新日期並將其存儲在一個名為 cup 的變量中,然後將其添加到 cupsOfWater 數組中。 模板部分更接近 HTML 並增加了一些功能。再次使用“{}”表示法,您可以從“<script>”部分引用任何聲明的變量。您還可以使用事件偵聽器(如 `on:click`)、條件(如 `{#if}`)和使用 `{#each}` 循環。 ### **Svelte 比 React 快嗎?** 是的,從快速的 HTML 生成到更快的構建和開發環境,Svelte 的性能都大大優於 React。 * 生成 HTML * 根據狀態更新 UI * 第一次內容豐富的渲染 * 互動時間 * 速度指數 所有這些都看到了可衡量的差異,而 Svelte 具有優勢。您的應用程序越大越複雜,差異就越明顯。 在 Zeitspace 的一篇文章中可以看到性能比較 https://www.zeitspace.com/blog/we-built-an-app-with-svelte.-heres-what-we-learned ### **Svelte 比 React 好嗎?** 當開始一個新專案時,Svelte 有足夠的優勢,它應該始終是一個考慮因素。 話雖如此,React 在使用率方面仍然絕對勝過 Svelte。這可能會導致專案的第 3 方插件支持、僱用和壽命問題。 不過,為了應對這一點,Svelte 語法的易用性使其非常容易上手,尤其是對於 React 開發人員而言。這是公司在招聘 Svelte 項目時可以藉鑑的東西(不要將自己局限於 Svelte 開發人員)。 ### **何時從 React 切換到 Svelte** Svelte 是構建複雜網站或 Web 應用程序的絕佳選擇。許多老牌公司已經開始將 Svelte 用於內部和外部應用程序: * 1Password * Avast * Chess.com * Alaska Airlines * Fusion Charts * Rakuten * GoDaddy * IBM * Square * 紐約時報 * 飛利浦 但這並不意味著您必須將當前的 React 應用程序放入垃圾桶! 那麼什麼時候是接觸 Svelte 的合適時機? 如果您的應用/網站: * 由於頻寬限制,需要較小的包大小 * 需要盡可能快 * 需要快速建造 When is not the right time to reach for Svelte? 什麼時候不適合使用 Svelte? 如果您的應用/網站: * 嚴重依賴第 3 方集成/工具 * 需要轉換為移動應用程序 這些很快就不會成為問題,但在投入之前確實需要進行一些研究和盡職調查。 ### **結論** 建議投入其中並嘗試在 Svelte 中構建一些東西。如果你來自 React,我幾乎可以向你保證你會喜歡它的簡單性和速度。
JavaScript 寫起來有很大彈性,但如何改善自己的 JavaScript 品質呢?以下是一份實用的參考指南。 - 原文出處:https://dev.to/taillogs/practical-ways-to-write-better-javascript-26d4 # 使用 TypeScript 改善 JS 的第一個技巧就是,不要寫 JS。寫 TypeScript 吧。它是微軟寫的一個語言,算是 JS 的母集合(一般的 JS 可以直接在 TS 裡面跑)。TS 在 JS 之上添加了一個全面的型別系統。長期下來,整個前端生態系,幾乎都支援 TS 語言了。下面介紹一下 TS 的優點。 **TypeScript 可以確保「型別安全」** 型別安全代表編譯器驗證了所有型別是否以「合法」的方式被使用。換句話說,如果你創建一個接受「數字」的函數 `foo`: ``` function foo(someNum: number): number { return someNum + 5; } ``` 該「foo」函數呼叫時要傳一個數字: 正確用法 ``` console.log(foo(2)); // prints "7" ``` 錯誤用法 ``` console.log(foo("two")); // invalid TS code ``` 除了需要花時間加型別以外,沒有其他缺點了。好處則是顯而易見。型別安全針對常見錯誤提供了額外預防,這對於像 JS 這樣鬆散的語言來說,是一件好事。 **TypeScript 的型別系統,讓你能重構大型應用程式** 重構大型 JS 應用程式是一場噩夢。主要是因為它不會檢查函數簽名。也就是說,JS函數隨便呼叫,編譯器都不會先報錯。舉個例,如果我有一個函數「myAPI」,由 1000 個不同的服務使用: ``` function myAPI(someNum, someString) { if (someNum > 0) { leakCredentials(); } else { console.log(someString); } } ``` 我稍微更改了呼叫簽名: ``` function myAPI(someString, someNum) { if (someNum > 0) { leakCredentials(); } else { console.log(someString); } } ``` 我必須自已 100% 去確認,使用此功能的1000 個地方,都有正確更新用法。漏掉的地方,在執行時就會壞掉。在 TS 中相同的情境如下: before ``` function myAPITS(someNum: number, someString: string) { ... } ``` after ``` function myAPITS(someString: string, someNum: number) { ... } ``` 如您所見,「myAPITS」函數跟在 JavaScript 中一樣修改。但是,這段程式碼無法順利產出 JavaScript,而是會出現無效 TypeScript 的錯誤提示,因為用到它的1000個地方,現在型別就出錯了。正是因為「型別安全」,這 1000 個案例會阻止編譯。 **TypeScript 使團隊溝通架構更容易** 正確設定 TS 後,要先定義介面跟類型,不然很難寫程式碼。這也順便提供了一種簡潔、可溝通的架構提案方法。例如,如果我想跟後端提出新的「請求」類型,可以使用 TS 將以下內容提交給團隊。 ``` interface BasicRequest { body: Buffer; headers: { [header: string]: string | string[] | undefined; }; secret: Shhh; } ``` 雖然也是要寫一點程式碼,但可以先提供以上內容作為初步想法、取得回饋,而不用一次設計完功能。像這樣強迫開發者先定義介面跟 API,能讓程式碼品質更好。 總體而言,TS 已經發展成為一種成熟且更可預測的 vanilla JS 替代品。當然還是要熟 JS,但我現在大多數新專案都是直接寫 TS。 # 使用現代功能 JavaScript是世界上最流行的程式設計語言之一。你可能會以為這語言已經被百萬開發者摸透了,其實不是。很多新功能是近期才加上去的。 **`async` 與 `await`** 長期以來,非同步、事件驅動的 callback 是 JS 開發中不可避免的: 傳統 callback ``` makeHttpRequest('google.com', function (err, result) { if (err) { console.log('Oh boy, an error'); } else { console.log(result); } }); ``` 上述程式碼會有越寫越多層的問題。JS 添加了一個新概念叫 Promises,可以避免嵌套問題。 Promises ``` makeHttpRequest('google.com').then(function (result) { console.log(result); }).catch(function (err) { console.log('Oh boy, an error'); }); ``` 與 callback 相比,Promise 的最大優勢是可讀性和可鏈性。 雖然 Promise 很棒,但它們仍然有一些不足之處。寫起來感覺有點怪。為了解決這個問題,ECMAScript 委員會添加一種使用 promise 的新方法,`async` 和 `await`: `async` 與 `await` ``` try { const result = await makeHttpRequest('google.com'); console.log(result); } catch (err) { console.log('Oh boy, an error'); } ``` 需要注意的是,`await` 的內容必須先被宣告為 `async`: 以前面 makeHttpRequest 舉例 ``` async function makeHttpRequest(url) { // ... } ``` 也可以直接 `await` 一個 Promise,因為 `async` 函數實際上只是 Promise 比較花哨的包裝寫法。這也意味著,`async/await` 代碼和 Promise 代碼在功能上是等價的。因此,請大方使用 `async/await` 吧。 **`let` and `const`** 以前大家寫 JS 都只能用 `var`。`var` 的變數作用域有一些獨特規則,一直讓人很困惑。從 ES6 開始,有了 `const` 跟 `let` 可以替代使用,幾乎不用再寫 `var` 了。 至於何時要用 const 何時要用 let 呢?永遠從 const 先開始使用。const 因為不可修改、更可預期,會讓程式碼品質更好。使用 let 的場景比較少,我寫 const 的頻率比 let 高 20 倍左右。 **箭頭 `=>` 函數** 箭頭函數是在JS中宣告匿名函數的簡潔方法。通常作為 callback 或 event hook 傳遞。 傳統的匿名 function ``` someMethod(1, function () { // has no name console.log('called'); }); ``` 在大多數情況下,這種風格沒有任何“不對”。但它的變數作用域很“有趣”,常導致許多意想不到的錯誤。有了箭頭函數之後,就沒這問題了。 匿名箭頭函數 ``` someMethod(1, () => { // has no name console.log('called'); }); ``` 除了更簡潔之外,箭頭函數還具有更實用的變數範圍界定。箭頭函數從定義它們的作用域繼承「this」。 在某些情況下,箭頭函數甚至可以更簡潔: ``` const added = [0, 1, 2, 3, 4].map((item) => item + 1); console.log(added) // prints "[1, 2, 3, 4, 5]" ``` 箭頭函數可以包括隱式的「return」語句。就不用寫大括弧、分號。 不過,這跟“var”被完全取代不同。傳統匿名函數仍然有需要的地方,例如類別方法定義。話雖如此,如果你總是預設使用箭頭函數,程式碼錯誤會少很多。 **展開運算子 `...`** 提取一個物件的鍵/值對,並將它們添加為另一個物件的子物件,是一種很常見的場景。從歷史上看,有幾種方法可以實現,但通通都很笨拙: ``` const obj1 = { dog: 'woof' }; const obj2 = { cat: 'meow' }; const merged = Object.assign({}, obj1, obj2); console.log(merged) // prints { dog: 'woof', cat: 'meow' } ``` 這寫法以前很常見,也很囉唆。多虧了「展開運算子」,再也不需要那樣寫了: ``` const obj1 = { dog: 'woof' }; const obj2 = { cat: 'meow' }; console.log({ ...obj1, ...obj2 }); // prints { dog: 'woof', cat: 'meow' } ``` 最棒的是,與陣列也可無縫接軌: ``` const arr1 = [1, 2]; const arr2 = [3, 4]; console.log([ ...arr1, ...arr2 ]); // prints [1, 2, 3, 4] ``` 它可能不是近期 JS 中最重要的功能,但它是我的最愛之一。 **範本文字(範本字串)** 字串處理太常見了,程式語言要能處理範本字串,才夠好用。處理動態內容、多行文字時,都會需要它: ``` const name = 'Ryland'; const helloString = `Hello ${name}`; ``` 我認為程式碼不言自明。看起來好多了。 **物件解構** 物件解構是一種從資料集合(物件、陣列等)中提取值,而無需反覆運算數據或顯式訪問其鍵的方法: 老方法 ``` function animalParty(dogSound, catSound) {} const myDict = { dog: 'woof', cat: 'meow', }; animalParty(myDict.dog, myDict.cat); ``` 新方法 ``` function animalParty(dogSound, catSound) {} const myDict = { dog: 'woof', cat: 'meow', }; const { dog, cat } = myDict; animalParty(dog, cat); ``` 不只這樣。您還可以在函數的簽名中定義解構: 解構範例二 ``` function animalParty({ dog, cat }) {} const myDict = { dog: 'woof', cat: 'meow', }; animalParty(myDict); ``` 它也適用於陣列: 解構範例三 ``` [a, b] = [10, 20]; console.log(a); // prints 10 ``` --- 以上,希望對您有幫助!
Javascript 是一個很棒的程式語言,但是,要寫出乾淨的 javascript 程式碼可不簡單,即便是資深工程師也一樣。 乾淨的 JavaScript 程式碼該長怎樣?它應該要: - 易於閱讀 - 易於測試 - 高效和高性能 以下是您可以使用的優質工具和技巧,可將您的 Javascript 功力提升到全新水平: - 原文出處:https://dev.to/alexomeyer/8-must-know-tips-for-writing-clean-code-with-javascript-i4 # 1. 對所有 api 請求和 JSON 方法使用 try catch 發出 api 請求來撈資料時,許多事情都可能出錯,因此必須注意這些情況。在處理 JSON 時,不要自動信任拿到的資料格式,請試著處理可能出乎意料的格式,來讓您的程式碼更健壯。  # 2. 使用 linter (ESLint) linter 是一種靜態程式碼分析工具,可根據一組預定義的規則和配置檢查程式和風格錯誤。簡而言之,它將改進您的 Javascript/Typescript 程式碼品質,並讓風格更加一致。 # 3. 在編輯器中追蹤 Javascript issues 保持 Javascript 程式庫簡潔的一個重要方式,是能夠輕易追蹤和查看程式碼本身的問題。在編輯器中追蹤 issues 允許工程師: - 全面了解技術債等更大的問題 - 查看每問題的上下文 - 減少上下文前後查看的頻率 - 持續地處理技術債 您可以使用各種工具來追蹤您的技術債,但最快速、最簡單的入門方法是使用與 Jira、Linear、Asana 和其他專案管理工具整合的 VSCode 或 JetBrains 的免費 Stepsize 外掛。 # 4.使用模板字符串 模板字符串讓您在保留格式的同時將值注入字符串,並且程式碼比字串運算更容易閱讀。  # 5. 需要搜尋字串時,使用正規表示式 正規表示式雖然乍看之下很深奧,但它是非常強大的字串解析工具,允許您建立複雜的模式來解決各種困難的字串配對情境。 # 6. 使用可選串連運算子 停止使用冗長的邏輯運算子,使用可選串連運算子來簡化您的程式碼。  # 7.避免巢狀結構 巢狀結構絕對會增加程式碼的複雜度,也讓它更難閱讀、更難理解。如果深度超過兩層,請考慮重構,改成在根層就有條件回傳、使用更短小的區塊、並將巢狀邏輯抽像化成獨立的函式。 # 8. 替所有特殊程式碼寫註解,但不要讓它取代程式碼可讀性 有時需要針對特殊情境寫專門處理。替這段程式碼寫註解,解釋它的功能與上下文的由來,這對其他工程師幫助會很大。也能幫助未來重讀這段的自己。但讓程式碼本身就很易讀還是最優先,不要習慣用寫註解來偷懶!
本論壇提供「新手友善」的 JavaScript 前端自學教材!
站長獨創「探索式學習法」教材,歡迎來學 JS,一起進入前端開發領域!
本論壇也是「新手友善」的程式設計討論區!
歡迎多多與大家交流、分享、互相打氣、一起學習、一起成長!