上一次的課程，我們學會如何用 Node 開發老派 CLI 應用程式，很好玩吧！ 再次提醒，上次的開發過程，可是跟 `網站` `瀏覽器` `web 伺服器` 完全沒關係的喔！ 之所以這樣課程設計，是為了先幫大家脫離 `js 一定是網頁相關、一定是 html/css 相關` 的刻板印象 現在，我們回頭來碰 backend programming 開發，銜接回來 web 領域看看！ 這樣的學習順序，吸收才順暢，不會各種觀念一直搞混在一起 雖然之前的教材一直是以前端開發為主，但是我認為稍微教一點 Node.js 後端開發，對於前端工程師的能力會有很大幫助！ 上完之後，會更清楚前後端的分工，以及網頁背後的基本概念！ 別擔心，本課只會深入淺出，學習一點基本的後端觀念，不會是艱難、完整的後端課程！ 準備好的話，讓我們馬上開始吧！
收到網友提問如下： ``` 這是最近跟一個朋友聊天聊到的 朋友是寫 .net Framework 的 我剛碰Vue的時候，跟他說我看不懂Vue在背後是怎麼運作的、為什麼這樣寫會變成這樣的結果？ 他跟我說，不用去在意框架背後幫你做了哪些事情 反正就是做那些制式的動作，把功能實現就好 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 這樣真的是好的嗎？ 工程師的等級差距並不在於是否知其所以而不知其所以然嗎？ ``` 這應該是每個年輕工程師都有的疑問，寫一篇完整、公開回答跟大家分享，給類似狀況的人參考。 我先講結論：這取決於你想不想越變越強、不斷提升競爭力，還是只想混口飯吃 如果只想混口飯吃，什麼工具都是學個用法，懶得研究，然後東西做出來交差了事，那可以永遠不去管工具背後原理 不過，這種心態，職涯成長、薪水成長空間會很有限，然後在 40 多歲的時候會有「中年危機」，會很慘、壓力很大 因為屆時新工具你跟年輕人一樣不太會用，舊有的經驗又幫不上忙，因為你從來不肯學背後通用的觀念 回到問題本身，我認為有兩件事情值得分享，有兩個觀點你需要去權衡，我們先談談「抽象」 # Abstraction 抽象 軟體工程師的主要工作就是「抽象化」，把各種邏輯分不同層次「封裝為抽象」 這樣才有重用性，別人才能基於你的成果，進一步開發更豐富的東西 網路的七層架構，各種協定，程式語言，語言上面的工具、套件、框架，都是抽象 # The Law of Leaky Abstractions，抽象滲漏法則：除非無關緊要，否則所有抽象都或多或少會滲漏 這是在軟體圈知名的一個理論，稍微資深的開發者都應該要知道這篇文章 https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ 我簡單說明一下，抽象滲漏法則就是在說：所有抽象都一定會在某些情境下失效，此時便是滲漏。 你只要工作時間夠久就會知道，長遠來說，你還是要花時間去研究它抽象背後的東西。 你本以為只是前端隨便寫一寫交差，卻發現有一天需要認真去看 HTTP 協定、CORS 在講什麼，否則無法處理資安問題 你本以為只是後端 CRUD 隨便寫一寫交差，卻發現有一天需要認真去看 database 索引機制、記憶體管理，否則無法處理效能問題 結論：「抽象」幫助我們省下一些工作的時間，但關於技術細節的學習時間，無法省下來。 # 你的生產力要對公司商業產值有幫助 我認為工程師常常在另一個方面犯錯，就是鑽研自己喜歡的細節，不去管對於公司的商業產值與個人生產力 我曾遇過公司要求協助更換一張網頁圖片，某工程師居然兩個星期還沒更換完成 問他原因，原來是他看圖片尺寸不順眼，在研究分割、壓縮、整個網頁的整合機制，以及相關工具的導入 問題是，那個網頁跟圖片並不重要，此時專案還沒進到效能優化的階段，此功能應該盡快上線，視情況決定下一步 這完全是沒搞清楚優先順序，只顧著研究自己爽的東西，也沒跟相關人士確認任務目標 # 結論 回到原 po 的描述 ``` 不然工程師哪有那麼多腦力去記住程式底層都做了什麼 ``` 這是大錯特錯，隨便找一個優秀的資深工程師，從 Vue 到 React 到各種工具，背後原理、相關機制，都能深入淺出跟你說明 什麼 shadow DOM / virtual DOM / pure function / fiber tree / proxy / immutable 等等，就算好幾個月不碰工具，還是能輕鬆解釋，根本不是死記硬背的，這全都是經驗＆融會貫通的結果 但是過猶不及，不顧公司需求，自顧自地研究技術細節也不好 該花多少時間研究背後機制？這是一個需要權衡的問題 請從公司需求的角度，以及個人長期職涯的角度，視情況判斷 以上，簡單分享
收到網友提問如下： ``` 我不知道自己想做前或後端，怎麼辦？ ``` 其實很多人都是這樣，阿川建議「就先都學」！ 如果急著上班賺錢，可以先側重「前端」，然後找個新手友善的職缺就先衝了 因為後端的技術有很多，一開始也不知怎麼挑選 以阿川目前觀察身邊同年紀33歲左右工程師 那些很強的前端或後端，雖然有專精的部份，但其實，同時也是「全端」工程師 同時對前後端保持興趣，有很大的好處 首先，同時學習前後端，會對網路技術生態系，有更深、更廣的了解 再來，是在求職的時候，可以應徵前端的機會，也可以應徵後端的機會 以我自己本人來說，面試上班、或者接案的時候，有時會負責前端，有時會負責後端，工作機會就多很多 最後，擁有全端技能，就算都是初階經驗，也可以在業餘時間做 side-project 甚至是跟朋友一起創業當副業 總之不用一開始就強迫自己一定要選好前端或後端 迷惘、探索、好奇的狀態，本來就是人生的常態 有時間的話，就都學吧！急著賺錢的話，可以先從前端開始～！ 以上，簡單分享
本文將分為三個部分： 1. 通用設計模式 2. 我的建議 3. 進一步閱讀 享受並且讓我知道您在專案中使用的模式和實踐🚀 原文出處：https://dev.to/jacobandrewsky/good-practices-and-design-patterns-for-vue-composables-24lk ## 通用設計模式 我認為了解建置可組合項模式的最佳來源實際上是 Vue.js 文件，您可以在[此處](https://vuejs.org/guide/reusability/composables.html)查看 ### 基本可組合項 Vue 文件顯示了以下 useMouse 可組合項的示例： ``` // mouse.js import { ref, onMounted, onUnmounted } from 'vue' // by convention, composable function names start with "use" export function useMouse() { // state encapsulated and managed by the composable const x = ref(0) const y = ref(0) // a composable can update its managed state over time. function update(event) { x.value = event.pageX y.value = event.pageY } // a composable can also hook into its owner component's // lifecycle to setup and teardown side effects. onMounted(() => window.addEventListener('mousemove', update)) onUnmounted(() => window.removeEventListener('mousemove', update)) // expose managed state as return value return { x, y } } ``` 稍後可以在元件中使用它，如下所示： ``` <script setup> import { useMouse } from './mouse.js' const { x, y } = useMouse() </script> <template>Mouse position is at: {{ x }}, {{ y }}</template> ``` ### 異步可組合項 為了獲取資料，Vue 建議使用以下可組合結構： ``` import { ref, watchEffect, toValue } from 'vue' export function useFetch(url) { const data = ref(null) const error = ref(null) watchEffect(() => { // reset state before fetching.. data.value = null error.value = null // toValue() unwraps potential refs or getters fetch(toValue(url)) .then((res) => res.json()) .then((json) => (data.value = json)) .catch((err) => (error.value = err)) }) return { data, error } } ``` 然後可以在元件中使用它，如下所示： ``` <script setup> import { useFetch } from './fetch.js' const { data, error } = useFetch('...') </script> ``` ### 可組合合約 根據上面的示例，以下是所有可組合項都應遵循的約定： 1. 可組合文件名應以 use 開頭，例如 `useSomeAmazingFeature.ts` 2. 它可以接受輸入參數，這些參數可以是字串等基本類型，也可以接受 refs 和 getter，但需要使用 toValue 幫助器 3. Composable 應該返回一個 ref 值，該值可以在解構可組合項後存取，例如 `const { x, y } = useMouse()` 4. 可組合項可以保存可以在整個應用程式中存取和修改的全局狀態。 5. 可組合性可能會產生副作用，例如加入窗口事件偵聽器，但在卸載元件時應清除它們。 6. 可組合項只能在 `<script setup>` 或 `setup()` 掛鉤中呼叫。它們也應該在這些上下文中同步呼叫。在某些情況下，您還可以在生命週期掛鉤中呼叫它們，例如“onMounted()”。 7. 可組合項可以呼叫內部的其他可組合項。 8. 可組合項應在內部包裝某些邏輯，當過於復雜時，應將它們提取到單獨的可組合項中以便於測試。 ## 我的建議 我已經為我的工作專案和開源專案建置了多個可組合項 - NuxtAlgolia、NuxtCloudinary、NuxtMedusa，因此基於這些，我想根據我的經驗在上面的合同中加入一些要點。 ### 有狀態或/和純函數可組合項 在程式碼標準化的某個時刻，您可能會得出這樣的結論：您希望對可組合項中的狀態保留做出決定。 最容易測試的函數是那些不存儲任何狀態的函數（即它們是簡單的輸入/輸出函數），例如負責將字節轉換為人類可讀值的可組合函數。它接受一個值並返回一個不同的值 - 它不存儲任何狀態。 不要誤會我的意思，你不必做出“或”的決定。您可以完全保留有狀態和無狀態可組合項。但這應該是一個書面決定，以便以後更容易與他們合作 🙂 ### 可組合項的單元測試 我們希望使用 Vitest 為我們的前端應用程式實施單元測試。在後端工作時，進行單元測試程式碼覆蓋率非常有用，因為您主要關注邏輯。然而，在前端，您通常使用視覺效果。 因此，我們認為對整個元件進行單元測試可能不是最好的主意，因為我們基本上將對框架本身進行單元測試（如果按下按鈕，檢查狀態是否更改或模式是否打開）。 由於我們已將所有業務邏輯移至可組合項（基本上是 TypeScript 函數）內，因此它們很容易使用 Vitest 進行測試，並且允許我們擁有更穩定的系統。 ### 可組合項的範圍 不久前，在 VueStorefront 中，我們開發了自己的可組合方法（早在它們實際上像這樣被呼叫之前）。在我們的方法中，我們使用可組合項來映射電子商務的業務領域，如下所示： ``` const { cart, load, addItem, removeItem, remove, ... } = useCart() ``` 這種方法絕對有用，因為它允許將域包裝在一個函數中。在“useProduct”或“useCategory”等更簡單的示例中，實現和維護相對簡單。然而，正如您在此處的“useCart”示例中看到的那樣，當包裝一個包含更多邏輯而不僅僅是資料獲取的域時，這個可組合項正在發展成為一種非常難以開發和維護的形狀。 此時，我開始為 Nuxt 生態系統做出貢獻，其中引入了不同的方法。在這種新方法中，每個可組合項僅負責一件事。因此，我們的想法不是建置一個巨大的“useCart”可組合項，而是為每個功能建置可組合項，即“useAddToCart”、“useFetchCart”、“useRemovefromCart”等。 因此，維護和測試這些可組合項應該更容易 🙂 ## 進一步閱讀 這將是我的研究的全部內容。如果您想了解有關此主題的更多訊息，請務必查看以下文章： * https://vuejs.org/guide/reusability/composables.html * https://www.youtube.com/watch?v=bcZM3EogPJE * https://vueschool.io/articles/vuejs-tutorials/what-is-a-vue-js-composable/ * https://blog.logrocket.com/getting-started-vue-composables/ * https://macopedia.com/blog/news/how-can-vue-3-composables-make-your-life-easier
如何在微前端中處理 CSS？畢竟，樣式始終是*任何* UI 片段所需要的東西，但是，它也是全局共享的東西，因此是潛在的衝突來源。 在這篇文章中，我想回顧一下現有的不同策略來馴服 CSS 並使其擴展以開發微前端。如果這裡的任何內容對您來說聽起來很合理，那麼也可以考慮研究一下[“微前端的藝術”](https://microfrontends.art/)。 **本文的程式碼可以在[github.com/piral-samples/css-in-mf](https://github.com/piral-samples/css-in-mf)找到。請務必查看示例實現。** CSS 的處理是否會影響每個微前端解決方案？讓我們檢查可用的類型來驗證這一點。 原文出處：https://dev.to/florianrappl/css-in-micro-frontends-4jai ## 微前端的類型 過去我寫了很多關於存在哪些類型的微前端、為什麼存在以及何時應該使用什麼類型的微前端架構的文章。採用 Web 方法意味著使用 iframe 來使用來自不同微前端的 UI 片段。在這種情況下，沒有任何限制，因為無論如何每個片段都是完全隔離的。 在任何其他情況下，無論您的解決方案使用客戶端還是伺服器端組合（或介於兩者之間的東西），您最終都會得到在瀏覽器中評估的樣式。因此，在所有其他情況下，您都會關心 CSS。讓我們看看這裡有哪些選項。 ## 無特殊處理 好吧，第一個 - 也許是最（或根據觀點，最不）明顯的解決方案是不進行任何特殊處理。相反，每個微前端都可以附帶額外的樣式表，然後在渲染微前端的元件時附加這些樣式表。 理想情況下，每個元件僅在首次渲染時加載所需的樣式，但是，由於這些樣式中的任何一個都可能與現有樣式衝突，我們也可以假裝在微前端的任何元件渲染時加載所有“有問題的”樣式。  這種方法的問題在於，當給出諸如“div”或“div a”之類的通用選擇器時，我們還將重新設置其他元素的樣式，而不僅僅是原始微前端的片段。更糟糕的是，類和屬性也不是故障保護措施。像“.foobar”這樣的類也可以在另一個微前端中使用。 **您將在引用的演示存儲庫中找到兩個衝突的微前端的示例，網址為 [solutions/default](https://github.com/piral-samples/css-in-mf/tree/main/solutions)。** 擺脫這種痛苦的一個好方法是進一步隔離元件 - 就像 Web 元件一樣。 ## 影子 DOM 在自定義元素中，我們可以打開一個影子根來將元素附加到專用的迷你文件，該迷你文件實際上與其父文件屏蔽。總的來說，這聽起來是一個好主意，但與這裡介紹的所有其他解決方案一樣，沒有硬性要求。  理想情況下，微前端可以自由決定“如何”實現元件。因此，實際的 Shadow DOM 集成必須由微前端完成。 使用 Shadow DOM 有一些缺點。最重要的是，雖然 Shadow DOM 內部的樣式保留在內部，但全局樣式也不會影響 Shadow DOM。乍一看，這似乎是一個優勢，但是，由於整篇文章的主要目標只是隔離微前端的樣式，因此您可能會錯過諸如應用某些全局設計系統（例如 Bootstrap）之類的要求。 要使用 Shadow DOM 進行樣式設置，我們可以通過“link”引用或“style”標籤將樣式放入 Shadow DOM 中。由於 Shadow DOM 是無樣式的，並且外部的樣式不會傳播到其中，因此我們實際上需要它。除了編寫一些內聯樣式之外，我們還可以使用捆綁器將“.css”（或者類似“.shadow.css”的內容）視為原始文本。這樣，我們只會得到一些文本。 對於 esbuild，我們可以配置 `piral-cli-esbuild` 的預製配置，如下所示： ``` module.exports = function(options) { options.loader['.css'] = 'text'; options.plugins.splice(0, 1); return options; }; ``` 這會刪除初始 CSS 處理器 (SASS) 並為“.css”文件配置標準加載器。現在，shadow DOM 中的某些樣式的工作方式如下： ``` import css from "./style.css"; customElements.define(name, class extends HTMLElement { constructor() { super(); this.attachShadow({ mode: "open" }); } connectedCallback() { this.style.display = "contents"; const style = this.shadowRoot.appendChild(document.createElement('style')); style.textContent = css; } }); ``` 上面的程式碼是一個有效的自定義元素，從樣式角度來看它是透明的（“display：contents”），即只有其內容會反映在渲染樹中。它託管一個包含單個“style”元素的影子 DOM。 `style` 的內容設置為 `style.css` 文件的文本。 **您將在 [`solutions/shadow-dom`](https://github.com/piral-samples/css-in-mf/tree/main) 引用的演示存儲庫中找到兩個衝突的微前端的示例/解決方案/shadow-dom）。** 域元件避免使用影子 DOM 的另一個原因是，並非每個 UI 框架都能夠處理影子 DOM 中的元素。因此，無論如何都必須尋找替代解決方案。一種方法是轉而使用一些 CSS 約定。 ## 使用命名約定 如果每個微前端都遵循全局 CSS 約定，那麼就可以在元級別上避免衝突。最簡單的約定是在每個類前面加上微前端的名稱。因此，舉例來說，如果一個微前端稱為“shopping”，另一個微前端稱為“checkout”，那麼兩者都會將其“active”類分別重命名為“shopping-active”/“checkout-active”。  這同樣適用於其他可能存在衝突的名稱。舉個例子，在微前端稱為“shopping”的情況下，我們將其稱為“shopping-primary-button”，而不是像“primary-button”這樣的ID。如果由於某種原因，我們需要設置元素的樣式，我們應該使用後代選擇器（例如“.shopping img”）來設置“img”標籤的樣式。現在，這適用於具有“shopping”類的 *some* 元素中的“img”元素。這種方法的問題是購物微前端也可能使用其他微前端的元素。如果我們看到“div.shopping > div.checkout img”怎麼辦？儘管“img”現在由通過“checkout”微前端帶來的元件託管/集成，但它的樣式將由“shopping”微前端 CSS 設計。這並不理想。 儘管命名約定在一定程度上解決了問題，但它們仍然容易出錯並且使用起來很麻煩。如果我們重命名微前端會怎樣？如果微前端在不同的應用程式中獲得不同的名稱怎麼辦？如果我們在某些時候忘記應用命名約定怎麼辦？這就是工具幫助我們的地方。 ## CSS 模塊 自動引入一些前綴並避免命名衝突的最簡單方法之一是使用 CSS 模塊。根據您選擇的捆綁器，這可以是開箱即用的，也可以通過一些配置更改來實現。  ``` // Import "default export" from CSS import styles from './style.modules.css'; // Apply <div className={styles.active}>Active</div> ``` 導入的模塊是一個生成的模塊，保存將其原始類名（例如“active”）映射到生成的類名的值。生成的類名通常是 CSS 規則內容與原始類名混合的哈希值。這樣，名稱應該盡可能唯一。 作為示例，讓我們考慮使用“esbuild”建置的微前端。對於“esbuild”，您需要一個插件（“esbuild-css-modules-plugin”）和相應的配置更改以包含 CSS 模塊。 使用 Piral 我們只需要調整 `piral-cli-esbuild` 已經帶來的配置。我們刪除標準 CSS 處理（使用 SASS）並用插件替換： ``` const cssModulesPlugin = require('esbuild-css-modules-plugin'); module.exports = function(options) { options.plugins.splice(0, 1, cssModulesPlugin()); return options; }; ``` 現在我們可以在程式碼中使用 CSS 模塊，如上所示。 CSS 模塊有一些缺點。首先，它附帶了一些標準 CSS 的語法擴展。這對於區分我們想要導入的樣式（因此要進行預處理/哈希）和應保持原樣的樣式（即稍後在不導入的情況下使用）是必要的。另一種方法是將CSS直接帶入JS文件中。 ## CSS-in-JS CSS-in-JS 最近的名聲很差，但是，我認為這是一個誤解。我也更喜歡將其稱為“CSS-in-Components”，因為它為元件本身帶來了樣式。一些框架（Astro、Svelte 等）甚至允許通過其他方式直接執行此操作。經常被提及的缺點是性能 - 這通常是由於在瀏覽器中編寫 CSS 造成的。然而，這並不總是必要的，在最好的情況下，CSS-in-JS 庫實際上是建置時間驅動的，即沒有任何性能缺陷。  然而，當我們談論 CSS-in-JS（或 CSS-in-Components）時，我們需要考慮現有的各種選項。為簡單起見，我只包含三個：情感、樣式元件和香草提取物。讓我們看看它們如何幫助我們在將微前端整合到一個應用程式中時避免衝突。 ### Emotion Emotion 是一個非常酷的庫，它附帶了 React 等框架的幫助程序，但沒有將這些框架設置為先決條件。情感可以很好地優化和預先計算，並允許我們使用可用的 CSS 技術的完整庫。 使用“純粹”情感相當容易；首先安裝包： ``` npm i @emotion/css ``` 現在您可以在程式碼中使用它，如下所示： ``` import { css } from '@emotion/css'; const tile = css` background: blue; color: yellow; flex: 1; display: flex; justify-content: center; align-items: center; `; // later <div className={tile}>Hello from Blue!</div> ``` `css` 幫助器允許我們編寫被解析並放置在樣式表中的 CSS。返回值是生成的類的名稱。 如果我們特別想使用 React，我們還可以使用 Emotion 中的 jsx 工廠（引入了一個名為 css 的新標準 prop）或 styled 幫助器： ``` npm i @emotion/react @emotion/styled ``` 現在感覺很像樣式是 React 本身的一部分。例如，“styled”幫助器允許我們定義新元件： ``` const Output = styled.output` border: 1px dashed red; padding: 1rem; font-weight: bold; `; // later <Output>I am groot (from red)</Output> ``` 相比之下，“css”輔助屬性使我們能夠稍微縮短符號： ``` <div css={` background: red; color: white; flex: 1; display: flex; justify-content: center; align-items: center; `}> Hello from Red! </div> ``` 總而言之，這會生成不會衝突的類名，並提供避免樣式混合的穩健性。 “styled”助手尤其受到流行的“styled-components”庫的啟發。 ### 樣式元件 “styled-components”庫可以說是最流行的 CSS-in-JS 解決方案，並且常常是此類解決方案聲譽不佳的原因。從歷史上看，這實際上是在瀏覽器中編寫 CSS 的全部內容，但在過去幾年中，他們確實極大地推進了這一點。今天，您也可以對所使用的樣式進行一些非常好的伺服器端組合。 與“emotion”相比，安裝（針對 React）需要更少的軟體包。唯一的缺點是打字是事後才想到的 - 所以你需要安裝兩個包才能完全喜歡 TypeScript： ``` npm i styled-components --save npm i @types/styled-components --save-dev ``` 安裝後，該庫就已經完全可用： ``` import styled from 'styled-components'; const Tile = styled.div` background: blue; color: yellow; flex: 1; display: flex; justify-content: center; align-items: center; `; // later <Tile>Hello from Blue!</Tile> ``` 其原理與“情感”相同。因此，讓我們探索另一種選擇，嘗試從一開始就實現零成本，而不是事後的想法。 ### Vanilla Extract 我之前寫的關於利用類型更接近元件（並避免不必要的執行時成本）的內容正是最新一代 CSS-in-JS 庫所涵蓋的內容。最有前途的庫之一是“@vanilla-extract/css”。 使用該庫有兩種主要方式： - 與您的捆綁器/框架集成 - 直接使用 CLI 在此示例中，我們選擇前者 - 並將其集成到“esbuild”。為了使集成正常工作，我們需要使用“@vanilla-extract/esbuild-plugin”包。 現在我們將其集成到建置過程中。使用 `piral-cli-esbuild` 配置，我們只需將其加入到配置的插件中： ``` const { vanillaExtractPlugin } = require("@vanilla-extract/esbuild-plugin"); module.exports = function (options) { options.plugins.push(vanillaExtractPlugin()); return options; }; ``` 為了使 Vanilla Extract 正常工作，我們需要編寫 `.css.ts` 文件，而不是普通的 `.css` 或 `.sass` 文件。這樣的文件可能如下所示： ``` import { style } from "@vanilla-extract/css"; export const heading = style({ color: "blue", }); ``` 這都是有效的 TypeScript。我們最終會得到一個類名的導出 - 就像我們從 CSS 模塊、Emotion 中得到的一樣 - 你明白了。 所以最後，上面的樣式將像這樣應用： ``` import { heading } from "./Page.css.ts"; // later <h2 className={heading}>Blue Title (should be blue)</h2> ``` 這將在建置時完全處理——而不是執行時成本。 您可能會感興趣的另一種方法是使用 CSS 實用程序庫，例如 Tailwind。 ## CSS 實用程序，例如 Tailwind 這是一個獨立的類別，但我認為既然 Tailwind 是這個類別中的主要工具，我將只介紹 Tailwind。 Tailwind 的主導地位甚至達到了甚至有人問“你寫 CSS 還是 Tailwind？”之類的問題。這與 jQuery 在 DOM 操作領域的統治地位非常相似。 2010 年，人們問“這是 JavaScript 還是 jQuery？”。 無論如何，使用 CSS 實用程序庫的優點是根據使用情況生成樣式。這些樣式不會衝突，因為實用程序庫始終以相同的方式定義它們。因此，每個微前端將僅附帶實用程序庫中根據需要顯示微前端所需的部分。  如果使用 Tailwind 和 esbuild，我們還需要安裝以下軟體包： ``` npm i autoprefixer tailwindcss esbuild-style-plugin ``` esbuild的配置比之前複雜一點。 `esbuild-style-plugin` 本質上是 esbuild 的 PostCSS 插件；所以必須正確配置： ``` const postCssPlugin = require("esbuild-style-plugin"); module.exports = function (options) { const postCss = postCssPlugin({ postcss: { plugins: [require("tailwindcss"), require("autoprefixer")], }, }); options.plugins.splice(0, 1, postCss); return options; }; ``` 在這裡，我們刪除了默認的 CSS 處理插件 (SASS)，並將其替換為 PostCSS 插件 - 使用 PostCSS 的“autoprefixer”和“tailwindcss”擴展。 現在我們需要加入一個有效的 *tailwind.config.js* 文件： ``` module.exports = { content: ["./src/**/*.tsx"], theme: { extend: {}, }, plugins: [], }; ``` 這本質上是配置 Tailwind 的最低要求。它只是提到應該掃描 `tsx` 文件以了解 Tailwind 實用程序類的使用情況。然後找到的類將被放入 CSS 文件中。 因此，CSS 文件還需要知道生成/使用的聲明應包含在哪裡。至少我們只有以下 CSS： ``` @tailwind utilities; ``` 還有其他“@tailwind”指令。例如，Tailwind 帶有重置和基礎層。然而，在微前端中，我們通常不關心這些層。這屬於應用程式 shell 或編排應用程式的關注範圍 - 而不是域應用程式。 然後，CSS 將被替換為 Tailwind 中已指定的類： ``` <div className="bg-red-600 text-white flex flex-1 justify-center items-center">Hello from Red!</div> ``` ## 比較 迄今為止提出的幾乎每種方法都是微前端的可行競爭者。一般來說，這些溶液也可以混合。一個微前端可以採用影子 DOM 方法，而另一個微前端則對 Emotion 感到滿意。第三個圖書館可能會選擇使用香草精。 最後，唯一重要的是所選擇的解決方案是無碰撞的，並且不會帶來（巨大的）執行時成本。雖然某些方法比其他方法更有效，但它們都提供了所需的樣式隔離。 |方法|遷移工作|可讀性|穩健性|性能影響| | ----------- | -------------- | -------------- | ---------- | ------------------ | |大會 |中等|高|低|無 | | CSS 模塊 |低|高|中等|從無到低| |影子 DOM |低到中|高|高|低| | JS 中的 CSS |高|中到高|高|從無到高| |順風|高|中等|高|無 | 性能影響很大程度上取決於實施。例如，對於 CSS-in-JS，如果解析和組合在執行時完全完成，您可能會產生很大的影響。如果樣式已經預先解析但僅在執行時組合，則影響可能很小。如果使用像香草精這樣的解決方案，您基本上不會產生任何影響。 對於 Shadow DOM，主要的性能影響可能是 Shadow DOM 內部元素的投影或移動（本質上為零）以及“style”標籤的重新評估。然而，這是相當低的，甚至可能會產生一些性能優勢，給定的樣式總是切中要害，並且僅專用於要在影子 DOM 中顯示的某個元件。 在示例中，我們有以下捆綁包大小： |方法|索引 [kB] |頁碼 [kB] |表 [kB] |總體 [kB] |尺寸 [%] | | ----------------- | ---------- | --------- | ----------- | ------------ | ------ | |默認| 1.719 | 1.719 1.203 | 1.203 0.245 | 0.245 3.167 | 3.167 100% | |大會 | 1.761 | 1.761 1.241 | 1.241 0.269 | 0.269 3.271 | 3.271 103% | | CSS 模塊 | 2.149 | 2.149 2.394 | 2.394 0 | 4.543 | 4.543 143% | |影子 DOM | 10.044 | 10.044 1.264 | 1.264 0 | 11.308 | 11.308 357% | |情感| 1.670 | 1.670 1.632 | 1.632 25.785 | 25.785 29.087 | 29.087 918% | |樣式元件 | 1.618 | 1.618 1.612 | 1.612 63.073 | 63.073 66.303 | 66.303 2093% | |香草精 | 1.800 | 1.800 1.257 | 1.257 0.314 | 0.314 3.371 | 3.371 106% | |順風| 1.853 | 1.853 1.247 | 1.247 0.714 | 0.714 3.814 | 3.814 120% | 對這些數字持保留態度，因為在情感和样式元件的情況下，執行時可以（並且可能甚至應該）共享。另外，給定的示例微前端確實很小（所有 UI 片段的總體大小為 3kB）。對於更大的微前端，增長肯定不會像這裡描述的那麼問題。 Shadow DOM 解決方案的大小增加可以通過我們提供的簡單實用腳本來解釋，該腳本可以輕鬆地將現有的 React 渲染包裝到 Shadow DOM 中（無需生成新樹）。如果這樣的實用程序是集中共享的，那麼其大小將更接近其他更輕量級的解決方案。 ## 結論 在微前端解決方案中處理 CSS 並不困難 - 只需從一開始就以結構化和有序的方式完成，否則就會出現衝突和問題。一般來說，建議選擇 CSS 模塊、Tailwind 或可擴展的 CSS-in-JS 實現等解決方案。
距離大學畢業已經三年，我大學主要修php 還留著PHP7 新觀念php7+MySQL+AJAX的教科書 但那時候還沒學精 想繼續鑽研PHP但我英文不好想先從中文書看 請教是要先買php新版本的PHP8還是繼續原來那本(PHP7)弄懂好? 雖然目前應該是前端JS趨勢但我仍然想先把PHP學精在學前端 可能我對PHP語法比較熟悉吧 雖然高中學過JS 但JS都遺忘了...
開源對很多事情都非常有用。其中之一是學習新技能。在本文中，我們將介紹 GitHub 上一些最好的開源 React 專案，您可以使用它們來快速提升您的 React 技能。 原文出處：https://dev.to/livecycle/top-github-repositories-to-learn-modern-react-development-5d3h ## 你可以學習的開源 React 專案  ## Cal.com  [https://github.com/calcom/cal.com](https://github.com/calcom/cal.com) Cal.com 將自己標榜為“絕對適合所有人的日程安排基礎設施”。他們是 Calendly 等預約安排服務的競爭對手。他們同時提供託管和自託管產品。它是一個全棧 Next.js 應用程式，它依賴 tRPC 進行類型安全的客戶端到伺服器通信。該存儲庫具有相當廣泛的 Monorepo 設置（使用 Turborepo），可將應用程式拆分為多個包。在樣式方面，Cal.com 使用 TailwindCSS 和無頭 Radix 元件。存儲庫非常活躍，他們積極鼓勵貢獻者。許多問題被標記為“良好的第一期”和“需要幫助”。 ## Taxonomy  [https://github.com/shadcn/taxonomy](https://github.com/shadcn/taxonomy) 這個有點不同。它由單個開發人員建置，作為探索新的 Next.js 13 App Router 功能的演示。但是不要讓那個愚弄你。它可以說是使用新 App Router 的最全面的開源應用程式之一。因此，即使對於想要學習如何在生產中使用 App Router 的經驗豐富的 React 開發人員來說，這也是一個很好的資源。 除了用於前端和後端的 Next.js 之外，Taxonomy 使用 NextAuth 進行身份驗證，使用 Prisma 作為 ORM，使用帶有 Radix 的 TailwindCSS 進行樣式設置。特別有趣的是 Stripe 訂閱集成。因此，如果您想了解如何將訂閱集成到您的應用程式中，這就是適合您的存儲庫。 ## Highstorm  [https://github.com/chronark/highstorm](https://github.com/chronark/highstorm) Highstorm 是這個街區的新玩家。它是一種監視應用程式中發生的事件的服務。您通過他們的 API 提交事件，然後將其輸入 Highstorm 儀表板。再次重申，這是一個基於 Next.js 的專案。它使用 Tinybird 作為分析資料的資料庫，並使用 Clerk 進行身份驗證。如果您想學習如何處理大量分析資料並將它們顯示在精美的圖表中，那麼這個專案很棒。 ## Dub.sh  [https://github.com/steven-tey/dub](https://github.com/steven-tey/dub) Dub.sh 大約在一年前作為開源連結縮短器推出。它是 Bitly 等服務的替代品。它也是基於 Next.js 並結合使用舊頁面和新 App 路由器。它通常是最早採用 Next.js 新功能（例如元資料 API）的專案之一。 該存儲庫是了解多租戶 Next 應用程式的好地方。這些是為不同域下的不同用戶提供服務的應用程式。在 Dub.sh 的情況下，用戶可以加入自己的域以在其下建立縮短的連結。該應用程式的設計也很精美，整個網站上都有許多令人愉悅的動畫。 Framer Motion 庫用於幫助解決此問題。 ## Bulletproof React  [https://github.com/alan2207/bulletproof-react](https://github.com/alan2207/bulletproof-react) Bulletproof React 與我們目前介紹的其他專案不同。該存儲庫確實包含一個功能齊全的演示 React 應用程式。但最大的價值來自閱讀此應用程式附帶的綜合文件。本文件列出了設計大型 React 應用程式各個方面的最佳實踐。這是一個很好的資源，可以定期參考以刷新您對最佳實踐的記憶。 ## 總結和開始 正如我們所見，上述每個存儲庫都提供了一個獨特的視角來了解大型 React 應用程式是如何建置的。每個人都可以從研究存儲庫的程式碼中獲益，無論您有多有經驗。 開始從存儲庫中學習的一個很好的實用技巧是提出一個特定的問題。例如，您可能會問“Taxonomy 如何處理 Stripe 訂閱？”之類的問題。然後挖掘程式碼層以找到問題的答案。 最後一點——探索開源存儲庫是提升 React 技能的好方法，但這不是您唯一應該做的事情。將您新獲得的知識應用到您自己的專案中也很重要。這就是您鞏固新技能和保留訊息的方式。 最主要的是享受這個過程，並認識到開源是培養新技能的友好場所，無論您目前的經驗水平如何。
感謝站長關懷～ 是的，這禮拜確實有遇到一些之前有稍微碰過卻不太熟悉的東西，也有之前沒有碰過的東西，是有些小崩潰...，但還是可以稍微跟大家分享與請教一下： 這裡有一些前期提要：公司目前的前端開發並不使用現在的主流前端框架，也沒有使用打包整合工具...（像是Webpack、Parcel這類的)，ＪＳ使用JQuery，並且將ＪＳ檔案一個一個的引入網頁中。 ## 遇到的問題1 ：CSS樣式問題 過去在自學的時候其開發方法是：在本機開發，然後在處理樣式與ＲＷＤ時就是開啟Chrome 的 Dev Tools來做調整，但也有遇過在Chrome的Dev Tools中看起來將樣式都調整好了之後，部署到網路上之後換手機來查看頁面時卻發生了一些差異，這些差異可能包含滿版、間距等等，這部分我自己理解的差異可能會是有些手機會有瀏海的緣故以及Chrome與Safari之間的小差異．到新公司後發現在更多的裝置上，例如安卓手機，則存在的差異更多，包含顏色、日期時間選取器等等的樣式，因為型號真的太多了． ###到這裡可以跟大家分享的以及向各位請教的： 這裡我自己有想到幾個解決的方式，第一個是最懶的方法我最想用但是我有些不知道該如何整合給其他人使用的方法，例如透過Vue cli直接在npm下載PostCSS以及Autoprefixer這樣的工具來使用，一次解決主流瀏覽器的差異，但目前我不太曉得如何在公司的開發方法下，不透過整合工具來完成這個流程． 另一個我想到的方法是加入CSS Normalize來減少各個瀏覽器在不同樣式的預設值差異，過去我們可能都有寫過非常簡易CSS reset 例如： ```css= *{ padding: 0; margin:0; box-sizing:border-box; } ``` 但這樣如果把每一個樣式的預設值全部強制歸零，可能會導致有些樣式到後來要重新寫，或許Ｎormalize可以只是單純地減少差異（也是因為網路上有人已經整理好了ＸＤ）． ## 遇到的問題2 ：API串接 過去我自己練習串接API的方式實在是相當簡易，我拿的是中央氣象局開放資料平台的API，所以之前很簡單的一行fetch就拿到資料了，毫無難度哈哈哈，但第一天公司需要我去切幾個版面並且串接運輸資料ＴＤＸ的資料，恩...我一開始不知道要如何在ＪＳ中塞入登入資料並且拿回Token的方式．以及我要查詢的數值該如何發出． ###到這裡可以跟大家分享的以及向各位請教的： 這中間我摸索了fetch的一些選項設定，這應該也適用其他的非同步請求方法，例如ajax、axios(這兩個我還沒用過，後續應該會來摸索一下axios），包含請求方法（method)，header與body中的內容設定等等． 至於API該如何塞入a頁面填入查詢參數並且跳轉到b頁面顯示查詢解果，在沒有前端框架全域狀態管理的支援下，這邊則是摸索了encodeURIComponent以及decodeURIComponent這樣的函式，將要查詢的參數在a頁面進行編碼並丟入到ＵＲＬ中，跳轉到b頁面後再進行解碼．並fetch我要的資料．最後是有成功的，只是覺得自己像薪水小偷哈哈哈，效率並不高． 這個方法感覺並不建議應用在需要輸入有個人資料的內容中，因為編碼的方式是雙向的，資料可以編碼也可以解碼，所以....像個資這類的內容就應該不建議塞在ＵＲＬ中用這種方式傳輸．至於要用什麼方法，這也是我想知道的． ## 遇到的問題3：不同裝置的問題 這個並非第一個樣式的問題，而是我目前覺得還沒有解的問題，就是我在網頁中需要獲取使用者的位置，因此用了navigator.geolocation 這個API，但神奇的是，在本機中都可以抓得到資料，打開Dev Tools檢查回傳的狀態碼與經緯度也都是沒有問題，但是在手機中雖然會顯示是否能夠取得使用者位置的提示，但按了同意後卻一直無法獲取資料，而且尷尬的是，我無法在手機中打開Dev Tools，所以我也不知道問題發生在哪....，過去有使用過navigator.geolocation 好像也沒有碰過這樣的問題 想跟各位請教的是，有什麼方式可以查看手機上的問題嗎？ ## 遇到的問題4：不同的開發方式 這個是我自己很好奇的，雖然說我知道Vue是漸進式框架，但我卻不知道該如何漸進．我理解的漸進式是，有些頁面或元件可以自行選擇要不要使用Vue開發，還是這個漸進式的意思是可以自行選擇要使用多少Vue的套件工具呢（像是要不要使用Vue Router or Vuex)． 會這樣問是因爲，假如現在有一份專案一共是十個頁面，我被分到了其中五頁，另外的同事則是負責另外五頁，誠如開頭所說，假如公司既定的開發方式並不使用框架與其他整合工具，我有可能使用框架進行開發並與之合作嗎？還是我這是一個很奇怪的問題，本來就應該要統一一個開發方式？ --- 感謝看到這邊的各位，以上有些觀念上是我這位小菜雞自己摸索的，是可能不是正確的（例如有些函式、工具的用途或使用情境），因此歡迎大家指教與討論，這是我這禮拜可以跟大家分享的啦． 謝謝～～ --- ＰＳ：我自學八個月的時間有摸了原生JS、ＣＳＳ、Vue.js、Tailwind、SCSS這樣的工具，本來我是很想要在第一份工作多了解與強化上述工具以及多人開發GitHub的部分，我了解這些終究只是工具且我自己也沒有到非常熟，只要可以完成專案目的即可，我的實力在哪裡我也知道，但以目前公司的開發模式來說，我需要考量沒有踏上趨勢的這個問題嗎？還是我多慮呢了？
首先我們來看 google trend  https://trends.google.com.tw/trends/explore?date=all&geo=TW&q=dreamweaver&hl=zh-TW 如你所見 這是一個過時的技術、正在被人們拋棄 接著請到 google 搜尋 `dreamweaver 職缺` 會發現其實 還是有些職缺要求要會 dreamweaver 這些職缺的待遇、工作內容 都在各大人力資源網站 你可以自行判斷：這些是不是你求職的目標職缺、理想職缺 --- 再來是我個人經驗，我這十年職場所見所聞，沒有遇過公司在用 Dreamweaver 我在社群認識各類工程師，也沒聽過有人在用這工具 不得不說 這實在是一個很老派的工具 唯一有次在業界遇到 好像有人在用的情境 是一間接案公司 以快速、便宜為主打 他們當時需要有人能用低價、快速的方式 把大量網頁切出來 後來找到的配合的人 好像就是用 Dreamweaver 在切版 --- 如果對 Dreamweaver 有興趣、好奇 我覺得多學一個工具 也不是壞事 對於之後再學其它工具 也是會有幫助 但是 應該沒必要花時間「專精」或者「鑽研」這樣一個老舊的工具 如果課程要求 或是有證照需求 那評估一下需要花費的時間 如果證照沒那麼難考 那花點時間 拿個證照 也滿好的 還能培養一些自信 如果履歷表還沒什麼東西能放 那放個證照也不錯 但如果考那證照很花錢、很花時間 那請審慎思考一下這投資值不值得 我是不推薦 我感覺只是培養快速、低成本切版網頁的能力 這能力頂多在接案公司會有幫助 而且還不會是很精緻的接案公司 不如花時間深入研究 JavaScript 基本功，對前端職涯更有幫助，而不只是專精於切版而已 --- 以上 簡單個人觀點分享
簡單複習一下，在這次的課程中，我們學會了 - 寫 node 程式 - 讀取、寫入檔案 - 匯入、匯出模組 - 從終端機輸入、輸出訊息 - NPM 套件管理工具 - 非同步語法、同步語法 是不是很有趣呢？ --- 補充一點，我在課程中多次提到非同步程式設計很多餘，其實不太精準 拿 node 寫 CLI 當然會覺得非同步程式設計很多餘，那是因為 node 設計的初衷是拿來寫網站後端！ 相比於其他像是 php 或 python 語言，js/node 非同步的設計會讓網站後端的效能比較強大！ 詳細原因可以先不用知道，有興趣再自己去研究一下即可！ --- 再補充一點，隨著 js 與 node 的發展 套件匯入匯出的語法，有時會看到 `require` 的寫法，有時會看到 `import` 的寫法 用 `import` 寫法有一些額外設定＆調整要弄 我是為了教學方便，才使用 `require` 的寫法，現在主流都改用 `import` 寫法了！ 實務上，就以 `import` 寫法為主吧！ 不過，反正就是模組管理而已，你就看情況，隨便哪一種寫法都可以，程式能解決問題最重要！ --- 這次的課程內容，完全不需要打開瀏覽器，沒有任何程式是在 `瀏覽器 js 環境` 執行的喔！ 都是從 `終端機` 直接要求 `node 主程式` 來執行！ --- 坊間的 Node 課程，大多是從「web 後端程式設計」開始教起 雖然也不錯，但是需要一開始就碰 node 的 `http` 模組，或是 `express` 模組 從前端開始認識 javascript 的學習者，常常會在這地方有點「腦袋打結」 分不清 `瀏覽器 js 環境` 以及 `node 環境` 的差別 也分不清為何 `node_modules` 的內容一下是在瀏覽器上出現，一下是在伺服器端出現 所以，我決定退一步來教，我們先學老派的 CLI 應用程式開發 這樣，過程中跟 `網站` `瀏覽器` `web 伺服器` 完全沒關係，你就可以先抓到純粹 node 寫程式的感覺！ 古早年代，所有程式都是 CLI 程式，文書處理、作業系統、連電腦遊戲都是 CLI 時至今日，CLI 應用程式看似老派，但依然是開發人員最重要的操作 UI 之一！所以值得學一下！ 但我們學一點就好了，不用深入鑽研 CLI 程式的開發技巧，這只是替後面 node 的進階應用、以及後端開發學習鋪路而已！ --- 消化、研究完本課程之後，請接著前往下一份教材，繼續邁向資深之路吧！ https://codelove.tw/@howtomakeaturn/course/bap2xj
身為網站工程師，對於 JavaScript 在 `瀏覽器還境` vs `Node.js 環境` 的關係，通常有點困惑 我認為單獨教一下 Node.js 開發，對於前端工程師的能力會有很大幫助！ 坊間要教 Node.js 通常會教「網頁後端程式設計」，這種教法當然沒問題 不過，我找到了一個更好吸收的教學法，就是從「命令列程式設計」開始教起！嘿嘿！ 命令列英文是 Command Line Interface，我們通常簡短稱呼為 CLI CLI 程式就是那種打開一個全黑的視窗，用戶需要手動打字，然後視窗又會跳出一堆字的程式 聽起來像是 40 年前人們使用電腦的方式，感覺是老派過氣的東西，對嗎？ 其實大錯特錯！ 工程師在 ssh 遠端處理主機的設定時，幾乎都還是操作透過 CLI 操作 使用 Linux 系列電腦的朋友（例如 Ubuntu 作業系統），日常中也會大量使用 CLI 即便是前端工程師，在開發過程，還是有大量的情況要使用 CLI，例如 NPM 相關指令通通會用到 --- 其實，CLI 是電腦程式最原始的 UI 介面！ Windows 電腦是一種 UI、網頁是一種 UI、手機是一種 UI 工程師在開發工具給別的工程師使用時，很常會懶得設計 UI 比如我寫了一個很強的檔案壓縮程式、或是硬碟清理程式，核心演算法寫完，我就想發佈給大家用了 我幹嘛還要花時間去寫一個漂亮、五顏六色、有按鈕的 UI？程式就用 CLI 操作就可以了，反正用戶都是工程師 --- 因為 CLI 是最原始的 UI，我認為教你寫一些 CLI 應用程式，對於 Node.js 會有極大的幫助 別擔心，這門課非常簡單，也非常好玩，也會讓你知道 Node.js 拿來寫 CLI 是什麼感覺 雖然這年頭市面上沒有人會去教 CLI 程式開發了，不過我保證你會獲益良多，還能讓之後學 Node.js 網頁後端開發，吸收得更好 嘿嘿，讓我們馬上開始吧！
這是我 2015 年寫的文章，當時在學界、業界評價兩極，也引起很多人痛罵 多年後回頭看，我的觀點不變。文章滿適合這個論壇的，我順手轉發一下 --- 從來沒有一個技能，曾經被神化到這個程度： 「你不但要有天份，還要有熱情，才適合寫程式。」 那些寫程式的人，好像「從小就立定志向，決定未來要寫程式了」。 缺乏其一的話，你要嘛是個假貨，要嘛走不遠，總之就是不適合。 這種深植人心的刻板印象不但大錯特錯，同時還是有害的。 隨便找幾個工程師都能證明這點。 # Jacob Kaplan-Moss（Django創造者） Jacob Kaplan-Moss的這份簡報提到： [一個平庸工程師的自白](http://www.inside.com.tw/2015/06/12/i-am-a-mediocre-programmer) > 這種關於「程式天才」的神話非常有害，一方面它把行業門檻設置得特別高，令很多人望而卻步，另一方面它也在折磨產業內的人，因為你如果不能 rocks ，就會變成 sucks ，所以不得不用一切時間來努力學習和工作，導致影響生活。…（略）…我們應該改變這種態度，寫程式只是一些技能，並不需要太多天分，它是可以學習的，而且做一個平庸的工程師不丟人， 他本人在[Twitter的自介](https://twitter.com/jacobian)直接寫「不是真的程式設計師（not a real programmer）」， 透漏著他對這種迷思的不耐煩。 # Jacob Thornton（Bootstrap作者） 在Github擁有八萬顆星的Bootstrap作者， 前Twitter、現任Medium工程師Jacob Thornton的一篇採訪也是這種迷思的反例： [Jacob Thornton痛恨電腦（Jacob Thornton Hates Computers）](https://medium.com/@verbagetruck/jacob-thornton-hates-computers-5c64f164ee07) > 當他說「我痛恨電腦」的時候，並不完全在開玩笑。…（略）…他說「我本來要去唸社會學的」 接著描述了他第一份工作的情況： > 我拿到了一個遠超我能力的工作。每一天都可能被開除。所以我非常努力工作，想搞懂JavaScript，因為我不懂它到底在幹嘛。 > 我一生中最現實的一刻到了。整間公司的人圍在我身邊，要我做一個XHR request。我根本沒做過，我只稍微聽過而已。於是我開始打字、重新整理瀏覽器，然後什麼都沒出來。我反覆做了幾次，知道自己完蛋了，他們發現我是假貨了。接著我突然發現自己忘記加「.send()」。我加了之後再次重新整理瀏覽器，畫面成功顯示。整個團隊感覺像在說「喔，酷。」然後就各自回辦公桌了。 > 我在那裡坐了15分鐘。心想，就這樣。我搞定了。我不會被開除了。 這段描述一點也不像「程式天才」在職場的表現。 至於支持他一路走來的動機是什麼呢？他說： > 我是一個高度在乎同儕的人，我做前端的朋友總是會告訴我哪個地方做很醜或是在哪個瀏覽器上壞掉。感覺真的很棒。我真的只想跟朋友一起寫程式，一起工作。 [他本人的Twitter](https://twitter.com/fat)自介寫「computer loser」， 置頂推文是「公司裡第一爛的工程師，但是第三酷」。 這種態度跟刻板印象完全相反。 # Rasmus Lerdorf（PHP之父） Rasmus Lerdorf的[言論](https://en.wikiquote.org/wiki/Rasmus_Lerdorf)常常引起廣泛爭議： - 我其實很討厭寫程式，不過我喜歡解決問題。 - 有些人熱愛寫程式。我不懂他們為何會這樣。 - 我不是一個真的工程師。我把東西弄一弄，弄到能跑之後就不管了。真的工程師會說「這段程式能跑，但記憶體沒管理好，我們來修好它」。我只會說，一直重新開機不就好了。 從他的言論，很難看出他對電腦本身有多少熱情。 他也跟Jacob Kaplan-Moss以及Jacob Thornton一樣，懶得對寫程式的迷思多做解釋， 乾脆直接說自己是loser、假工程師了。 # David Heinemeier Hansson（Rails之父） DHH在接受[Big Think訪問](http://bigthink.com/videos/big-think-interview-with-david-heinemeier-hansson)時提到： > 說來有點好笑。我以前寫PHP跟Java的時候，常常花時間去摸其他程式語言。到處摸看看其他程式語言…隨便什麼都好。寫PHP跟Java實在太悶了，我需要用這種方式讓自己暫時抽離。 > 我以前寫PHP跟Java的時候，完全不覺得自己之後會當程式設計師。 整段看起來都不像是一個「電腦天才」的自我介紹。 最後讓他愛上的不是電腦本身，而是Ruby程式語言的優雅性。 如果Ruby沒有被發明，DHH現在也許會做完全不同的事情。 --- 這一類可以說明刻板印象大錯特錯的文章實在太多了， 看看工程師們最愛的幾個玩笑：[關於工程師 59 條搞笑但卻真實無比的語錄](http://www.inside.com.tw/2013/12/20/59-hilarious-but-true-programming-quotes-for-software-developers) - 一個人寫的爛軟體將會給另一個人帶來一份全職工作。 - 傻瓜都能寫出電腦能理解的程式，優秀的工程師寫出的是人類能讀懂的程式。 - 開發軟體和建造教堂非常相似——完工之後我們就開始祈禱。 如果工程師都很有天份跟熱情，這些笑話又怎會受歡迎呢。 再看看Medium上很受歡迎的學習系列文章：[資深開發者給後輩的七個 Coding 學習心得](http://buzzorange.com/techorange/2013/11/29/wish-someone-had-told-me-when-learn-coding/) 其中的幾個建議 - 也許常常有人說你是錯的 - 也許常常會有人跟你說「你並不是個 Coder」 - 不要在意外表，能力才是一切 無非就是想打破這類寫程式的迷思、無意義的資格論神話。 下次又有人學到一半，開始反省自己適不適合、夠不夠資格的時候， 我只想跟他說：你就多找幾種方式學學看吧，不要抱持那種奇怪的資格論。 很多時候其實只是[搞錯方法](http://blog.turn.tw/?p=1283)、[搞錯心態](http://blog.turn.tw/?p=2568)而已。 真的完全學不懂再放棄吧。 寫程式不需要天份，也不需要熱情。 (Photo via Sano Rin, CC licensed.)
最近看到滿多年輕學生、考慮轉職者提問：未來 ChatGPT 會取代軟體工程師嗎？ 看來這個議題已經造成不少 IT 領域學生的焦慮，我非常驚訝，讓我簡單談論一下這件事 # 個人經驗回顧 我在畢業前全心學習 web 前端與後端開發，2012 年畢業時，正逢智慧型手機快速發展，所有公司都在思考如何開發手機 app 來創造新機會，當時媒體的主要論述是：「web 已死！web 工程師都將失業，未來是 mobile app 的世界！」 當時年輕的我，看到這些媒體這樣分析，也是有點焦慮，但同時又有點不服氣，所以依然 100% 心思在研究 web 開發，不管媒體怎麼看衰。現在，10 年過去了，請問 web 職缺消失了嗎？ # 媒體的習慣、網紅 YTer 的習慣 想像你住在一個非常小的島嶼國家上，往外走一下就看到海，國家全年365天基本沒什麼大事，每天就是太陽升起、太陽落下。如果你是島上的「新聞從業人員」，請問你每天能做什麼？你當然只能誇大你看到的每件事情。 看到海水漲潮，發新聞：「海水異常上漲！恐有釀禍危機！全國一半人口恐有水災、死亡風險！」 看到海水退潮，發新聞：「近三年最低點！海水不斷消退、國家水資源流失、重大警訊！我國恐成大型沙漠！」 世界上大多數事情本就「帶有波動性」，一下狀況好一下狀況壞，潮起又潮落，正如月有陰晴圓缺，這相當正常。 媒體、網紅，基本上需要吸引人們關注來過活，他總不能每天發新聞：「今天海水正常漲潮，沒什麼特別的。」、「今天海水退潮了，這很自然，不太重要。」 身為現代公民，你要有能力透過媒體吸收新知，但同時也要有能力保持冷靜、自行判斷，不要隨意被影響。你要能看出各種觀點背後相關的利益。 # AI 對職缺的影響 AI 當然對各行各業會有重大衝擊，但是目前也僅止於改善工作效率、優化流程而已。 AI 因為可以加強專業人員的生產力，所以會造成職缺變少一點，但要到「軟體工程師通通失業」、「就靠機器人寫完所有程式」這種程度，實在太誇大了 最後，程式設計已經是各種工作領域之中，最難被機器取代的職缺之一，如果真的被高階人工智能取代，那社會上已經沒有多少工作適合人做，大概會是「無條件基本收入」制度之類的社會 --- # 結論 太廢的技能、感覺問 google 或問 ChatGPT 就有的東西，可以不用學了，像死背課文一樣的任務再也不用做了 除此之外，該學什麼學什麼，不用想太多 上個時代，懂得善用 google 與網際網路的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 下個時代，懂得善用 AI 的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 除此之外，跟案主溝通、釐清功能規格、分析各種技術選擇、認識領域知識並設計軟體，是極度複雜的工作，你真的覺得一個機器人放在面前聊天幾分鐘，它就能通通做完給你？ --- 以上，簡單看法分享
對於轉職寫程式、或是業界情況好奇、擔心的人很多 簡單分享一些看法＆建議 # 前端好像很氾濫，現在適合轉職前端嗎？ 過去幾年，我指導過很多非本科的朋友入行，幾乎都是從前端入行（也有少數是從 iphone 開發、網站後端、資料科學入行） 我都分別問過這些朋友 轉職前的薪資 說真的 在台灣 有很多產業、領域 薪水對年輕人真的很不友善 寫程式這一行 前端雖說門檻低、就業者越來越多 這些都是事實 但是 跟很多行業比起來 薪水還是有比較好 而且進步空間很多（台北的工作機會又會更多一些） 所以 如果受不了原本產業的低薪 考慮寫程式 就試試看吧 先找書 或是便宜的線上課程試試就對了 （真的要花數萬～十幾萬找補習班之前，切記要多打聽，多比較） # 2023景氣好像很差，很多軟體公司裁員，業界很慘嗎？ 新聞上看到的 矽谷各大科技公司裁員幾千幾萬人 都是真的 但是台灣的軟體業還沒出現這情況 主要原因是 北美的公司本來就比較多「創業投資人」的資源＆募資 台灣的軟體業本來就沒拿到多少投資人的錢 😂 簡單講就是窮習慣了 現在全球資金緊縮 台灣業界本來就不是特別高薪的地方 所以衝擊反而還好 😂😂 （不過，很多靠過去幾年ABC輪募資撐下來的新創公司 現在都有危機 這是鐵定的） 我有在兼職接案北美的案子 目前北美的案件報酬大概打6折左右 非常慘 什麼時候會回溫不知道 不過，身在台灣，打開徵才網站，很多公司還是有在徵才，篩選條件選「無經驗可」就可找到「可接受半路出家」的職缺 所以，大環境沒辦法預測，想入行的話，還是先學就對了，還是有不少機會 # 我想轉職寫程式，未來也許可以接案子、賺外快，對嗎？ 工作3-5年之後，基本上多少會有親戚朋友，想找人接案寫程式 這種機會有是有，但，有幾件事還是要分享一下 要常態獲得接案收入、甚至全職接案的話，是滿困難的 首先，自由工作者需要有兩個特質，第一個是談判者特質，也就是樂於談判，拉高價碼、限制住案主規格，這樣才能有較好利潤 第二個是銷售者特質，也就是樂於老王賣瓜，自賣自誇，這樣才能被人看見，有更多機會 我認為大多數人並不會喜歡做這兩件事，我自己也不太擅長、也不太喜歡做這兩件事，所以，接案這條路，偶爾賺一點可以，要經營得好，並不容易 最後要說的是，台灣的發案報酬，常常會比你想像的還要「低很多」，有人拿幾千元就希望你架一個網站給他，或者各種離譜的情況，很多 這些都要花時間處理，很多時候綜合比較下來，直接在一間不錯的軟體公司上班、學習，還比較好 以上，簡單分享，大家有什麼問題，可以多多提問，我盡量回答
## 課程目標 - 學會處理 git 衝突 ## 課程內容 這課來學一下 commit 彼此有衝突，而 git 沒辦法自動合併的情況吧 先挑一個資料夾，把 `my-work-1.html` 裡面隨意加上幾行內容 ``` <p>我的第一個網頁檔案</p> <p>new content a</p> <p>new content b</p> <p>new content c</p> ``` 接著 ``` git add my-work-1.html git commit -m 'new content abc' git push ``` 順利送出！ 然後去另一個資料夾，把 `my-work-1.html` 裡面隨意加上幾行內容 ``` <p>我的第一個網頁檔案</p> <p>new content x</p> <p>new content y</p> <p>new content z</p> ``` 接著 ``` git add my-work-1.html git commit -m 'new content xyz' git push ``` 結果失敗了！一如預期，被 git 喊停了 ``` To github.com:howtomakeaturn/my-first-testing-repo.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'github.com:howtomakeaturn/my-first-testing-repo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. ``` 預期之中，這時應該 pull 對吧？ ``` git pull ``` ``` remote: Enumerating objects: 14, done. remote: Counting objects: 100% (12/12), done. remote: Compressing objects: 100% (4/4), done. remote: Total 8 (delta 3), reused 8 (delta 3), pack-reused 0 Unpacking objects: 100% (8/8), 792 bytes | 79.00 KiB/s, done. From github.com:howtomakeaturn/my-first-testing-repo d999c25..2cf01f4 main -> origin/main hint: Pulling without specifying how to reconcile divergent branches is hint: discouraged. You can squelch this message by running one of the following hint: commands sometime before your next pull: hint: hint: git config pull.rebase false # merge (the default strategy) hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. Auto-merging my-work-1.html CONFLICT (content): Merge conflict in my-work-1.html Automatic merge failed; fix conflicts and then commit the result. ``` 在前一課，我們 pull 之後，會被 git 自動把雲端版本、跟本機你剛改過的版本，合併在一起，然後在終端機編輯器內，請你打一段小訊息，備註這次合併 這次，卻沒有進入終端機編輯器內，而是跳出一串訊息！ 注意看最後幾行！ ``` Auto-merging my-work-1.html CONFLICT (content): Merge conflict in my-work-1.html Automatic merge failed; fix conflicts and then commit the result. ``` 這就是 commit 衝突的情況：兩個 commit 都有改到同樣檔案，雖然先後時間不同，但是 git 不敢直接用新的蓋掉舊的！ git status 看一下 ``` Unmerged paths: (use "git add <file>..." to mark resolution) both modified: my-work-1.html ``` 清楚寫出了：both modified，兩邊都修改過！ 打開 `my-work-1.html` 看一下 ``` <p>我的第一個網頁檔案</p> <<<<<<< HEAD <p>new content x</p> <p>new content y</p> <p>new content z</p> ======= <p>new content a</p> <p>new content b</p> <p>new content c</p> >>>>>>> 2cf01f4f63f5ea9040610495688f08032761a170 ``` 看起來很嚇人，其實，只是 git 怕你看不清楚，用一種誇飾法，列出衝突的地方而已！ HEAD 段落，是你剛提交的 commit 部份 `2cf01f4f63f5ea9040610495688f08032761a170` 的部份呢？則是剛剛從 github 抓下來的 commit 代號！ 要如何處理衝突呢？其實，你就決定一下，衝突這幾行，到底要怎麼合併就可以了，然後把 git 誇飾法的地方刪掉 比方說，我決定讓行數交錯呈現吧 ``` <p>我的第一個網頁檔案</p> <p>new content a</p> <p>new content x</p> <p>new content b</p> <p>new content y</p> <p>new content c</p> <p>new content z</p> ``` 改完之後 ``` git add my-work-1.html ``` ``` git commit -m 'handle conflict' ``` 手動合併的 commit，我個人通常習慣訊息就寫 handle conflict ``` git push ``` 大功告成！這就是所謂的 git 衝突處理 ## 課後作業 接續前一課的作業 在上一次的作業，我們嘗試了兩個資料夾，同時 push 送出 commit，導致 git 比對 github 上的雲端版本時，發現有衝突，請你先 pull 再 push 的情況 上次的情況比較單純，因為雖然有衝突，但是 git 一看就知道影響不大，所以 pull 時自動處理了衝突，把事情都安排好了 這次的作業，我們要模擬「遇到衝突，而且 git 無法自動處理衝突」的情況 --- 請按照以下步驟，送出 commit **第一步** 到 `at-home` 資料夾，打開檔案 `about.html` 的內容，原本是 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發</p> ``` 請改成 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發，目標是成為厲害的前端工程師</p> ``` 然後送出 commit，接著 `git push` 出去 你會看到 github 上面就被更新了 **第二步** 到 `at-laptop` 資料夾，假設你今天出門工作，忘記先 pull 了，也忘記檔案其實你已經改好了 打開檔案 `about.html` 的內容，依然是 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發</p> ``` 請改成 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發，目標是成為厲害的軟體工程師</p> ``` 然後送出 commit，接著 `git push` 出去 這時 git 會請你先更新，於是你輸入 `git pull` 你會發現 git 表示遇到衝突，無法自動合併，請你處理！ 原來有一邊是寫「前端工程師」，另一邊是寫「軟體工程師」 git 無法自動判斷你到底是想要以哪個為準！（其實用哪個都可以吧！） 請處理這個 conflict 衝突，處理完之後 push 到 github 上面 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 可以把 github 專案連結，貼到留言區
我是web工程師，從剛開始學MVC就深感困惑： - 怎麼每個地方說的MVC都不太一樣？ - 有些文章講的MVC，跟我正在用的MVC，怎麼像完全不同的東西？ Model、Controller、View三者到底如何互動？真是一個定義不明、含糊不清的名詞。 這讓我研究了很久。最後，發覺它是一個嚴重的誤會。 這個誤會導致了學習和溝通上的代價，請聽我娓娓道來。 # 哪些是MVC？ web領域，不論前端(client-side)、後端(server-side)、不論什麼程式語言，幾乎所有framework都自稱、或被認為是「MVC」。 有哪些呢？ 前端：Backbone.js、AngularJS、Ember.js… 後端：Ruby on Rails、CodeIgniter、Laravel、Django… 真的是這樣嗎？它們全都是MVC嗎？ # MVC是什麼？ 該怎麼定義MVC呢？ 我們先來看看維基百科怎麼說： > MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。 嗯，跟大家說的一樣。我們繼續往下看： > 模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 看起來有些陌生，整段描述跟你的web開發經驗完全不同，對嗎？ 最大的疑問來自這句： > 那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 後面直接叫你去看觀察者模式(observer pattern)。 問題來了：你有在view跟model之間實作observer pattern嗎？ 也就是說，你的Model在資料改變之後，能主動通知View嗎？ 沒有的話，就根本不符合MVC的定義。 # 全都不是MVC？ 我們現在發現MVC有observer pattern這個必要條件了。 事情嚴重了起來。 client-side framework或許能夠符合這個條件。 以Backbone.js官網範例來說，我們可以這樣在Model上註冊： ``` book.on({ "change:title": titleView.update, "change:author": authorPane.update, "destroy": bookView.remove }); ``` 它的確實作了observer pattern。 但server-side framework呢？ 你的Model如何能在發生改變之後去「主動通知」View？ 你平常開發web哪有用到server push的技術？ 所有server-side framework，從Ruby的Rails；PHP的CodeIgniter、Laravel；到Python的Django，他們全都不是MVC。 它們實作的，是昇陽電腦在1998年提出的「Model 2」。 # 什麼是Model 2？ Model 2名氣不大，在維基百科連中文條目都沒有。我們看看英文條目怎麼講： > Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. > In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. 它針對web而設計，讓controller進行必要的程序之後，將資料塞進view去呈現。 正是我們server-side框架在做的事情。 也就是說，server-side目前只能實作Model 2；client-side可以實作Model 2，也可以實作MVC。 # 巨大的代價 web工程師最常碰的就是client-side跟server-side框架。結果整個業界把MVC跟Model 2混為一談，都說成MVC。 這帶來了什麼後果呢？ MVC變成一個從初學者到業界工程師，永遠說不清楚、下不了定義的名詞。 這件事對於學習和討論，造成了非常巨大的成本。（參考下方的Q1和Q2） # 那該怎麼辦？ 下次有初學者詢問「什麼是MVC」的時候，怎麼回答才不會害他回家之後「越查資料越混亂」？ [Rails is not MVC](http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html)的作者提出了三種解決方法： > 第一個方法是聲稱MVC已經從原始意義改變了，Model 2也可以稱為MVC。如此一來，我們可以用「傳統MVC」或「真MVC」來描述原始的MVC。這是現在普遍的作法，但我不認為改變定義是一個好主意。這幾乎是越搞越亂。 > 第二個方法是到處推廣Rails其實是Model 2，MVC就留給…MVC吧。這很困難，但至少能保持定義不變。 > 第三個是直接忽略這些混亂。管它那麼多？ 我個人覺得MVC這個詞已經沒救了，不管怎麼解釋都會帶給別人混亂。 當對方同時學習client-side跟server-side時，混亂更強烈。 我選擇這樣回答： 「MVC有分很多種喔！網路上全部沒寫清楚，你一定看不懂。 沒關係，你只要知道View可以抽出來就好。 C跟M先別管，你先隨便瞎搞吧。」 --- # Q&A ## Q1: 怎麼可能各大server-side framework都搞錯？ 確實有人腦袋清醒得很，它就是Python的Django。 Django的官方文件內根本沒有「Controller」這個名詞。 看看Django官網的常見問題： > Q: Django似乎是一個MVC框架，但你們把Controller命名為「View」，把View命名為「Template」。你們幹嘛不用標準命名啊？ > A: （前略）…如果你真的很想要一個縮寫，你就說Django是一個MTV框架吧。Model、Template、View。這樣分比較有道理些。 Django不想變成搞亂MVC的幫凶，只好委屈地又發明了一個名詞「MTV」。 ## Q2: 那client-side框架有受影響嗎？ 有。client-side框架也必須為MVC巨大誤會浪費一堆時間解釋。 看看Backbone.js官網的常見問答： > Backbone跟「傳統MVC」的關聯何在？ > …我們來比較一下Backbone跟像是Rails這種server-side MVC框架的差別… Backbone實作了「傳統MVC」，卻被迫用「傳統MVC」來描述server-side的Model 2，然後花一堆篇幅解釋。 ## Q3: 知道Model 2的存在又如何？我現在依然一片混亂！ 沒錯，Model 2跟MVC都用到Model、Controller、View三個名詞，所以看起來類似。 但是，我們不應該再把時間花在思考「MVC怎麼如此難懂」。 我們討論的重點，應該是「如何分辨MVC與Model 2」、「在server-side如何實作Model 2才漂亮」、「在client-side實作MVC跟Model 2的優劣分別何在」。 ## Q4: 好，那你現在回答我，「如何分辨MVC與Model 2」？ OK，就讓我拋磚引玉一下。 分別談談Model、View、Controller吧： ### View - Model 2: 不具有行為，只是等別人塞資料進去的模板（template）。 - MVC: 具有監視Model的行為，並以此去改變呈現（presentation）。 兩種View有沒有很像？跟張飛、岳飛一樣像。 看看Backbone.js官網的View範例。你server-side的View哪是長這樣？ ``` var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, initialize: function() { this.listenTo(this.model, "change", this.render); }, render: function() { ... } }); ``` ### Controller - Model 2: 接收請求與參數，轉交給Model處理，再把結果（最新的資料）塞進View。 - MVC: 接收請求與參數，轉交給Model處理。沒其他事了。 兩種Controller有沒有很像？跟小狗、熱狗一樣像。 MVC的View跟Model 2的Controller可能還比較像一點。（隨便說說，千萬別這樣類比。） ### Model - Model 2: 接收Controller傳來的參數，回傳結果。 - MVC: 接收Controller傳來的參數，將結果通知View。 Model倒是有些類似。 總之，Model 2跟MVC除了三個部份的名字一樣之外，沒什麼關聯了。 ## Q5: 我決定徹底鑽研MVC跟Model 2的定義了。給我一些延伸閱讀？ http://www.ithome.com.tw/node/77330 http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html https://docs.djangoproject.com/en/1.7/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names http://backbonejs.org/#FAQ-mvc https://r.je/views-are-not-templates.html --- ##一些社群的看法（2015-2-28） 附上幾個社群的連結，裡面有許多很棒的討論。 https://www.facebook.com/groups/javascript.tw/permalink/600136880087654/ https://www.facebook.com/groups/199493136812961/permalink/759391387489797/ https://www.facebook.com/groups/pythontw/permalink/10153760201638438/ https://www.facebook.com/mosky.liu/posts/10203964969186383 http://www.ithome.com.tw/voice/94877
## 目錄 ##### [【前端動手玩創意】等待的轉圈圈效果 (1)](https://ithelp.ithome.com.tw/articles/10311621) ##### [【前端動手玩創意】google五星評分的星星(2)](https://ithelp.ithome.com.tw/articles/10311643) ##### [【前端動手玩創意】CSS-3D卡片翻轉效果(3) (今天難度頗高，想挑戰再進來！)](https://ithelp.ithome.com.tw/articles/10311672) ##### [【前端動手玩創意】一句CSS做出好看的hero section！(4)](https://ithelp.ithome.com.tw/articles/10311691) ##### [【前端動手玩創意】創造一個Skill bar(5)](https://ithelp.ithome.com.tw/articles/10311756) ##### [【前端動手玩創意】遮蔽廣告(D卡未登入)腳本、自定義新增名單(6)](https://ithelp.ithome.com.tw/articles/10311999) ##### [【前端動手玩創意】前端canvas截圖的招式！竟然有三招，可存成SVG或PNG (7)](https://ithelp.ithome.com.tw/articles/10312001) ##### [【前端動手玩創意】讓你的PDF檔案更難被抓取(8)](https://ithelp.ithome.com.tw/articles/10312046) ##### [【前端動手玩創意】哇操！你敢信？花式寫todo-list，body裡面一行都沒有也能搞？(9)](https://ithelp.ithome.com.tw/articles/10312056) ##### [【前端動手玩創意】卡片製作，才不是！是卡片製作器！(10)](https://ithelp.ithome.com.tw/articles/10312066) ## 前情提要 各位知道jquery，這個JS的函式庫提供我們非常多實用的方法，包裝好給我們用。 其中底層邏輯都還是跑不出js原生的概念， 今天就讓我們用原生JS的類來創造一些Jquery幫我們打包好的方法吧！ 來掀開它的奧秘底牌。 ## 程式碼內容 假設我們要創造一個叫做Dquery的東西，該怎麼做呢： ``` class Dquery { constructor(selector) { this.elements = document.querySelectorAll(selector); //噴出DOM來 } css(property, value) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].style[property] = value; } return this; //修改style } addClass(className) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].classList.add(className); } return this; //增加class } removeClass(className) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].classList.remove(className); } return this; } on(eventType, callback) { for (let i = 0; i < this.elements.length; i++) { this.elements[i].addEventListener(eventType, callback); } return this; //監聽事件的運作 } html(htmlString) { if (typeof htmlString === 'undefined') { return this.elements[0].innerHTML; } else { for (let i = 0; i < this.elements.length; i++) { this.elements[i].innerHTML = htmlString; } return this; } } } function $(selector) { return new Dquery(selector); } ``` ## 觀念筆記 其實概念就是先把底層邏輯刷過一遍 最後return this 就達成jquery的效果了唷。 ## 心得 Jquery曾經非常流行，儘管後來式微了，卻還是有一批死忠的粉絲鍾愛著它的簡便， 事實上它就是JS，所以討人喜歡也是正常的， 這次學會了用ES6類的概念，會讓我們在前端的功力大幅提升唷！！
## 前情提要 最近在網上想找一些學習前端的夥伴，發現要組個討論會非常的難。 是因為沒有人學前端嗎？不是，與事實相反，非常多人學。那麼是因為大家程度太差嗎？ 也不是，其實自學的人吸收能力都不錯。 那到底是因為什麼，其實是源自於一個魯蛇心態：「貶低自己、迂迴溝通」 ## 觀念解說 什麼意思？貶低自己？沒錯，很多前端新手當要進行自我介紹或是參加討論， 都因為自尊心太高，要幫自己打上一堆預防針：「我還是菜鳥，我什麼都不會。」 當人家問你說寫過什麼，就說：「都只是一些人家的作業，我沒有做什麼耶」 你以為謙虛是一種美德，事實上這種噁心的做作，只是降低大家討論進步的溝通效率， 要人家稱讚你老半天說：「不會啦！很棒，有東西就拿出來」 你才願意把你自己的作品連結丟出來。 事實上你明明就有自己嘗試做過一些東西，一定要迂迴老半天才願意拿出來，真的太假掰。 ## 健康的心態 那麼前端的新手應該具備什麼心態呢？我們要培養的不是假裝謙虛：「我什麼都不會啦，只是照著做」 「就看網路課程而已，我只是剛摸過js」 「對框架沒概念耶，只是看過VUE的課程。」 就省去這些假掰的噁心詞彙，你學過什麼就說出來，把自己會的東西講出來， 明明學過，又不願意老實講，真的很糟糕。 這不僅是對自己的尊重也是尊重別人。 別人沒有義務必須要每一次的對話都要先稱讚你，才有辦法跟你討論正事。 格局多大，完全建立在你自己的心態健康不健康之上。 做過什麼作品，就算是抄課程上的那就拿出來講，表達出來才有辦法討論。 不是明明你也想要找學習夥伴討論、交流，真的要互相討論的時候才拿出來當作藉口。 那你到底是想要進步，還是你只是想要人家安慰？ ## 總結心得 我不知道這是源自於人格上的自卑，又或是東方文化容易被打擊所培養的自我防禦意識。 但在前端程式的交流，真的要練習培養大方的態度， 實事求是，不需要你把自己包裝的多厲害，只要不要你裝模作樣說自己什麼都不會、 什麼都沒寫過， 問了老半天才要把你明明偷偷嘗試過的五種作品拿出來，才發現你bs5也碰過、VUE也學了， 那講了老半天的預防針到底有什麼意義？ 請培養健康正確的心態，不要看不起自己，也請尊重別人跟你溝通的對談成本。 真的沒有人有義務一路上安慰你，想要討論交流，你必須擁有正確大方地表達、人格態度。
正想分享近期面試心得，站長就先PO文了，哈哈 由於我本身是美術科系畢業，之前也是做包裝和平面設計的工作，所以網頁設計和前端的職缺我都有投，目標是先讓自己進入業界環境。 剛開始蠻挫折的因為沒什麼前端junior職缺，且職缺要求五花八門技術又要有相關工作經驗或是相關科系，工作內容好像什麼都要會，也很多我看不懂的工具... 過一兩週後，開始有人找我，但大多都是網頁設計相關的工作，至於工作內容也很雜，且薪資也不在預期之中。 這幾天陸續面試，其實沒什麼自信且緊張，有些公司面試有筆試，拿到試題腦袋一片空白，平常用電腦打字，現在變成拿筆寫出code或回答問題，最後就把試題會的部分寫一寫，完全看不懂的就跳過，之後面試官來面試我，原本想說試題好多都不會，根本亂寫一通，可能會被洗臉，先做好心理準備XD 結果面試官一題一題有耐心的問我為什麼會這樣回答，不管我答對還是錯面試官都詳細的告訴我釐清觀念，其實考官有說題目都比較刁專有陷阱，因為知道我是初學者，所以也在他預料範圍內，很感謝他們耐心教導，對方也告訴我一些這方面的經驗或關鍵字，真感人！ 總之，近期的面試都吸取很多知識和建議，也被面試官提點我的JS部分要在深入學習扎實一點，還有去看看什麼是clean code --- 分享一下面試題目(我比較有印象的) ``` if ([]) { console.log('Y') } else { console.log('N') } //結果為如何 ``` ``` console.log( (0.1 + 0.2) === 0.3 ) //結果為如何 ``` ``` console.log( NaN === NaN ) //結果為如何 ``` ``` console.log(parseInt('123ABC')) //結果為如何 ``` ``` const a = '3' const b = 1 console.log (a+b) //結果為如何 ``` ``` console.log ([...'...'].length) //結果為如何 ``` 還有一系列的`typeof`型別比較問題，但我無法**直覺信心**的直接寫出答案 因為平常都是寫code時順便用`console.log`來確認型別，這部分要再重新複習😥 還有一些`class`和`this`的試題，我完全看不懂也不會😵 先分享這樣，希望近期能收到好結果～～
[【前端動手玩創意】哇操！你敢信？花式寫todo-list，body裡面一行都沒有也能搞？](https://ithelp.ithome.com.tw/articles/10312056) ## 前情提要 如果說蟑螂怕拖鞋，老鼠愛大米，任何事物都有相生相剋的道理，那麼前端最害怕什麼呢？ 恐怕就是todo-list。 這應該是前端的四大惡夢之一，並不是因為太難了，而是因為太簡單而且太無聊了， 不只無聊，還是每次教學都必須寫的一個磨難，簡直是瞬間殺死靈魂中隊前端的愛。 今天要來用不同風格寫出todo-list，把代辦事項寫出新滋味。 body裡面一行都沒有也能搞？ 就是可以搞，讓我們馬上來欣賞這段有特別滋味的玩法！ε(*´･∀･｀)зﾞ ## 程式碼 ``` <!DOCTYPE html> <html> <head> <title>Todo List</title> </head> <body></body> <script> //渲染DOM AddHtml(); //資料內容 function AddHtml() { const Data = { h1: "Todo List", button: "Add", }; //主體的DOM const html = `<h1>${Data.h1}</h1> <input type="text" id="input" /> <button onclick="CheckNull()">${Data.button}</button> <ul id="list"></ul>`; //渲染至畫面上 document.body.innerHTML += html; } //邏輯確認:是否有輸入值 function CheckNull() { if (!input.value.trim("")) { return; } else { AddItem(); } } //新增代辦事項 function AddItem() { const li = `<li>${document.getElementById("input").value}</li>`; document.getElementById("list").innerHTML += li; input.value = ""; } </script> </html> ``` [可以貼到try it的地方執行看看效果](https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_form_submit) ## 觀念筆記 所謂MVC架構就是模型、視圖、控制，背後其實有一個元素貫串任何程式，那就是：「邏輯」 每當你要下手寫一個程式卻不知道怎麼開始動手， 那就是邏輯沒有通順。 網頁不外乎就是畫面，以及資料，還有使用者的操作。 對於todo-list來說就是一個簡單的input畫面，使用者輸入的資料，點下按鈕送出的操作。 這段程式特地不寫任何一行body裡面的東西， 玩弄了一般人對於程式區分的概念。 用模板符的特性讓所有一切交給變數與函式處理，最後三個function： AddHtml、CheckNull、AddItem完美演繹了代辦清單這個網頁所需要構成的底層邏輯。 必須先加入畫面，然後確認使用者操作的條件，最後新增資料。 這樣子的流程對於新手或許不習慣，但是以邏輯面來看比一般人的寫法清晰許多。 這也是未來框架導入後，對資料流更敏感的培養練習。 ## 心得 無聊的todo-list竟然可以搞成這樣！？ 真的是太有趣了(๑╹◡╹๑)！ 原來前端的惡夢也可以變成寫不同風格的天堂，沒錯，寫程式就是這麼千變萬化！ 重點是背後的邏輯抓到了，那麼想要怎麼寫，真的就是藝術的發揮。 請繼續關注， 跟著我們這個系列繼續動手玩創意！！未來還有更多更新鮮的花招呢(｡◕∀◕｡)
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
