鐵人檔案
從 UI/UX 設計師轉職前端工程師後，我才發現「看得懂語法」和「看得懂一整段程式在做什麼」是完全不同的事。
這個系列會從跨領域初學者的角度出發，整理我從 JavaScript、React 到實際專案開發過程中，如何學會拆解程式流程、追資料來源、理解 State、Props、Component、API Request / Response，以及遇到問題時如何一步步 Debug。
文章會搭配簡單範例與匿名化的實務案例，不追求一次塞進大量語法，而是希望建立一套「程式碼該怎麼讀、問題該怎麼拆」的思考方式，也記錄我從 UI/UX 麻瓜一路學習工程開發的過程。
開始接 API 之後，我很常看到這些判斷： value ?? "-" value || "-" data?.cust...
上一篇講到： undefined null "" 0 看起來都像「空」，但其實意思完全不同。 而這件事到了表單送 API 時，會直接影響資...
前幾天我們一路講到： null undefined "" 0 false 這些值在 JavaScript 裡看起來都很容易被歸類成： 「...
前一篇講到： ?. ?? || ? : 其中 ?. 很常跟 API Response 一起出現。 例如： data?.customer?.name 以前我看...
上一篇講到巢狀資料： data?.customer?.name 也提到一個很常見的情況： API 回來的資料結構，不一定剛好就是 UI Component...
前幾天我們看到： map() 是在把一份 Array 轉成另一份新的 Array。 接下來在 React 和實際專案裡，又很常看到： [...items]...
上一篇講到： [...items] 以及： { ...data } 它們常常被用來建立新的 Array 或 Object。 到了 React 裡，這種寫法更...
上一篇講到 React State 更新時，我們會盡量建立新的 Array / Object。 但只要開始 Render List，很快又會看到另一個幾乎無所不...
前 18 天，我們一路從： 資料在哪裡？ ↓ State / Props ↓ Component ↓ useEffect ↓ useRequest ↓ API...
上一篇講到： API 重複 Request，不一定是 API 本身有問題，也可能是 Component 一直被 remount。 今天來看一個剛好相反的狀況...
