Drafts

Framework 概要 打造 framework 的動機？ 想解決什麼問題？ 做法評估 打造 framework 的動機？ 升版導致內容壞掉 製作內容不友善 想解決什麼問題？ TODO: 做法評估 問題 framework 的做法如果是整包 Worlds codebase 都打包進去則會增加整體內容打包的大小，是否考慮提供多版本並存的 Worlds runtime 環境，為每個發布的內容標記所使用的 Worlds 版本，runtime codebase 由 Worlds 負責 host 就好？不用每個 content 都把 worlds 包進去 (降低存放空間壓力、成本?) 模組部分保留在平台，而不是每一個模組都做成靜態 publish 的模組對象指向 cdn 需要跟其他前端框架整合嗎？ 例如 react？ 預期 framework 使用方式為何？ 挑戰 & 限制 架構是綁定的 // PlayCanvas 強制的 ECS 模式 var entity = new pc.Entity(); entity.addComponent('render'); entity.addComponent('script'); // 你無法改變這個基本結構 // 所有自定義功能都必須透過 Component 或 Script 實現 限制：...

成為團隊的領導者 概要 為何要成為領導者 影響力更大、能傳遞理念 生產力更大 薪水提升 成為領導者的挑戰 要去銷售自己想法 - 要有主張，不能沒想法 對形勢的掌握 要有產品的思維 人際關係的挑戰 怎麼預備 ？ sharing time 分享 Principles, Best Practices 分享技術新知 分享專案遇到問題 訂下 rules coding convention AI tools rules 專案程式碼 & 流程優化 CI/CD 優化 -> 整合到 release note 主導重構項目 code review 先用 AI 做一遍，確定符合 convention 敏感度培養 協助團隊之間合作溝通，不要讓任何一個人被 blocking 住 code base 降低 deps 依賴 -> 例如不要被 avatar SDK block member 之間 1.1

重點 單向資料流 (one-way data flow) 資料由上往下傳遞 狀態權責 (父或子層) 元件設計五步驟 1. 將 UI 拆分成 Component 👉 Programming (遵守單一職責原則 (SRP)) 單一職責原則 (Single Responsibility Principle) 👉 CSS (依照 selectors 區分) 👉 Design (依照設計圖分層區分) (若 JSON 資料的結構良好，通常能直接映射到相對應的 Component) 2. 建立一個靜態版本的 Component (沒有任何互動功能) 3. 設計異動最小但最完整的 state (有些 state 是不必要的，靠 props 傳遞即可，不需要再宣告一次 useState 來裝載 props) 4. state 要放哪裡？ (當有多個子 component 需要共用 state，則 state 必須往上提升到父 component 管理 (Lifting State Up)) 5. 反向數據流 (子層改變父層狀態) 參考規範 基礎規範 JS Sweetness

一個 類/模塊/元件 應該有且只有一個改變的原因。 (如果使用到多於一個的動機去改變一個 類/模塊/元件，那麼這個 類/模塊/元件 就具有多於一個的職責，不符合 SRP 原則) Component const getTitle = ({ type, title }) => { switch (type) { case 'a': return 'A'; case 'b': // ❌ 控制項變成兩個 if (title) return `B-${title}`; else return 'B'; case 'c': return 'C'; default: return null; } }; const getContent = (type) => { switch (type) { case 'a': return '是否刪除該筆資料？'; case 'b': return '是否更新該筆資料？'; case 'c': return '請確認內容無誤。'; default: return null; } }; const getActions = ({ type, actions, onConfirm, onCancel }) => { switch (type) { case 'a': case 'b': return ( <div> {actions....

Switch-case to Object // ❌ 過多無謂的判斷及重新復賦值 const getDay = (type) => { let day = null; switch (type) { case 0: day = 'Sunday'; break; case 1: day = 'Monday'; break; case 2: day = 'Tuesday'; break; case 3: day = 'Wednesday'; break; case 4: day = 'Thursday'; break; case 5: day = 'Friday'; break; case 6: day = 'Saturday'; break; default: break; } return day; }; // ✅ 變得更一目了然、簡單明瞭 const days = { 0: 'Sunday', 1: 'Monday', 2: 'Tuesday', 3: 'Wednesday', 4: 'Thursday', 5: 'Friday', 6: 'Saturday', 7: 'Sunday', }; const getDay = (type) => { return days[type] || null; }; Default parameters // ❌ 預設參數不為最後一個 function getPassword(account, name = '', id) { // do something } // ❌ 若預設參數不為最後一個，則可能會有這種程式碼出現 (bad) getPassword(account, undefined, id); // ✅ 保持預設參數為最後一個的習慣 function getPassword(account, id, name = '') { // do something } // ✅ 若為最後一個，則可以避免剛才那種程式碼出現 (good) getPassword(account, id); Multiple parameters // ❌ 若過多個參數須控制，則會造成閱讀上的困難 function getPassword(account, id, name, birthday, sex, phone) { // do something } // ❌ 呼叫此 function 時，會需要數第幾個 getPassword(acc, id, roleName, roleBirthDay, roleSex, rowPhone); // ✅ 建議超過 3 個就改為物件 function getPassword({ account, id, name, birthday, sex, phone }) { // do something } // ✅ 呼叫此 function 時，也不需要數第幾個，名稱直接對應 getPassword({ account, id, name, birthday, sex, phone });

component 保持頂層 (Top-Level) 宣告 // ❌ const App = () => { const Container = ({ children }) => <section>{children}</section>; const Button = ({ onClick }) => <button onClick={onClick}>Click Me!</button>; const handleClick = () => { // do something... }; return ( <Container> <Button onClick={handleClick} /> </Container> ); }; // ✅ const Container = ({ children }) => <section>{children}</section>; const Button = ({ onClick }) => <button onClick={onClick}>Click Me!</button>; const App = () => { const handleClick = () => { // do something....