🔍 搜尋結果:api

🔍 搜尋結果:api

JS教學-文章縮圖預覽,夢幻連動的腳本教學!

## 前情提要 常常寫文章的時候都會運用到圖文並茂, 如果可以設定文章的圖片封面就是一個很棒的設計。 今天的JS腳本教學已經夢幻連動! 原本IT幫的文章與codeLove像是平行宇宙,只有偶爾轉載,現在, 教學內容直接來針對codelove來寫一個小小有趣小功能XD ## 目標設計 今天以codelove這個論壇為例, 讓我們來手動創造一個小腳本:分析文章內容,以正則去匹配圖片網址, 然後透過create的API寫出div,並且監聽事件, 當點擊圖片的時候,把圖片網址放到封面圖片的input欄位。 ## 效果 會根據textArea change的時候來匹配出網址。 並且創建div與img元素去放入網頁。 ![](https://i.imgur.com/sHcMDU8.png) 點圖片後會把圖片網址丟入。 ![](https://i.imgur.com/MWhkOB7.png) ## 程式碼內容 ``` // 獲取textarea元素 var textarea = document.querySelector("body > div.container.px-0 > div > div.col-12.col-lg-9 > div > div > form > textarea"); var featuredImageInput = document.querySelector('input[name="featured_image"]'); textarea.addEventListener('change', function(event) { // 檢查是否存在imgBox元素 let imgBoxCheck = document.querySelector('.imgBox'); if (imgBoxCheck) { // 如果存在,則刪除imgBox元素 imgBoxCheck.parentNode.removeChild(imgBoxCheck); } // 獲取文本框的內容 var ContentText = textarea.value; // 創建一個空數組來存儲圖片鏈接 var imgArray = []; // 使用正則表達式查找圖片鏈接 var urlRegex = /https?:\/\/[^\s/$.?#].[^\s]*/gi; // 匹配以http或https開頭的鏈接 var matches = ContentText.match(urlRegex); if (matches) { // 疊代所有匹配項並篩選出以.png或.jpg結尾的鏈接 for (var i = 0; i < matches.length; i++) { if (matches[i].match(/\.(png|jpg)$/i)) { imgArray.push(matches[i]); } } } // 使用正則表達式匹配鏈接部分 var regex = /!\[\]\(([^)]+)\)/g; var match; while ((match = regex.exec(ContentText)) !== null) { imgArray.push(match[1]); } // 創建一個包含圖片的容器div(imgBox)並設置為display: flex let imgBox = document.createElement('div'); imgBox.className = 'imgBox'; // 添加類名 imgBox.style.display = 'flex'; // 平均分配圖片大小 var imageSize = 100 / imgArray.length; // 假設100%寬度,根據圖片數量計算每張圖片的寬度 // 將圖片鏈接轉換為img元素並插入到imgBox imgArray.forEach(function (imgUrl) { var imgDiv = document.createElement('div'); var img = document.createElement('img'); img.src = imgUrl; img.className = 'imgCover'; img.addEventListener('click', function () { // 設置name="featured_image"的輸入框的值為被點擊圖片的src屬性 featuredImageInput.value = img.src; }); // 設置img的寬度為100% img.style.width = '100%'; img.style.height = '100%'; imgDiv.appendChild(img); imgBox.appendChild(imgDiv); }); // 將imgBox插入到textarea後面 h5.insertAdjacentElement('afterend', imgBox); textarea.style.overflow = 'auto'; imgBox.style.border="5px solid gray" imgBox.style.marginTop="5px" }); // 創建一個包含CSS規則的<style>元素 var style = document.createElement('style'); style.type = 'text/css'; style.textContent = '.imgBox:hover .imgCover:not(:hover) { filter: grayscale(100%); opacity: 0.75; }'; // 將<style>元素添加到<head>中 document.head.appendChild(style); h5= document.createElement('h5') h5.innerText='請選擇你的文章縮圖:' h5.style.marginTop="50px" h5.style.fontSize="16px" textarea.insertAdjacentElement('afterend', h5); ``` ## 觀念筆記 這次的腳本內容其實沒有太多新的知識點,算是一個很好的複習。 querySelector addEventListener insertAdjacentElement forEach 以及正則表達式的使用。 ## 心得後記 網頁上的功能,其實就是這些基礎的運用配合起來!(°ཀ°) 所以不用擔心前端沒有東西練習,其實點子四處都有,練習也都很實用。 而不是每次都在重複輪迴相同的東西、感到疲倦! 這次的前端小試身手就帶來一個回鍋菜,下次敬請期待更有趣的變化。 喜歡記得追蹤或留言唷。 還沒挑戰過此系列其他內容的,可以試著去挑戰看看◑ω◐

我在寫程式碼時,會切換的兩種風格:嚴格風 vs 隨興風

最近跟一些年輕的工程師合作,發現系統上線之後 bug 有點多 這當然很正常,不過,如果適度的留意自己的當下的「寫作風格」 其實可以減少很多 bug,或者是可以減少 debug 的時間 這些年工作下來,我發現在開發不同元件的時候,我基本上會在兩種風格中選擇,簡單跟大家分享 # 嚴格風 在寫一些基礎重要元件、或者呼叫第三方 API 時,我認為把「可能的狀態」通通清楚列出來比較好 也就是像這樣 ``` function doTask($arg1) { if ($arg1 === 'val1') { // ... } else if ($arg1 === 'val2') { // ... } else if ($arg1 === 'val3') { // ... } else { throw new Exception("Impossible state."); } } ``` 只要出現預期之外的值,就直接丟出例外,這樣可以大幅改善 developer experience 也就是在當下就提醒同事:「我這元件當初設計不是這樣用的,請檢查」 很多人不會把「可能的狀態」寫完,而是放在 else 底下,比如說 ``` function doTask($arg1) { if ($arg1 === 'val1') { // ... } else if ($arg1 === 'val2') { // ... } else { // handle `val3` here } } ``` 雖然程式課本都是這樣教的,但實務上這會導致很多可能的 bug 比方說有同事在使用這元件時,參數傳入 `val4` 結果程式繼續運行 這會導致一些錯誤的理解、讓錯誤的假設在團隊中持續蔓延 所以,在重要的元件,比如金流相關時,採用這種「嚴格風」去寫會比較好 也就是強迫大家搞清楚這個元件的用法,不准許憑感覺隨意呼叫 # 隨興風 在一些寬鬆的元件,通常是 search 相關的元件、抓資料相關的元件時,可以預期,呼叫方會隨意嘗試各種參數 甚至會有一些參數傳都不傳,覺得元件要有預設才合理 這種元件,就寫得盡量寬鬆、盡量多給預設值,會比較好 也就是呼叫方,參數要傳不傳,都可以,傳錯的時候,就當作是跟沒傳一樣,就用預設值就好 這種元件就是用起來很寬鬆,主要目的是希望不要因為這些小事,讓程式爛掉、故障在那邊 寫起來就是多檢查變數有沒有存在,沒有就給預設值 然後 if else 的時候也比較隨興,基本上不會丟例外,不管怎麼傳都盡量讓你跑 --- 不同的元件,適合採用不同的風格來寫 雖然這是一個主觀的問題,但適當的分辨當下應該採用哪種風格 會讓你的同事非常喜歡跟你工作,覺得你寫的元件「總是很好用」、「用錯的時候都會提醒」、「在不需要拘泥小節的時候,也不會囉唆」 話雖如此,要能知道當下適用的風格,其實需要許多年的經驗累積。 嚴格風、隨興風,只是一個概念,實際上的 coding style 有很多寫法,大家可以慢慢實驗&嘗試 簡單給個方向,跟大家簡單分享

不是共產黨,但是審查低質量雜訊很重要!自己寫一個JS腳本過濾!

本文轉自:https://ithelp.ithome.com.tw/articles/10338948 ## 前情提要 資訊大爆炸。 有時候我們瀏覽技術文章,不一定真的是想學深奧的高級技術。 然而劣質低端的文章充斥著,則會降低我們學習的效率、甚至變成噪音與雜訊,干擾我們的思緒。 因此針對某些洗文或是質量很低的作者,我們必須列為思想犯, 否則會降低閱讀質量,平白浪費自己的時間、平台的版面、上網的電力、看到垃圾資訊的副作用等等.... ## 構思來源 如果有個思想審查警衛可以:**去除那些垃圾低端,稱不上技術文章的雜訊。** 以確保未來瀏覽文章的時候,不會再被洗文打擾, 也可以針對不喜歡的主題去封鎖,讓時間與精神更能專注於自己想要學的資訊。 阻止一些垃圾就是喜歡把自己尚未整理的白痴內容一直丟上來, 什麼都還不懂,把技術文章當成個人日記簿,寫一堆自我囈語、無病呻吟, 每天大量狂發文章,昭告天下以為這就是努力,欺騙自己也浪費別人的人生。 ## 「思想審查警衛」出動! ## 功能 1. 把頭像屏蔽 2. 加上思想通緝犯、紅字與刪除線 3. 新增封殺按鈕 4. 版面通知封殺名單與文章數 5. 透過ajax確認某id的最新ID ## 效果截圖 ![](https://i.imgur.com/kgUYJbl.png) 此截圖僅是腳本示範,跟其使用者無關, 本人沒有任何覺得此使用者發的文章是差勁的意味,我認為非常上進、值得學習。 ![](https://i.imgur.com/G27Ea2F.png) 此圖也只是隨機挑user使用,純粹作為範例用途,不代表我個人意見。 ## 腳本下載 https://greasyfork.org/zh-TW/scripts/477283-%E6%80%9D%E6%83%B3%E7%8A%AF%E5%B0%81%E6%AE%BA ## 原理說明 鄭重聲明,這個示範真的毫無任何私人意味,此腳本也只是針對不同的主題去隱藏, 例如我想學python就不想看到JS的文章,因此使用此工具幫忙隱藏罷了。 取名做思想警察、比喻成清除垃圾等都只是文學上的趣味。 請勿當真Ꮚ・ꈊ・Ꮚ 這次的技術可說比較難,認真難很多!但是趣味性以及功能性是無比的超越! 可以說幾乎是我寫系列文以來,最頂、最派的一篇! 不過很多觀念已經出現過,在【前端小試身手】系列裡面,每次的腳本都是主打實用, 因此cookie或localstorage這種技術當然都會運用到。 ## JS原始碼 ``` // ==UserScript== // @license MIT // @name 👮思想犯封殺 // @namespace http://tampermonkey.net/ // @version 0.1 // @description 把廢文製造機轟出去 // @author You // @match https://ithelp.ithome.com.tw/articles* // @match https://ithelp.ithome.com.tw/users/* // @icon https://www.google.com/s2/favicons?sz=64&domain=ithome.com.tw // @grant none // @run-at document-end // ==/UserScript== let URL = window.location.href; let ArticleSite = "https://ithelp.ithome.com.tw/articles?tab=tech" let UserSite = "https://ithelp.ithome.com.tw/users/" // 判斷URL的開頭部分 if (URL.startsWith(ArticleSite)) { //文章頁執行清理垃圾程序 CleanGarbage(); } else if (URL.startsWith(UserSite)) { UserCheck(); } else { console.log("這邊不執行腳本"); } // 餅乾儲存的機制函數------------------------------------------------- function setListInCookie(list) { document.cookie = 'myList=' + JSON.stringify(list) + '; expires=Wed, 31 Dec 2099 23:59:59 GMT;'; } // 從 Cookie 中獲取 list function getListFromCookie() { var cookieValue = document.cookie.replace(/(?:(?:^|.*;\s*)myList\s*\=\s*([^;]*).*$)|^.*$/, "$1"); return JSON.parse(cookieValue) || []; } function CleanGarbage(){ // 從本地存儲中獲取數據 var myListData = localStorage.getItem("myList"); // 解析數據到變量 list var list = myListData ? JSON.parse(myListData) : []; //list = getListFromCookie()||[]; // 儲存要刪除的字符串名單 // 找到所有CLASS是"qa-list__info-link"的<a>元素 var linkElements = document.querySelectorAll('.qa-list__info-link'); var removedCount = 0; // 初始化已清除的垃圾數量 for (var j = 0; j < list.length; j++) { // 遍歷這些<a>元素,確保文本內容包含"伍貳捌",然後刪除其父元素 for (var i = 0; i < linkElements.length; i++) { if (linkElements[i].textContent.includes(list[j])) { // 開始向上查找父元素 var parentElement = linkElements[i].parentElement; while (parentElement) { // 如果找到具有"classname"為"qa-list"的<div>元素,則刪除它 if (parentElement.classList.contains('qa-list')) { parentElement.remove(); removedCount++; // 增加清除的數量 console.warn('抓到"'+list[j]+'"這位思想犯'); break; // 找到並刪除後,結束循環 } parentElement = parentElement.parentElement; } } } if (removedCount>0){ // 顯示已清除的垃圾數量 console.log('已清除他的 ' + removedCount + ' 篇垃圾');} removedCount=0; } } //------------------------------------------------------- // 為了防止五百八改名,我們針對他的ID去ajax得到他最新的名稱 function FindBitch() { // 使用 Fetch API 獲取指定 URL 的內容 return fetch("https://ithelp.ithome.com.tw/users/20163468") .then(response => response.text()) .then(data => { // 創建一個臨時 div 元素以容納頁面內容 var tempDiv = document.createElement("div"); tempDiv.innerHTML = data; // 查找 class 為 "profile-header__name" 的元素 var profileNameElement = tempDiv.querySelector(".profile-header__name"); if (profileNameElement) { // 刪除元素內的所有 <span> 元素 var spanElements = profileNameElement.querySelectorAll("span"); spanElements.forEach(function(span) { span.remove(); }); // 讀取元素的文本內容,去掉前導和尾隨空格 var text = profileNameElement.textContent.trim(); // 返回處理後的文本內容 return text; } else { return "未找到元素"; } }) .catch(error => { console.error("發生錯誤: " + error); return "發生錯誤"; }); } //------------------------------------------------------- function UserCheck(){ //轉換資料從餅乾到localstorage var currentCookieValue = getCookie("myList"); // 2. 存儲數據到本地存儲 if (currentCookieValue) { var list = JSON.parse(currentCookieValue); // 存儲到本地存儲 localStorage.setItem("myList", JSON.stringify(list)); }else{ FindBitch() .then(text => { let FirstKill = [text]; setListInCookie(FirstKill); }) .catch(error => { console.error("找不到五百八:", error); }); } // 刪除不需要的ID document.querySelector('.profile-header__account').remove(); //封殺按鈕------------------------------------------------- // 找到具有class為"profile-header__right"的元素 var profileRightElement = document.querySelector('.profile-header__right'); var pullRightElement = profileRightElement.querySelector('.pull-right'); // 創建一個新按鈕元素 var BlockBtn = document.createElement('button'); BlockBtn.textContent = '封殺'; // 添加樣式和類名到按鈕 BlockBtn.style.marginTop = '10px'; BlockBtn.style.width = '100%'; BlockBtn.className = 'btn btn-trace trace_btn_border BlockBtn'; // 將按鈕元素添加到"pull-right"元素內部 pullRightElement.appendChild(BlockBtn); // 通緝犯名單的cookie------------------------------------------------ // 從 Cookie 中加載 list(例如,頁面加載時) list = getListFromCookie()||[]; let UserBlock = document.querySelector('.profile-header__name'); let text = UserBlock.textContent.trim(); // 如果使用者已經在封殺名單內的判斷,已存在或不存在 if (list.includes(text)) { BlockStart(BlockBtn); } else { // 針對封殺按鈕進行監聽事件 BlockBtn.addEventListener('click', function() { list.push(text); setListInCookie(list); //先加入到名單內,然後再執行封殺事件 BlockStart(); // 輸出到控制台 console.log('黑名單新增:' + text); //本地儲存機制----------------------------- let currentCookieValue = getCookie("myList"); let list2 = JSON.parse(currentCookieValue); // 存儲到本地存儲 localStorage.setItem("myList", JSON.stringify(list2)); }); } } // ------------------------------------------------ //封殺事件的函數 function BlockStart(){ let BlockBtn = document.querySelector('.BlockBtn'); BlockBtn.textContent = '已封殺'; BlockBtn.disabled = true; BadText(); BadImg(); } //封殺事件函數裡面的細項函數 function BadText(){ // 標記這傢夥是垃圾------------------------------------------------- let UserBlock = document.querySelector('.profile-header__name'); let newHeading = document.createElement('h1'); newHeading.textContent = '思想通緝犯'; // 把思想通緝犯這幾個大字加上去 UserBlock.parentElement.insertBefore(newHeading, UserBlock); UserBlock.style.textDecoration = "line-through"; UserBlock.style.color = "red"; } function BadImg(){ //圖片進行網點作業XD------------------------------------------------- var originalImage = document.querySelector('.profile-header__avatar'); // 創建一個包含交叉紅線的覆蓋層 <div> 元素 var overlayDiv = document.createElement('div'); overlayDiv.style.position = 'absolute'; overlayDiv.style.width = '150px'; overlayDiv.style.height = '150px'; overlayDiv.style.background = 'linear-gradient(45deg, black 50%, transparent 50%), linear-gradient(-45deg, black 50%, transparent 50%)'; overlayDiv.style.backgroundSize = '5px 5px, 5px 5px'; overlayDiv.style.backgroundPosition = '0 0, 0 2px'; // 將覆蓋層疊加到圖片上 originalImage.parentNode.appendChild(overlayDiv); // 設置覆蓋層的位置,以與原始圖像對齊 overlayDiv.style.top = originalImage.offsetTop + 'px'; overlayDiv.style.left = originalImage.offsetLeft + 'px'; // 設置覆蓋層的z-index,以確保它在圖片上方 overlayDiv.style.zIndex = '2'; } ``` ## 觀念筆記 這個腳本開發足足花了我一整個晚上,將近八小時之久。 有趣的是,其中為了進行測試才選某些user當作隱藏對象,否則腳本執行上會出錯。 細心的人若觀察原始碼,也會發現裡面有個firstKill, 那是必須要的段落,先設置好cookie的首要內容物,才有辦法繼續操作下去( ิ◕㉨◕ ิ) 也就是初始化的概念XD 另一個有趣的點是,為了防止使用者改名導致腳本出錯,我甚至不惜再寫一段ajax, 去更新一下ID,這樣不管人家怎麼改,都逃不了, 要改成「別抓我」也沒用,這個腳本都還是可以run。 ## 心得後記 我只能說這篇是自從「備份IT幫發文、一眼全覽」最強的JS教學文章! 超派,真的不騙( メ∀・) 有些人喜歡看前端小試身手,有些人喜歡前端動手玩創意; 其實這兩個系列的本質都是JS的教學,是可以互相連接的,但也有很多不同的重心。 這個系列就是以腳本為主,重點在於創意與發想,打到使用者痛點。 【前端動手玩創意】則是以建構網站為起點, 任何元素與概念都會變成網頁上的一部分,算是比較基礎工的建立。 如果對JS的強大感興趣,那麼可以把這兩個系列交互看,反覆的閱讀、實際動手操作, 這樣一來的學習非常踏實,甚至比YT學習都來的高效率、實際。 尤其此系列都是原創發想的腳本,當然超強! 喜歡記得關注,未來還有更多超酷的前端內容可以玩,下課⧸⎩⎠⎞͏(・∀・)⎛͏⎝⎭⧹

肏!原來JS寫腳本這麼簡單?手把手教你玩油猴!

本文轉載自:https://ithelp.ithome.com.tw/articles/10338469 ## 前情提要 有時候,夜深人靜,總是會想要沉思人生的意義。 於是打開某個網站, 開始看一些只有長大了才能看的大人動作愛情學,必須好好鑽研, 此刻電影裡的聲響徹雲霄,你感覺無比尷尬..... 這時候就需要靜音神隊友。 可以自己加入網頁名單,讓小電影們先保持靜音,自己再手動開啟。 如此一來非常保險,絕對不讓你不小心爆音。 非常的有禮貌,人生的哲理更奧妙了。 ## 腳本下載 ![](https://i.imgur.com/qgX2gr6.png) https://greasyfork.org/zh-TW/scripts/477196-%E9%9D%9C%E9%9F%B3%E5%B0%8F%E5%8A%A9%E6%89%8B ## JS程式碼 ``` // ==UserScript== // @name 靜音小助手 // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match https://*/* // @icon https://www.google.com/s2/favicons?sz=64&domain=xvideos.com // @grant none // ==/UserScript== // 定義 JSON 資料,包含網址開頭 var jsonUrls = [ "https://www.xvideos.com/", "https://example.com/json2", // 添加更多的網址開頭 ]; // 取得當前網址 var currentUrl = window.location.href; // 檢查當前網址是否以 JSON 中的某些開頭開始 var isJsonUrl = jsonUrls.some(function(jsonUrl) { return currentUrl.startsWith(jsonUrl); }); // 如果當前網址符合 JSON 的某些開頭,執行程式碼 if (isJsonUrl) { // 在這裡放置你想要執行的程式碼 console.log("當前網址符合 JSON 開頭"); Mute(); } else { console.log("當前網址不符合 JSON 開頭"); } function Mute(){ // 取得網頁上所有的 <video> 元素 var videoElements = document.getElementsByTagName('video'); // 迭代所有的 <video> 元素並將其靜音 for (var i = 0; i < videoElements.length; i++) { videoElements[i].muted = true; } } ``` ## 觀念筆記 只能說,前端的東西往往越簡單,越強。 這次只是使用三個小觀念,都是超級基本的小小觀念,幼稚園等級。 ### 第一部分:使用陣列儲存網址 ``` // 定義 JSON 資料,包含網址開頭 var jsonUrls = [ "https://www.xvideos.com/", "https://example.com/json2", // 添加更多的網址開頭 ]; ``` 這部分就是把我們的資料儲存起來,可以自己新增訂義哪些網址要被匹配。 ### 第二部分:location的API 使用網址要確認網址,就是用location,這已經屢見不鮮。 另外字串的搜查,startsWith非常老舊卻也很無敵。 ### 第三部分:影片靜音API 很簡單,針對video元素muted就可以了,非常輕鬆! 簡直就像早餐吃鬆餅一樣,鬆。 ## 心得 很多人常常說前端,好難,JS好基八 我是覺得,關你屁事?/ᐠ。ꞈ。ᐟ\ 你會罵蛋餅為什麼要這麼蛋餅嗎,蛋餅之所以好吃就是因為它是蛋餅,不好吃也因為它是蛋餅。 JS的奇怪或是難懂,只是它的本質,在那邊靠北靠母的風氣真的很無聊。 要玩梗也可以多一點新的梗,而不是表面嘴皮耍耍。 它很機八,但也很強,這就是JS的厲害之處。 因此這個簡單實用的小腳本,又再次被我們秒殺了! 喜歡可以關注,未來還會有更多JS的小試身手、前端動手玩創意也還有一堆素材呢⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾

前端可以這樣玩??JS腳本-IMG複製大師,懶人專用小腳本

## 轉載自 https://ithelp.ithome.com.tw/articles/10338052 ## 前情提要 有時候我們需要使用一些圖片,勢必需要圖片的網址,這時候, 也許你可以本機上傳,然後去把網址抓好, 又或者你可以找到網路上別人的圖片,右鍵開啟新分頁,再複製網址; 又或者直接打開檢查(F12)找到src的網址去複製。 光聽這個流程我就覺得,心累。 這時候前端大師,就會寫一套簡單的小腳本來完成這個白爛的工作。 ## 腳本下載 ![](https://i.imgur.com/D1s1kxi.png) https://greasyfork.org/zh-TW/scripts/477141-img%E8%A4%87%E8%A3%BD%E5%A4%A7%E5%B8%AB ## JS程式碼 ``` // ==UserScript== // @name IMG複製大師 // @namespace http://tampermonkey.net/ // @version 0.1 // @description 針對網頁上圖片,點擊就複製其網址 // @author You // @match *://*/* // @icon https://www.highcharts.com/demo/highcharts/spline-plot-bands // @grant none // ==/UserScript== let isEventActive = false; // 用於跟蹤事件的狀態 // 創建一個鏈接元素並設置其屬性 const toastrCssLink = document.createElement('link'); toastrCssLink.rel = 'stylesheet'; toastrCssLink.href = 'https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/css/toastr.min.css'; // 創建一個腳本元素並設置其屬性 const toastrScript = document.createElement('script'); toastrScript.src = 'https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js'; // 創建另一個腳本元素並設置其屬性 const toastrScript2 = document.createElement('script'); toastrScript2.src = 'https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js'; // 將鏈接元素和腳本元素添加到文檔頭部 document.head.appendChild(toastrCssLink); document.head.appendChild(toastrScript); document.head.appendChild(toastrScript2); // 獲取頁面上的所有img元素 const images = document.querySelectorAll('img'); function removeClickHandler(image) { image.removeEventListener('click', clickHandler); } function toggleEvent() { if (isEventActive) { // 如果事件已經激活,則關閉事件 console.log('IMG複製大師關閉ꐦ°᷄д°᷅'); // 解除事件監聽 images.forEach(removeClickHandler); isEventActive = false; } else { // 如果事件尚未激活,則打開事件 console.log('IMG複製大師啟動ฅ^•ﻌ•^ฅ'); // 遍歷所有img元素 images.forEach((image) => { // 檢查圖像是否已加載 if (image.complete) { // 圖像已加載,直接添加點擊事件處理程序 addClickHandler(image); } else { // 圖像尚未加載,等待加載完成後再添加點擊事件處理程序 image.addEventListener('load', () => { addClickHandler(image); }); } }); isEventActive = true; } } document.addEventListener('keydown', (event) => { if ((event.key === 'q' && event.ctrlKey) || event.key === 'F8') { toggleEvent(); // 切換事件的狀態 } }); function transformImageUrl(url) { // 使用正則表達式匹配URL中的目標部分 const regex = /https:\/\/cache.ptt.cc\/c\/https\/i.imgur.com\/([^?]+)/; const match = url.match(regex); if (match) { // 如果匹配成功,構建新的URL const imgurId = match[1]; return `https://i.imgur.com/${imgurId}`; } else { // 如果沒有匹配到目標部分,返回原始URL return url; } } // 創建一個函數,用於添加點擊事件處理程序並處理圖像的src function addClickHandler(image) { image.addEventListener('click', clickHandler); } // 創建一個函數,用於處理點擊事件 function clickHandler() { let src = this.src; src = transformImageUrl(src); const textArea = document.createElement('textarea'); textArea.value = src; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); document.body.removeChild(textArea); // 使用 toastr 進行通知 toastr.success('網址複製完成: ' + src); } ``` ## 觀念筆記 這個小腳本總共使用了大概三種觀念, 第一種就是toast的套件使用, 第二個是監聽鍵盤做開關, 第三個則是程式本身對於img的監聽,把src複製到剪貼簿。 ### 第一部分:套件 使用套件在於腳本,必須利用appendChild,先使用create的API製作出放置CDN的link元素, 再把它append到網頁上,則可以使用其套件。 ### 第二部分:監聽鍵盤 這腳本啟動與關閉是透過監聽鍵盤的,ctrl+q或F8這部分就是純粹監聽。 ``` document.addEventListener('keydown', (event) => { if ((event.key === 'q' && event.ctrlKey) || event.key === 'F8') { toggleEvent(); // 切換事件的狀態 } }); ``` 裡面寫了一個toggleEvent是因為想要設定可以開開關關。 ### 第三部分:程式本身 這邊有一點小技巧是複製到剪貼簿,其實以前文章也有寫過教學,是個常見實用的招數: ``` const textArea = document.createElement('textarea'); textArea.value = src; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); ``` 再來就是針對網頁上全部的img元素,去監聽點擊事件、移除事件這兩個。 ``` const images = document.querySelectorAll('img'); function addClickHandler(image) { image.addEventListener('click', clickHandler); } function removeClickHandler(image) { image.removeEventListener('click', clickHandler); } ``` 之後這兩個事件要寫在toggle裡面,當開啟的條件就執行新增事件;關閉就執行解除綁定 開啟也就是: ``` images.forEach((image) => { // 檢查圖像是否已加載 if (image.complete) { // 圖像已加載,直接添加點擊事件處理程序 addClickHandler(image); } else { // 圖像尚未加載,等待加載完成後再添加點擊事件處理程序 image.addEventListener('load', () => { addClickHandler(image); }); ``` 關閉則是: `images.forEach(removeClickHandler);` ## 心得 這次的小腳本功能非常簡單,寫起來邏輯也是很清晰透明,沒有什麼彎曲。 雖然簡單,但是寫起來功能非常實用! 這就是針對懶人專用的! 其實沒有人規定前端這種東西要寫得多大,多了不起/ᐠ。ꞈ。ᐟ\ 好像你很屌、很懂前端、框架,那個是一回事,能夠完成自己的需求也很美好。 很久沒更新了,這次的酷酷小腳本應該很爽⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾ 好好的來玩前端吧,未來還有更大的宇宙!

laravel 的單元測試功能 Mail::fake() 簡單原理分析

為了提升系統穩定性,最近替某電商客戶的專案寫單元測試 有一部份核心功能會用到第三方 API,這讓測試變很難寫,因為沒有本地的狀態變化可以比較 想到 laravel 有一個關於 mail 的測試功能,有類似情況 簡單來說就是在 phpunit 中這樣啟動之後 ``` Mail::fake(); ``` 就可以這樣來檢查是否有執行某 api ``` Mail::assertSent(OrderShipped::class); ``` 能否用同樣原理,處理我面對的情況呢? 決定來看一下原始碼! --- 首先是 fake 會直接換掉 Mailer 的實體 `framework/src/Illuminate/Support/Facades/Mail.php` ``` public static function fake() { $actualMailManager = static::isFake() ? static::getFacadeRoot()->manager : static::getFacadeRoot(); return tap(new MailFake($actualMailManager), function ($fake) { static::swap($fake); }); } ``` 可見是實作同樣 interface 的測試專用類別! `framework/src/Illuminate/Support/Testing/Fakes/MailFake.php` 然後寄信就改成,把變數存進陣列即可 ``` public function send($view, array $data = [], $callback = null) { if (! $view instanceof Mailable) { return; } $view->mailer($this->currentMailer); if ($view instanceof ShouldQueue) { return $this->queue($view, $data); } $this->currentMailer = null; $this->mailables[] = $view; } ``` 然後 assertSent 那些就檢查陣列內容,比對一下即可 ``` public function assertSent($mailable, $callback = null) { [$mailable, $callback] = $this->prepareMailableAndCallback($mailable, $callback); if (is_numeric($callback)) { return $this->assertSentTimes($mailable, $callback); } $message = "The expected [{$mailable}] mailable was not sent."; if (count($this->queuedMailables) > 0) { $message .= ' Did you mean to use assertQueued() instead?'; } PHPUnit::assertTrue( $this->sent($mailable, $callback)->count() > 0, $message ); } ``` inside of the `sent` function ``` return $this->mailablesOf($mailable)->filter(fn ($mailable) => $callback($mailable)); ``` --- 所以,目前這樣看起來,在需要測試跟「第三方 API」有關的功能時,可以使用同樣原理 使用 laravel 提供的 mock 功能,把會用到的第三方套件 mock 掉,套件的核心 function 就存個變數或陣列之類的 然後多寫個類似 `assertSent` 這樣的方法,應該就可以做到不錯的測試效果~! 簡單來說,就是設法做出「本地的狀態變化可以比較」就是了 我來往這方向寫寫看,有心得再補充分享~

挑戰串接CodeLove的API

成品連結:https://codingdark.github.io/program/2023/09/18/API-Test.html ##第一步 架部落格 最初看到站長的貼文,提供了本站的API 並且鼓勵大家自架部落格,來嘗試串API 看到文章的當下,覺得有點難度(沒用過github page,API也不熟) 不過看到站長提供的關鍵字`setup a personal blog with github pages` 最終還是決定先google看看 查了之後,發現近年的gitbub簡化了很多 都可以自動部署,根本就是一鍵架站 外加原始碼開源,很多東西都能自己改 所以光是部落格就玩了一天XD 因為本站為CodeLove 愛寫扣 我就創了一個CodingDark 闇寫扣 表示致敬本站 & 本人的中二風格 ##第二步 串API 因為不熟的關係,所以決定先隨便串 呼叫API之後,把data印在console.log 大致上看了一下資料格式 使用上其實就類似陣列,非常方便 沒有想像中的難 確認API可以正常呼叫後 陸續加入一些功能 比方說,用Table把文章列表排整齊、加上[Read more]按鈕 先讓json資料,轉換成網頁能呈現出來的[資訊] ##第三步 程式碼優化 到這邊為止,網頁的畫面已經差不多定型了 剩下的就是回頭檢視程式碼 考量到後續維護 盡可能把重複的程式碼,包裝成function 或是把一群散亂的變數,包裝成object 最後,為了方便擴充文章列表 將原本是寫死的HTML Dom 改成動態產生 目前的部落格頁面 點進去會撈出站長、Tony,以及我的文章列表 後續若想要列出其他使用者的文章 只需新增`setTable(userAccount)`即可 ##結尾 感謝站長提供有趣的API 讓大家可以有練習的機會 雖然目前我在工作上,沒接觸過API 但經過這次的練習,以後若是真的有需要用到 可以更快上手

寫出 Clean Code 的一些技巧&原則

## 介紹 編寫乾淨的程式碼是每個軟體開發人員的基本技能。乾淨的程式碼不僅使您的程式碼庫更易於維護和理解,而且還能促進團隊成員之間的協作。在這篇綜合文章中,我們將探討什麼是乾淨的程式碼、為什麼它很重要,並為您提供一組最佳實踐和原則來幫助您編寫乾淨且可維護的程式碼。 - 原文出處:https://dev.to/favourmark05/writing-clean-code-best-practices-and-principles-3amh --- ## 什麼是乾淨程式碼? 乾淨的程式碼是易於閱讀、易於理解且易於修改的程式碼。它是沒有不必要的複雜性、冗餘和混亂的程式碼。乾淨的程式碼遵循一組約定和最佳實踐,使其更加一致,使多個開發人員更容易無縫地處理同一個專案。 ## 為什麼乾淨的程式碼很重要? 1. **可讀性**:乾淨的程式碼易於閱讀,這意味著任何人 - 包括未來的你 - 都可以快速理解它。這減少了掌握程式碼功能所需的時間,從而加快了開發和除錯速度。 2. **可維護性**:程式碼的讀取次數多於編寫次數。當您編寫乾淨的程式碼時,隨著時間的推移,維護和擴展應用程式將變得更加容易。這在軟體開發生命週期中至關重要,因為專案經常發展和成長。 3. **協作**:簡潔的程式碼鼓勵協作。當您的程式碼乾淨且組織良好時,其他團隊成員就可以有效地處理它。這使得劃分任務和同時處理程式碼庫的不同部分變得更容易。 4. **減少錯誤**:乾淨的程式碼可以減少引入錯誤的可能性。難以理解的程式碼在修改或增強過程中更容易出錯。 5. **效率**:乾淨的程式碼就是高效率的程式碼。它通常執行速度更快並且使用更少的資源,因為它避免了不必要的操作和複雜性。 現在我們了解了為什麼乾淨的程式碼很重要,讓我們深入研究一些最佳實踐和原則來幫助您編寫乾淨的程式碼。 ## 編寫簡潔程式碼的最佳實踐和原則 1. **有意義的變數和函數名稱** 對變數、函數、類別和其他辨識碼使用描述性名稱。精心選擇的名稱可以傳達實體的目的,使程式碼更容易理解。避免使用單字母變數名或神秘的縮寫。 ``` # Bad variable name x = 5 # Good variable name total_score = 5 ``` 2. **保持函數和方法簡短** 函數和方法應該簡潔並專注於單一任務。單一職責原則(SRP)指出,一個函數應該要做一件事,並且把它做好。較短的函數更容易理解、測試和維護。如果函數變得太長或太複雜,請考慮將其分解為更小、更易於管理的函數。 ``` // Long and complex function function processUserData(user) { // Many lines of code... } // Refactored into smaller functions function validateUserInput(userInput) { // Validation logic... } function saveUserToDatabase(user) { // Database operation... } ``` 3. **評論和文件** 謹慎使用評論,當你使用評論時,要讓它們變得有意義。程式碼應該盡可能不言自明。文件(例如內嵌註解和自述文件)可協助其他開發人員了解程式碼的目的和用法。記錄複雜的演算法、重要的決策和公共 API。 ``` # Bad comment x = x + 1 # Increment x # Good comment # Calculate the total score by incrementing x total_score = x + 1 ``` 4. **一致的格式和縮排** 堅持一致的編碼風格和縮排。這使得程式碼庫看起來乾淨且有組織。大多數程式語言都有社群接受的編碼標準(例如,Python 的 PEP 8、JavaScript 的 eslint),您應該遵循。一致性也適用於命名約定、間距和程式碼結構。 ``` // Inconsistent formatting if(condition){ doSomething(); } else { doSomethingElse(); } // Consistent formatting if (condition) { doSomething(); } else { doSomethingElse(); } ``` 5. **DRY(不要重複)原則** 避免重複程式碼。重複的程式碼更難維護並增加不一致的風險。將通用功能提取到函數、方法或類別中以提高程式碼的可重複使用性。當您需要進行更改時,只需在一個地方進行即可。 假設您正在開發一個 JavaScript 應用程式來計算購物車中商品的總價。最初,您有兩個單獨的函數來計算每種商品類型的價格:一個用於計算一本書的價格,另一個用於計算筆記型電腦的價格。這是初始程式碼: ``` function calculateBookPrice(quantity, price) { return quantity * price; } function calculateLaptopPrice(quantity, price) { return quantity * price; } ``` 雖然這些函數有效,但它們違反了 DRY 原則,因為計算總價的邏輯對於不同的商品類型是重複的。如果您有更多的專案類型需要計算,您最終將重複此邏輯。為了遵循DRY原則,提高程式碼的可維護性,可以對程式碼進行如下重構: ``` function calculateItemPrice(quantity, price) { return quantity * price; } const bookQuantity = 3; const bookPrice = 25; const laptopQuantity = 2; const laptopPrice = 800; const bookTotalPrice = calculateItemPrice(bookQuantity, bookPrice); const laptopTotalPrice = calculateItemPrice(laptopQuantity, laptopPrice); ``` 在此重構的程式碼中,我們有一個calculateItemPrice函數,它根據作為參數提供的數量和價格計算任何商品類型的總價。這遵循了 DRY 原則,因為計算邏輯不再重複。 現在,您可以通過使用適當的數量和價格值呼叫calculateItemPrice來輕鬆計算書籍、筆記本電腦或任何其他商品類型的總價。這種方法提高了程式碼的可重用性、可讀性和可維護性,同時降低了重複程式碼引起的錯誤風險。 6. **使用有意義的空白** 使用空格和換行符正確設置程式碼格式。這增強了可讀性。使用空格來分隔程式碼的邏輯部分。格式良好的程式碼更容易瀏覽,減少讀者的認知負擔。 ``` // Poor use of whitespace const sum=function(a,b){return a+b;} // Improved use of whitespace const sum = function (a, b) { return a + b; } ``` 7. **錯誤處理** 優雅地處理錯誤。在程式碼中使用適當的 try-catch 塊或錯誤處理機制。這可以防止意外崩潰並為除錯提供有價值的訊息。不要抑制錯誤或在沒有正確響應的情況下簡單地記錄錯誤。 ``` // Inadequate error handling try { result = divide(x, y); } catch (error) { console.error("An error occurred"); } // Proper error handling try { result = divide(x, y); } catch (error) { if (error instanceof ZeroDivisionError) { console.error("Division by zero error:", error.message); } else if (error instanceof ValueError) { console.error("Invalid input:", error.message); } else { console.error("An unexpected error occurred:", error.message); } } ``` 8. **測試** 編寫單元測試來驗證程式碼的正確性。測試驅動開發 (TDD) 可以迫使您預先考慮邊緣情況和預期行為,從而幫助您編寫更清晰的程式碼。經過良好測試的程式碼更加可靠並且更容易重構。 ``` // Example using JavaScript and the Jest testing framework test('addition works correctly', () => { expect(add(2, 3)).toBe(5); expect(add(-1, 1)).toBe(0); expect(add(0, 0)).toBe(0); }); ``` 9. **重構** 定期重構你的程式碼。隨著需求的變化以及您對問題域的理解的加深,請相應地調整您的程式碼。隨著專案的發展,重構有助於保持乾淨的程式碼。必要時不要害怕重新存取和改進現有程式碼。 假設您有一個函數,可以計算購物車中具有固定折扣百分比的商品的總價: ``` function calculateTotalPrice(cartItems) { let totalPrice = 0; for (const item of cartItems) { totalPrice += item.price; } return totalPrice - (totalPrice * 0.1); // Apply a 10% discount } ``` 最初,此函數計算總價並應用 10% 的固定折扣。然而,隨著專案的發展,您意識到您需要支持可變折扣。為了重構程式碼使其更加靈活,可以引入折扣參數: ``` function calculateTotalPrice(cartItems, discountPercentage) { if (discountPercentage < 0 || discountPercentage > 100) { throw new Error("Discount percentage must be between 0 and 100."); } let totalPrice = 0; for (const item of cartItems) { totalPrice += item.price; } const discountAmount = (totalPrice * discountPercentage) / 100; return totalPrice - discountAmount; } ``` 在這段重構的程式碼中: * 我們在calculateTotalPrice函數中新增了discountPercentage參數,讓您在呼叫函數時指定折扣百分比。 * 我們對discountPercentage 參數進行驗證,以確保其落在有效範圍內(0 到100%)。如果不在範圍內,我們會拋出錯誤。 * 折扣計算現在基於提供的discountPercentage,使功能更加靈活,能夠適應不斷變化的需求。 通過這種方式重構程式碼,你提高了它的靈活性和可維護性。您可以輕鬆地調整該函數來處理不同的折扣場景,而無需重寫整個邏輯。這證明了隨著專案的發展和需求的變化定期進行程式碼重構的重要性。 10. **版本控制** 使用 Git 等版本控制系統來跟踪程式碼更改。這使您可以與團隊成員有效協作,在必要時恢復到以前的版本,並維護專案開發的清晰歷史記錄。 Git 提供了程式碼審查、分支和合併工具,促進協作和程式碼整潔。 ##結論 編寫乾淨的程式碼不僅僅是一套規則,更是一種心態和紀律。它是關於建立易於閱讀、維護和擴展的軟體。通過遵循這些最佳實踐和原則,您可以成為一名更熟練的開發人員,生成高質量的程式碼。投入時間仔細檢查其他工程師的程式碼庫,特別是在開源專案中,可能是一種啟發性的體驗。通過這種探索,您將獲得對不同編碼風格和策略的寶貴見解。這種接觸使您能夠提煉出編寫原始、可持續程式碼庫的精髓。請記住,乾淨的程式碼是一個持續的旅程,通過練習,它會成為第二天性,從而實現更高效、更愉快的軟體開發。

主流商用軟體的 10 個開源選擇方案

一篇國外的熱門文章,關於一些開源選擇方案,翻譯出來給大家參考。 - Medusa vs. Shopify - Postman vs. Hopscotch - Slack vs. Rocket Chat - Google Chrome vs. Brave - n8n vs. Zapier - Webflow/Framer vs. Webiny - Bit.ly vs. Dub.co - Calendly vs. Cal.com - Airtable vs. NocoDB 原文出處:https://dev.to/rigdev/10-open-source-alternatives-to-proprietary-software-34lb --- ##Medusa:Shopify 的替代方案 ![Medusa:Shopify 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n0lsrwimibby8vpfqyjc.png) 您可能聽說過 Shopify,它是遊戲中的大玩家。但現在有一個新的競爭者:美杜莎。讓我們來分析一下這兩者的優點、缺點以及本質。 ###Medusa 與 Shopify 相比的優點: **按你的方式做**:Medusa 是開源的,這意味著您可以根據自己的喜好對其進行調整。想要一個霓虹粉紅結帳按鈕嗎?大膽試試吧! **保留您的現金**:與 Shopify 不同的是,除非您使用他們的支付系統,否則 Shopify 會奪走您的部分銷售額,而 Medusa 不會動用您的口袋。 **選擇你的家**:透過 Medusa,你可以決定在哪裡開設你的商店。這就像在租公寓還是建造自己的房子之間做出選擇。 **權力歸於人民**:美杜莎受到社區的愛戴。這意味著定期更新、酷炫的新功能以及一群隨時準備提供幫助的人。 **沒有秘密**:開源意味著您可以看到幕後發生的一切。 ###Medusa 與 Shopify 相比的缺點: **開箱即用**:Shopify 擁有大量內建功能和龐大的應用程式商店。美杜莎在這方面仍在迎頭趕上。 **減少 DIY**:使用 Shopify,許多技術問題都會為您處理。美杜莎?您坐在駕駛座上,但這意味著您也必須應對道路上的顛簸。 **名言**:每個人都知道 Shopify。美杜莎仍然是學校裡的新生。 ###結論: 在 Medusa 和 Shopify 之間進行選擇可以歸結為您的特定需求和技術專長。如果您重視靈活性、客製化和成本控制,Medusa 是令人信服的選擇。然而,如果您正在尋找一個擁有良好記錄、廣泛內建功能和強大支援的平台,Shopify 仍然是一個強大的競爭者。 ##Hopscotch:郵差的替代方案 ![跳房子:郵差替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/omls8xf9jd2jocktn1mp.png) 您可能聽過 Postman,它是 API 測試領域的大人物。但有一個開源挑戰者踏入了這個圈子:Hopscotch。 ###Hopscotch 與 Postman 相比的優點: **像鳥一樣自由**:作為開源軟體,Hopscotch 不會花費您一毛錢。對於關注預算的小型團隊或個人開發人員來說,這可能是一個巨大的勝利。 **社群氛圍**:像 Hopscotch 這樣的開源工具依靠社群的投入而蓬勃發展。這意味著您有一群充滿熱情的人不斷改進它並加入很酷的新功能。 **透明度**:對於 Hopscotch,不存在任何幕後謎團。您可以看到每一行程式碼,確保您確切知道發生了什麼。 **輕量級**:Hopscotch 往往比 Postman 更輕量級,如果您正在尋找資源密集程度較低的東西,這可能是一個優勢。 **豐富的客製化**:由於是開源的,如果缺少您需要的功能,您可以自行加入或召集社群來提供協助。 ###Hopscotch 與 Postman 相比的缺點: **功能豐富**:Postman 已經廣泛存在並擁有大量內建功能。它就像是 API 測試的瑞士軍刀。 **流暢的使用者介面**:Postman 的使用者介面精美且直觀,讓新手可以輕鬆上手。 **協作功能**:透過其團隊協作工具,Postman 讓團隊可以輕鬆地協同工作、共享集合並保持所有內容同步。 **廣泛的文件**:Postman 參與遊戲已經有一段時間了,因此他們建立了一個龐大的教程、指南和社區帖子庫來幫助您。 **整合生態系統**:Postman 提供與各種其他工具的集成,使其更容易融入現有工作流程。 如果您熱衷於開源,喜歡修補,並且正在尋找一個輕量級工具,那麼 Hopscotch 可能是您最好的新朋友。但如果您想要一個功能豐富且擁有良好記錄的環境,並且不介意花一些錢購買高級功能,那麼 Postman 仍然是一個不錯的選擇。像往常一樣,關鍵是找到適合您需求的工具。 ##Rocket Chat:Slack 替代方案 ![Rocket Chat:Slack 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jwewh09g82kg1ez8egay.png) 當談到團隊溝通工具時,Slack 一直是許多人的首選。但等一下,擂台上有個開源挑戰者:Rocket.Chat。讓我們透過簡單地了解 Rocket.Chat 與 Slack 相比的三個優缺點來分解這兩者的比較。 ###為什麼 Rocket.Chat 可能會震撼您的世界: **調整和調整**:Rocket.Chat 是開源的,這意味著如果有您不喜歡的東西或您認為可以更好的東西,您(或您的技術團隊)可以參與並自訂它。您的 Rocket.Chat 可以像您團隊最喜歡的內部笑話一樣獨特。 **錢包友好**:使用 Rocket.Chat,您可以避免 Slack 等高級版本專有軟體帶來的一些討厭的費用。此外,由於是自託管,您可以更好地控制未來潛在的價格上漲。 **您的資料,您的規則**:在您自己的伺服器上託管 Rocket.Chat 意味著您可以完全控制您的資料。無需擔心第三方存取或資料儲存位置。 ###Slack 仍可能佔上風的地方: **即插即用**:Slack 以其用戶友好的介面和易於設定而聞名。對於那些不懂科技的人來說,Slack 的簡單方法可能是一件幸事。 **整合**:Slack 一直處於領先地位,擁有龐大的應用程式整合庫。無論是 Trello、Google Drive,還是您的團隊離不開的小眾工具,Slack 都可能提供了整合。 **酷兒童俱樂部**:Slack 的受歡迎意味著許多人已經熟悉它。如果新團隊成員之前已經使用過 Slack,那麼新團隊成員的入職或與合作夥伴的協作可能會更順利。 ###結論: Rocket.Chat 提供了一個無與倫比的客製化、成本節約和資料控制的世界。但如果您正在尋找無憂無慮的設置、大量的整合以及廣泛的熟悉度,Slack 仍然可以滿足您的需求。一如既往,最好的選擇取決於您的團隊最重視的是什麼! ##Brave:Google Chrome 的替代品 ![勇敢:Google Chrome 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cg5kruse2v60hvr61dwo.png) 就網頁瀏覽器而言,Google瀏覽器在相當長一段時間內一直是衛冕冠軍。但有一個新的競爭者正在引起轟動:Brave。 Brave 建構於與 Chrome 相同的 Chromium 引擎之上,承諾提供不同類型的瀏覽體驗。 ###Brave 與 Google Chrome 相比的優點: **隱私第一**:Brave 非常重視隱私。它可以立即阻止第三方廣告和追蹤器,這意味著您不必擺弄設定或加入擴充功能來阻止公司在網路上追蹤您。 **速度惡魔**:由於其廣告攔截功能,Brave 通常加載頁面的速度比 Chrome 更快。更少的廣告和追蹤器意味著更少的下載資料,讓您的瀏覽體驗更快捷。 **衝浪獲得報酬**:Brave 有一個獨特的功能,稱為 Brave 獎勵。選擇尊重隱私的廣告,您可以獲得 BAT(基本注意力代幣),您可以將其保留或作為小費提供給您最喜歡的網站。 Chrome 不提供類似的功能。 ###Brave 與 Google Chrome 相比的缺點: **豐富的擴充功能**:Chrome 的網路應用程式商店是擴充功能和應用程式的寶庫。雖然 Brave 是基於 Chromium 引擎建置的,因此能夠安裝所有 Chrome 擴充程序,但由於某些擴充功能非常注重隱私和廣告攔截,因此可能會出現相容性問題。 **Google 生態系統**:如果您已經投資於 Google 領域(例如 Google 雲端硬碟、Google 照片、Google Meet),那麼 Chrome 可以與這些服務無縫整合。 Brave 可以存取它們,但不太順利。 **穩定可靠**:Chrome 已經存在多年,並且在穩定性和性能方面擁有良好的記錄。 Brave 比較新,雖然很強大,但還沒有足夠的時間來解決所有的問題。 ###結論: 如果您重視隱私,並且喜歡更快、更有價值的瀏覽體驗,那麼 Brave 可能會改變您的遊戲規則。但如果您是 Chrome 擴充功能的重度用戶或深入 Google 生態系統,那麼 Chrome 可能仍然是您的最佳選擇。 ##n8n 與 Zapier:自動化競技場 ![n8n vs. Zapier:自動化競技場](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/au3eybw4auja3m6kjipu.png) 在工作流程自動化領域,Zapier 長期以來一直是家喻戶曉的名字,它幫助企業和個人連接他們最喜歡的應用程式並自動化任務。進入 n8n,這是一個開源替代方案,以其獨特的方法而引人注目。讓我們深入了解 n8n 如何與 Zapier 進行比較。 ###n8n 與 Zapier 相比的優點: **客製化之王**:n8n 是開源的,提供無與倫比的客製化功能。如果您需要特定的功能或集成,您可以自行建立或利用社群來取得協助。這種程度的彈性是 Zapier 等專有平台無法比擬的。 **成本效益**:n8n 可以自架,這意味著您可以節省大量成本,尤其是在執行大量工作流程時。使用 Zapier,隨著您的需求成長,訂閱成本也會隨之增加。 **資料隱私**:透過 n8n 的自架選項,您可以完全控制您的資料。它保留在您的伺服器上,確保您確切知道它在哪裡以及誰有權存取。這與 Zapier 等基於雲端的解決方案形成鮮明對比,後者的資料是在外部伺服器上處理的。 ###n8n 與 Zapier 相比的缺點: **使用者友好**:Zapier 以其直覺的介面而聞名,即使是非技術人員也可以輕鬆設定和管理工作流程。 n8n 以其更面向開發人員的方法,對某些人來說可能有更陡峭的學習曲線。 **海量整合庫**:Zapier 擁有超過 3,000 個應用程式整合。雖然 n8n 的清單正在快速增長,但它尚未達到與 Zapier 一樣廣泛的開箱即用整合數量。 **可靠性和支援**:憑藉其成熟的影響力,Zapier 提供強大的可靠性和專門的支援團隊。雖然 n8n 擁有一個充滿熱情的社區,但它可能無法提供與 Zapier 這樣的成熟平台相同程度的即時、專業支援。 ###結論: n8n 提供了一個客製化、節省成本和資料控制的世界,對於那些習慣更實際操作方法的人來說,這是很難擊敗的。然而,如果您正在尋找一個具有大量即用型整合、用戶友好介面和專門支援的平台,Zapier 仍然是一個強大的選擇。您的理想選擇將取決於您的特定需求和技術舒適度。 ##Webiny:Webflow 和 Framer 的替代方案 ![Webiny:Webflow 和 Framer 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ihuqbo2d9cqmpvorr98.png) 在網頁設計和開發領域,Webflow 和 Framer 等工具因提供直覺的介面和強大的設計功能而聞名。但鎮上出現了一個新的開源玩家:Webiny。 ###Webiny 與 Webflow 和 Framer 相比的優點: **開源彈性**:Webiny 的開源性質意味著您可以根據自己的喜好進行自訂。如果您需要某種功能或集成,您將不會受到專有約束的限制。這種程度的適應性是像 Webflow 和 Framer 這樣的專有平台無法完全匹敵的。 **成本考量**:從長遠來看,Webiny 更具成本效益,特別是對於較大的專案或企業。雖然 Webflow 和 Framer 需要付費,但 Webiny 的開源模型可以節省大量成本,特別是在考慮自架網站時。 **完全控制資料**:透過 Webiny,您可以選擇自行託管,從而完全控制資料及其安全性。這與 Webflow 和 Framer 等基於雲端的解決方案形成鮮明對比,在這些解決方案中,您的資料駐留在外部伺服器上。 ###Webiny 與 Webflow 和 Framer 相比的缺點: **直覺的設計介面**:Webflow 和 Framer 都以其用戶友好的設計介面而聞名。它們提供拖放功能和視覺設計工具,使設計人員即使沒有深厚的編碼知識,也可以輕鬆地將他們的願景變為現實。 Webiny 雖然功能強大,但對於純粹的設計師來說可能有更陡峭的學習曲線。 **豐富的範本和元件庫**:Webflow 和 Framer 附帶豐富的範本、元件和動畫庫。這可以顯著加快設計過程。 Webiny 較新,可能無法提供同樣廣泛的即用型設計元素。 **社群與支援**:Webflow 和 Framer 擁有大型、成熟的社群和專門的支援團隊。這意味著有大量的教程、論壇和資源可供使用。 Webiny 是新出現的,仍在發展其社區和支援基礎設施。 ###結論 Webiny 提供了一個引人注目的開源替代方案,具有客製化功能、潛在的成本節約和資料控制。然而,對於優先考慮直覺設計介面、大量設計元素和成熟社群支援的人來說,Webflow 和 Framer 的綜合優勢仍然難以超越。 ##Penpot:Figma 的替代品 ![Penpot:Figma 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6qbwjeb3qobr4ji0oxpp.png) 在設計界,Figma 因其協作功能和時尚的介面而受到青睞。但有一個開源競爭者走進了聚光燈下:Penpot。 ###Penpot 與 Figma 相比的優點: **開源優勢**:Penpot 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化,而 Figma 等專有平台可能無法提供。 **無成本障礙**:Penpot 是開源的,可以免費使用。雖然 Figma 提供免費套餐,但高級功能和更大規模的團隊協作需要付費訂閱。使用 Penpot,您可以存取所有功能,而無需擔心訂閱費用。 **用於資料控制的自託管**:Penpot 使您可以選擇在自己的伺服器上託管。這意味著您可以完全控制資料、資料的安全性以及資料的儲存位置,這是 Figma 的純雲端模型所不具備的功能。 ###Penpot 與 Figma 相比的缺點: **成熟的生態系統**:Figma 存在的時間更長,並且擁有更成熟的生態系統。這包括一個龐大的插件庫、整合庫和社群貢獻的資源,可以增強設計過程。 **即時協作**:Figma 的突出功能之一是無縫即時協作。多個設計師可以同時處理一個專案並進行即時更新。雖然 Penpot 提供協作功能,但它可能不如 Figma 的那麼精緻。 **性能和可靠性**:Figma 的性能,尤其是複雜的設計和原型,是強大且可靠的。作為一種較新的工具,Penpot 仍在完善其性能並消除任何問題。 ###結論 Penpot 為設計工具領域提供了全新的開源視角,其成本效益和資料控制對許多人來說都很有吸引力。然而,對於那些看重龐大生態系統、即時協作和經過驗證的性能的人來說,Figma 仍然是一個強大的選擇。 ##Dub.co:Bit.ly 的替代方案 ![Dub.co:Bit.ly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ye97eh00t801zuixzoe8.png) Bit.ly 已成為許多用戶的主要內容。然而,開源社群提出了另一種選擇:Dub.co。 ###Dub.co 與 Bit.ly 相比的優點: **開源彈性**:Dub.co 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化,而 Bit.ly 等專有平台可能無法提供。 **成本考慮**:Dub.co 是開源的,可以免費使用。雖然 Bit.ly 提供免費套餐,但其高級功能和分析功能價格昂貴。透過 Dub.co,您可以存取所有功能,而無需擔心訂閱費用。 **資料隱私和自架**:Dub.co 為您提供在自己的伺服器上託管的選項。這意味著您可以完全控制您的資料、資料的安全性以及資料的儲存位置,這是 Bit.ly 的純雲端模型所不具備的功能。 ###Dub.co 與 Bit.ly 相比的缺點: **已建立的聲譽**:Bit.ly 已經存在很長時間了,並在可靠性和性能方面建立了聲譽。這種長期存在意味著許多用戶信任並熟悉其服務。 **廣泛的集成選項**:Bit.ly 提供與其他平台和行銷工具的廣泛集成,使企業可以更輕鬆地將連結管理納入其現有工作流程。 **用戶友好的介面**:Bit.ly 以其直覺的介面而聞名,使用戶可以輕鬆建立、管理和分析其縮短的連結。雖然 Dub.co 提供了一個強大的平台,但新手可能會發現 Bit.ly 的介面更加簡單。 ###結論: Dub.co 為連結管理提供了全新的開源視角,提供客製化、成本效益和增強的資料控制。然而,對於那些重視具有大量整合和易於使用介面的久經考驗的平台的人來說,Bit.ly 仍然是一個不錯的選擇。您理想的工具將取決於您的特定需求以及您如何優先考慮功能。 ##Cal.com:日曆的替代方案 ![Cal.com:Calendly 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/utln9g2ijnenv4y9d8ub.png) 在安排會議和約會時,Calendly 一直是許多人的首選平台。但有一個新的開源替代方案引起了人們的注意:Cal.com。 ###Cal.com 與 Calendly 相比的優點: **開源彈性**:Cal.com 是開源的,這意味著您可以對其進行自訂以滿足您的特定需求。無論是加入獨特的功能還是與其他工具集成,您都可以自由地打造自己的功能。這是 Calendly 作為專有平台無法提供的。 **成本效益**:Cal.com 對個人免費,並且是開源的,您可以自行託管它以避免訂閱費用。另一方面,Calendly 有免費套餐,但僅限於一種活動類型,並且缺乏一些高級功能,除非您升級到付費計劃。 **資料隱私**:透過自行託管選項,Cal.com 讓您可以完全控制自己的資料。您確切地知道它的儲存位置以及誰可以存取它,而 Calendly 的基於雲端的模型則不然。 ###Cal.com 與 Calendly 相比的缺點: **使用者體驗**:Calendly 已經存在了一段時間,並且擁有精美、用戶友好的介面。即使對於那些不懂技術的人來說,設定和管理約會也很容易。 Cal.com 較新,可能有更陡峭的學習曲線。 **整合選項**:Calendly 提供與 Google 日曆、Office 365 和 Zoom 等流行平台的廣泛整合。雖然 Cal.com 正在努力擴展其整合選項,但尚未達到與 Calendly 相同的水平。 **社群與支援**:Calendly 擁有龐大的用戶群,並提供強大的客戶支持,包括豐富的教學和資源。 Cal.com 作為一個較新的開源平台,更依賴社群支持,但社群支持可能不那麼直接或廣泛。 ###結論: 如果您熱衷於嘗試新事物、喜歡優質的免費贈品並重視保持資料的私密性,請嘗試 Cal.com。但如果您想要一個久經考驗、易於使用且擁有可靠支援的工具,Calendly 仍然是一個不錯的選擇。 ##NocoDB:Airtable 替代方案 ![NocoDB:Airtable 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phokr8123e2qpxge9ix5.png) 您可能已經看過 Airtable,它具有豐富多彩的網格和簡單的拖放氛圍。但有一個新來者正在引起一些轟動:NocoDB。讓我們來分解一下這兩者是如何疊加的。 ###NocoDB 與 Airtable 相比的優點: **開源優點**:NocoDB 是開源的,這意味著您可以根據自己的喜好調整、扭曲和自訂它。另外,您還可以從不斷改進它的社區中受益。空中桌?這很酷,但它並沒有給你那種程度的自由。 **錢包友善**:使用 NocoDB,您可以透過自己託管來避免這些月費。 Airtable 有免費套餐,但如果您想要更多記錄、檢視或精美功能,則需要花費一些現金。 **您的資料,您的規則**:由於您可以自行託管 NocoDB,因此在資料方面您處於主導地位。您可以決定它的儲存位置以及誰可以查看它。使用 Airtable,您的資料將掛在他們的伺服器上。 ###NocoDB 與 Airtable 相比的缺點: **使用者友善的氛圍**:Airtable 超級直覺。它的介面很乾淨,設定基地感覺輕而易舉。 NocoDB 比較新,可能需要更多時間來適應。 **模板寶庫**:Airtable 有大量模板。無論您是計劃活動、追蹤庫存還是管理專案,都可能有一個模板。 NocoDB 仍在建立其集合。 **內建整合**:Airtable 與其他應用程式配合得很好,提供了一系列與流行應用程式的內建整合。雖然 NocoDB 正在擴展其整合遊戲,但尚未達到 Airtable 的水平。 如果您是開源愛好者,喜歡控制資料,並且希望節省一些錢,那麼 NocoDB 可能正合您的胃口。但是,如果您正在尋找超級用戶友好、具有豐富模板庫並且可以輕鬆與其他應用程式連接的工具,那麼 Airtable 仍然很強大。 ##大結論 在不斷發展的數位工具世界中,老牌巨頭和創新的新來者之間始終需要保持平衡。無論是設計平台、調度工具或資料庫系統,每個平台都有其獨特的優點和潛在的缺點。 Penpot、Cal.com、NocoDB 等開源替代方案帶來了無與倫比的客製化、成本節約和資料控制。另一方面,Figma、Calendly 和 Airtable 等老牌廠商提供用戶友好的介面、廣泛的整合選項以及隨著時間的推移和改進而帶來的可靠性。 ##誰說你必須選邊站隊? 當今技術生態系統的美妙之處在於您可以混合搭配。使用開源工具完成一項任務,使用專有工具完成另一項任務。這就像擁有一把瑞士軍刀和一個專門的工具包。您將獲得兩全其美的效果。 例如,您可能喜歡根據資料庫需求自訂 NocoDB,但更喜歡使用 Calendly 進行排程的無縫整合。或者也許 Penpot 的開源靈活性吸引了您的設計方,而 Slack 的可靠性則讓您的團隊溝通順暢。 關鍵是,你並沒有被歸類。這一切都是為了找到適合工作的工具,有時,這意味著將開源精神與專有軟體的精美體驗相結合。 因此,當您冒險進入科技領域時,請記住:這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克!

非同步 JS 訓練二:第6課 ── 認識 async/await 語法與收尾處理

## 課程目標 - 認識 async/await 語法與收尾處理 ## 課程內容 接著來學 async/await 的收尾處理吧! 說起來也神奇,只要加上 `finally` 區塊就可以了! ``` try { const data1 = await $.get(url, params); // do something with data to get params2 const data2 = await $.get(url2, params2); // do something with data to get params3 const data3 = await $.get(url3, params3); // do the final task with data } catch (err) { alert('Something went wrong.'); } finally { // hide the loading icon } ``` 因為 `try/catch/finally` 本來就是一般同步程式設計語言會用到的錯誤處理語法 所以這整段程式碼,看起來跟一般的同步程式設計,幾乎一模一樣! 就是這麼奇妙!應該不用我多解釋什麼了! --- 多補充一句,我個人開發比較複雜的前端應用時,最常用的語法就是這種! 我認為 `async/await` 加上 `try/catch/finally` 是最簡潔有力的! 錯誤訊息提示、忙碌狀態提示,通通都有了,很輕易就做出 UX 很棒的應用程式! ## 課後作業 請拿出第三課的作業,我們來改善這個頁面的 UX(使用者體驗),明確提示「忙碌中」這個狀態 --- - 請用 html 元素,在頁面中加入一段 `讀取中,請稍等...` 的訊息,這個元素預設不顯示 - 在開始呼叫 API 的地方,用 js 操作來讓那個 html 元素顯示 - 在結束呼叫 API 的地方,使用 `finally` 語法,用 js 操作來讓那個 html 元素隱藏 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練二:第5課 ── 認識 promise chain 鏈接與收尾處理

## 課程目標 - 認識 promise chain 鏈接與收尾處理 ## 課程內容 接著來學 promise chain 的收尾處理吧! 繼續拿 jquery 當範例,只要在上次的 promise chain 最後,加上 `.always()` 就可以了! ``` $.get(url, params).then((data) => { // do something with data to get params2 return $.get(url2, params2); }).then((data) => { // do something with data to get params3 return $.get(url3, params3); }).then((data) => { // do the final task with data }).catch((err) => { alert('Something went wrong.'); }).always(() => { // hide the loading icon }); ``` 很簡潔有力吧! ### ⚠️特別注意事項⚠️ 因為某些歷史因素,jquery 包裝的 promise 跟現在瀏覽器原生的 promise 有點不太一樣! 原生的 promise 是 `.finally()`,而不像 jquery 是 `.always()`! 為了教學方便,本課&作業都用 jquery 示範,實務上如果看到 `.finally()` 請不要意外! 都是類似東西,知道這樣就好! ## 課後作業 請拿出第二課的作業,我們來改善這個頁面的 UX(使用者體驗),明確提示「忙碌中」這個狀態 --- - 請用 html 元素,在頁面中加入一段 `讀取中,請稍等...` 的訊息,這個元素預設不顯示 - 在開始呼叫 API 的地方,用 js 操作來讓那個 html 元素顯示 - 在結束呼叫 API 的地方,使用 `always()`,用 js 操作來讓那個 html 元素隱藏 寫完之後,你應該會發現不但 callback hell 改善了、錯誤處理有了、連 UX 都改善了! 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練二:第4課 ── 認識 callback hell 與收尾處理

## 課程目標 - 認識 callback hell 與收尾處理 ## 課程內容 研究完 callback hell、promise chain、async/await 的錯誤處理 接著來用三課的時間,分別研究收尾處理吧! 讓我們先從 callback hell 的寫法開始! --- 什麼是收尾處理? 其實就是,有些事情,不論任務執行成功 or 失敗,都固定要執行 這種事情,可以在 success callback 跟 error callback 最後都寫,但這樣就重複寫了,很煩! 所以就有所謂的收尾處理,讓你寫一次就好了 如果繼續拿 jquery 做範例,看起來會像這樣: ``` $.ajax({ url: url, data: params, success: (res) => {}, error: (res) => {}, complete: () => {}, }); ``` 其實,就是再多一個 callback function 而已!很單純吧! 在連續多個 ajax call 的時候,錯誤處理機制,再加上收尾處理機制,想想看 callback hell 會有多嚴重! --- 看到這邊,你可能會想,到底什麼事情需要在收尾機制處理呀? 其實,以我個人經驗來說,需要放進收尾處理的東西,其實很少 最常見的就是處理畫面上的「載入中,請稍等...」的文字,或者是畫面上「用來代表忙碌中的一個旋轉的圖示」 不論任務執行結果,都需要把這些文字、圖示隱藏 老實說,很多人根本連「忙碌中」這個狀態也沒做,導致 UX 不太好 所以實務上,如果你發現專案中不太會寫收尾處理,那也算正常,你就知道有這功能可以用即可 ## 課後作業 在第一課的作業,你已經體驗到了 callback hell 與錯誤處理的悲劇 忍耐一下,這一課要再體驗一下當年工程師的痛苦:加上收尾處理吧! 請拿出第一課的作業,我們來改善這個頁面的 UX(使用者體驗),明確提示「忙碌中」這個狀態 --- - 請用 html 元素,在頁面中加入一段 `讀取中,請稍等...` 的訊息,這個元素預設不顯示 - 在開始呼叫 API 的地方,用 js 操作來讓那個 html 元素顯示 - 在結束呼叫 API 的地方,使用 `$.ajax()` 的 `complete` 參數,用 js 操作來讓那個 html 元素隱藏 寫完之後,你應該會發現,有點難寫,而且顯示/隱藏的時機,有點奇怪! 如果想要讓顯示/隱藏的時機,完全正確,那就會重複很多一樣的 code! 別懷疑,就是這麼難寫、這麼奇怪!這就是當年前端開發的為難之處! 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練二:第3課 ── 認識 async/await 語法與錯誤處理

## 課程目標 - 認識 async/await 語法與錯誤處理 ## 課程內容 在非同步訓練一的課程,我們初步體驗到 async/await 寫起來的感覺,效果不錯! 這次來試著加上錯誤處理! 說起來也神奇,只要使用 `try/catch` 語法包起來就可以了! ``` try { const data1 = await $.get(url, params); // do something with data to get params2 const data2 = await $.get(url2, params2); // do something with data to get params3 const data3 = await $.get(url3, params3); // do the final task with data } catch (err) { alert('Something went wrong.'); } ``` 因為 `try/catch` 本來就是一般同步程式設計語言會用到的錯誤處理語法 所以這整段程式碼,看起來跟一般的同步程式設計,幾乎一模一樣! --- 上次我們說過:每次只要看到 await,就要去想「現在是去剝開 promise 的 then 裡面,拿出最後回傳的內容!」 現在可以多補充一句:「如果 await 後面的非同步任務跑失敗,就會直接 throw exception(拋出例外)」 有點看不懂沒關係,就先跟著使用方式,照做即可! 工作上多用幾次之後,會逐漸抓到感覺! ## 課後作業 這一次的作業,我們要延續「非同步 JS 訓練一:第3課」的內容,並且加上錯誤處理 https://codelove.tw/@howtomakeaturn/post/bapzbx 請找出你上次寫的作業,把上次的三組 API,換成以下這三組 ``` https://codelove.tw/fake-api/get-current-user-unstable ``` ``` https://codelove.tw/fake-api/get-orders-unstable ``` ``` https://codelove.tw/fake-api/get-order-details-unstable ``` --- 幾點注意事項如下: - 繼續用 `$.get()` 來呼叫 API 即可 - 寫一個 `try/catch` 就好了,不要寫成多個 `try/catch` - 任何一個 API 失敗時,請 `alert('抱歉,系統出了點問題,請稍後再試一次。');` 寫完之後,你會發現,整段程式碼看起來很像「一般程式語言中,同步程式設計」的寫法! 連 `try/catch` 看起來都跟常見程式語言的錯誤處理,一模一樣! 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練二:第2課 ── 認識 promise chain 鏈接與錯誤處理

## 課程目標 - 認識 promise chain 鏈接與錯誤處理 ## 課程內容 在非同步訓練一的課程,我們初步體驗到 promise chain 寫起來的感覺,效果不錯! 這次來試著加上錯誤處理! 只要在上次的 promise chain 最後,加上 `.catch()` 就可以了! ``` $.get(url, params).then((data) => { // do something with data to get params2 return $.get(url2, params2); }).then((data) => { // do something with data to get params3 return $.get(url3, params3); }).then((data) => { // do the final task with data }).catch((err) => { alert('Something went wrong.'); }); ``` 上面這段程式碼,總共發了三次 ajax,不論是哪一次失敗,都會被最後的 `.catch()` 捕捉到喔! 很簡潔有力吧! --- 看到這邊,你可能會心想,可是上次 callback hell 的寫法,我可以針對三個 api 分別寫不同的 callback,顯示不同的錯誤訊息耶! 這次只能寫一個 callback,給一個籠統的系統錯誤,好像 UX 不夠好呀? 其實你說的沒錯!這樣寫的確會有這問題! 但我個人經驗是,系統跑 ajax 失敗,其實整體 UX 已經很不好了,用戶已經覺得這網站很難用了 明確顯示哪個步驟失敗,其實幫助不大。就一律在訊息中「道歉&懇請用戶再試一次&告知可以回報客服」就好了! (如果真的要顯示不同錯誤訊息,是有其他 promise 比較複雜的寫法,這一課先不談論) ## 課後作業 這一次的作業,我們要延續「非同步 JS 訓練一:第2課」的內容,並且加上錯誤處理 https://codelove.tw/@howtomakeaturn/post/8aAPD3 請找出你上次寫的作業,把上次的三組 API,換成以下這三組 ``` https://codelove.tw/fake-api/get-current-user-unstable ``` ``` https://codelove.tw/fake-api/get-orders-unstable ``` ``` https://codelove.tw/fake-api/get-order-details-unstable ``` --- 幾點注意事項如下: - 繼續用 `$.get()` 來呼叫 API 即可 - 寫一個 `.catch()` 就好了,不用特別寫三種錯誤訊息 - 任何一個 API 失敗時,請 `alert('抱歉,系統出了點問題,請稍後再試一次。');` 寫完之後,你應該會看到多個 `.then()` 串接在一起,不再出現多層深度的巢狀 callback 傳遞了! 而且錯誤處理的部份,也比之前改善很多,簡單又清楚! 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練二:第1課 ── 認識 callback hell 與錯誤處理

## 課程目標 - 認識 callback hell 與錯誤處理 ## 課程內容 在非同步訓練一的課程,我們初步體驗到 callback hell 寫起來的感覺 其實,當年的工程師,面對的真正痛苦,比上次體驗到的更嚴重! 非同步任務,常常需要處理「任務失敗」的情況 比方說「主機回應超時」、「資料庫連線失敗」、「主機斷線」等等情況 按照 javascript 的慣例,就是多寫一個 callback function 處理這種情況 比方說函式可以設計成這樣 ``` runAsyncTask(success, error) ``` 使用者只要分別傳進「成功後的處理」以及「失敗後的處理」即可 ``` runAsyncTask(() => { alert('執行成功!'); }, () => { alert('執行失敗,請等等重新嘗試!'); }); ``` 如果繼續拿 jquery 做範例,看起來會像這樣: ``` $.ajax({ url: url, data: params, success: (res) => {}, error: (res) => {}, }); ``` 註1:他不是設計成兩個參數,而是物件的兩個屬性,但意思一樣 註2:沒辦法繼續用上次的 `$.get()`,他沒有設計錯誤處理的 callback。所以改用 `$.ajax()` 光看這樣可能還好,畢竟寫 javascript 就是很常到處寫 callback 傳來傳去 可是,你能想像連續呼叫多個 ajax 時,再加上錯誤處理機制,callback hell 會有多嚴重嗎! 來跟著作業,體驗一下,試著用當年的方式開發看看吧! ## 課後作業 這一次的作業,我們要延續「非同步 JS 訓練一:第1課」的內容,並且加上錯誤處理 https://codelove.tw/@howtomakeaturn/post/lqOkWq 請找出你上次寫的作業,把上次的三組 API,換成以下這三組 ``` https://codelove.tw/fake-api/get-current-user-unstable ``` ``` https://codelove.tw/fake-api/get-orders-unstable ``` ``` https://codelove.tw/fake-api/get-order-details-unstable ``` 這三組 API 很不穩定,每組 API 都有 1/3 的機率會抓資料失敗! 實務上不可能有 API 爛成這樣,通常失敗率會在 1% 以下,這次是方便測試,我故意寫的 API --- 幾點注意事項如下: - 不要使用現代的非同步寫法,請使用 callback hell 的寫法 - 使用 `$.ajax()` 來呼叫 API - 使用 `$.ajax()` 的 `success` 參數來處理成功的情況 - 使用 `$.ajax()` 的 `error` 參數來處理失敗的情況 - 第一個 API 失敗時,請 `alert('讀取用戶失敗,請稍後再試一次。');` - 第二個 API 失敗時,請 `alert('讀取訂單列表失敗,請稍後再試一次。');` - 第三個 API 失敗時,請 `alert('讀取訂單細節失敗,請稍後再試一次。');` 寫完之後,你應該會看到有三層深度的巢狀 callback 傳遞! 而且比上次的情況還離譜!加上錯誤處理之後,整段 code 更加難以閱讀、維護! 這就是當年前端工程師,每天工作面臨的狀況!很悲慘吧! 做出以上功能,你就完成這次的課程目標了!

非同步 JS 訓練一:第1課 ── 認識 callback hell

## 課程目標 - 認識 callback hell ## 課程內容 在一般「同步程式設計語言」中,程式碼執行的順序,就是一行一行跑下來,很容易理解 但 JavaScript 是「非同步程式設計語言」,很多時候,執行順序不是一行一行跑下來 為了讓用戶能持續流暢操作瀏覽器介面,工程師需要在會用到「非同步」的地方使用特殊寫法 最原始、也最單純的做法是使用 callback function,也就是把要在非同步任務結束後才跑的任務,寫在 callback function 傳進去 以 jquery 最原始的 ajax 處理為例 ``` $.get(url, params, (data) => { // do something with data }) ``` 第三個參數,也就是箭頭函式的部份,就是所謂的 callback function --- 當年的前端工程師,在一開始覺得這樣寫沒問題,但是當網頁應用程式越來越複雜之後 發現在需要連續執行多個非同步任務時,會需要不斷傳 callback function 進去更深層 最後導致的結果,就是所謂的「callback hell」!這讓程式碼很難讀、很難維護! ``` $.get(url, params, (data) => { // do something with data to get params2 $.get(url2, params2, (data) => { // do something with data to get params3 $.get(url3, params3, (data) => { // do the final task with data }); }); }); ``` 這樣描述比較抽象,來跟著作業,試著用當年的方式開發看看吧! ## 課後作業 讓我們時光倒轉,回到 2000 年代,體驗一下當時的開發方式 請使用 https://jsfiddle.net/ 寫作業 請載入 jquery 套件,並且用 `jQuery.get()` 來處理 ajax ``` <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"></script> ``` --- 假設你身為前端工程師,正在開發電商網站 今天,產品經理跟你說,為了提升 UX(用戶體驗) 希望能在網頁上顯示「最近一次的訂單內容」,就像這樣: ``` 尊貴的客戶您好,您上次的消費內容是: 訂單編號:XXX 訂單內容:XXX 訂單金額:XXX 希望這次也能有機會服務您! ``` --- 目前後端工程師提供了三組 API 給你使用 使用當年的 jquery 寫法會像是下面這樣: ### 取得當前登入用戶的資料 為了簡化起見,你不用實作「登入、驗證」等等功能 就當作用戶已經登入了,請直接呼叫這個 API 即可 ``` $.get("https://codelove.tw/fake-api/get-current-user", {}, (res) => { console.log('the current user id is:' + res.data.user.id) }); ``` ### 取得指定用戶的全部訂單 ``` $.get("https://codelove.tw/fake-api/get-orders", { user_id: 1 }, (res) => { console.log('get ' + res.data.orders.length + ' orders'); }); ``` ### 取得指定訂單的內容細節 ``` $.get("https://codelove.tw/fake-api/get-order-details", { order_id: 1 }, (res) => { console.log('the order id is #' + res.data.order.id); console.log('the order content is ' + res.data.order.content); console.log('the order amount is $' + res.data.order.amount); }); ``` - 請依序呼叫這三個 API,來完成這次需要的功能 - 把第一個 API 拿到的 user id 放進第二個 API 呼叫 - 把第二個 API 拿到的最後一個 order id 放進第三個 API 呼叫 - 把第三個 API 拿到的資料,顯示在網頁上 請注意,不要使用現代的非同步寫法,請使用 callback hell 的寫法,也就是: - 在第一個 API 的 callback function 裡面呼叫第二個 API - 在第二個 API 的 callback function 裡面呼叫第三個 API - 在第三個 API 的 callback function 裡面完成最終需要的功能 寫完之後,你應該會看到有三層深度的巢狀 callback 傳遞! 這就有一點悲慘了,有點 callback hell 的感覺! 做出以上功能,你就完成這次的課程目標了!

useContext 常犯錯誤與如何在 TS 使用

https://youtu.be/I7dwJxGuGYQ ## TL;DR - 在使用 useContext 時,一定要將其包裝成 custom hook - [好讀版本](https://hackmd.io/@jason60810/rklVqNUh2) - [React 官方文件新增了 TypeScript 使用專文](https://react.dev/learn/typescript?fbclid=IwAR3Pgkr8xpS48Vwa0ADo3oagaAPKX1q05jHhtbXH8ltV8MKwa8FAvePoXPU) - [英文版本](https://jason60810.hashnode.dev/always-use-a-custom-hook-for-context-api-not-usecontext-react-context-api-typescript) ## 資料夾結構 ( 使用 next app route ) ![](https://hackmd.io/_uploads/Bke6AE8n2.png) ### theme-context.tsx 一定要加上 `use client`,因為 useState 只能在 client component 運作 , **特別注意,就算這裡加了`use client`,所有的子層還是 server component (預設)** ![](https://hackmd.io/_uploads/BkF5REL3n.png) ### layout.tsx 加上 provider 之後,下面所有的子層都可以拿到值,不用用 prop 一個一個傳下去 ![](https://hackmd.io/_uploads/rJWXaVLnh.png) ### page.tsx ![](https://hackmd.io/_uploads/rJ-_ANI32.png) ### logo.tsx 1. 因為 useContext 要在 client component 運作,所以要加上 `use client`。 2. 當使用 useContext 時,一定要引入 ThemeContext,用起來很麻煩 3. 因為 ThemeContext 預設是 null,所以當不是在 provider 裡使用 `useContext` 時 ( Logo component ),會發生錯誤,因此需要先確認有 context ![](https://hackmd.io/_uploads/B1hAgrI23.png) 舉例:不是在 provider 裡使用 `useContext` ![](https://hackmd.io/_uploads/SkbYZrI23.png) ### 創建 custom hook ![](https://hackmd.io/_uploads/HJBffSI2n.png) ### 使用 custom hook 現在引入 ThemeContext 和處理錯誤的問題,已經抽離到 custom hook 中 ![](https://hackmd.io/_uploads/ByjYzr8n3.png) ### 加上型別 1. React.ReactNode,可以接受 JavaScript primitives ,如果只想要是 jsx 可以使用 React.ReactElement ( [react 官方文件](https://react.dev/learn/typescript#typing-children) ) 2. `type Theme` 可以讓 `useState` 在 get 和 set 時,可以使用正確的型別,例如:當想要 `setTheme('blue')` 時,會報錯,因為 `type Theme` 只有 'dark' 和 'light' 3. 在給予 createContext 型別時,可以利用 ts 的 union 讓 createContext 知道可能有 null 這個型別 ( [react 官方文件](https://react.dev/learn/typescript#typing-usecontext) ) ![](https://hackmd.io/_uploads/B13EHHI3h.png)

CodeLove 前輩分享寫作計畫:VIP 審核限定

大家好,我是站長阿川 我留意到 LINE 群組的討論非常踴躍 很多迷惘、想轉職的新手,各種發問,都有業界工程師幫忙回答,非常熱心! 各位很多的回答「非常詳細」,完整到我覺得:只有群組內的新手看到,也太可惜! 應該讓網路上更多人都能看到,這樣更造福眾生、未來有人 google 搜尋也能夠找到! 繁體中文社群,需要知識不斷累積。如果一直在 FB 等等聊天室討論,然後被洗掉,有點可惜! 這也是我建立 CodeLove 網站的初衷!所以我設計了一個新計畫,跟大家分享一下! # CodeLove 前輩分享寫作計畫:VIP 審核限定 我鼓勵大家,在回答新手之餘,如果覺得 LINE 訊息文字篇幅不夠,或是 LINE 程式碼排版不易 請直接在 CodeLove 寫一篇完整文章,然後再貼到 LINE 群組內! 舉例來說,我自己就有這樣回答 LINE 群組新手的習慣: [轉職軟體工程師的方法很多,到底該如何選擇:實體補習班、線上補習班、不花錢自學?](https://codelove.tw/@howtomakeaturn/post/NxN2Kx) [回答網友提問:如果前端要銜接後端的話,是不是學 node.js 比較快?](https://codelove.tw/@howtomakeaturn/post/2anP0x) [回應網友提問:我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢?](https://codelove.tw/@howtomakeaturn/post/Zq4Ona) # 如何成為這個計畫的 VIP? 原則上只接受「業界工程師」加入,也就是有工作經驗者加入! 就算只有一年工作經驗,也是正在轉職的新手的前輩,所以也歡迎! 越資深的話越好,因為您有大量的知識&經驗可以分享!真的是大前輩! **請在 CodeLove 網站上,任意發表一篇技術文章 or 工作心得,完成之後,點擊下方 LINE 群組加入:** https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 經過我審核之後,您就加入這個 VIP 群組了! (例外情況:您是學生,但明顯有極大分享熱情&知識,也會允許加入) # 身為這個群組的 VIP,可以幹嘛? 首先,我希望您寶貴的文章,能被儘量多的讀者看到! 您只要負責寫作就好,我會幫您「製造精美封面圖片」以及「行銷宣傳您的文章」! 凡是 VIP 前輩發文,我都會在有超過三百人的群組「愛寫扣論壇:發問&交流&討論群」轉貼,並且「設定為公告置頂至少24小時」! 再來,VIP 群組內都是「樂於分享、經驗豐富、寫作能力出色」的業界人士,大家可以在小群組內交流,我認為互相交換情報,也很有價值! 最後,如果我覺得您的文章實在應該被「成千上萬的更多讀者看到」,我會直接到各大論壇,到處轉貼宣傳您的文章,類似下面這樣: - https://www.dcard.tw/f/softwareengineer/p/252600314 - https://www.dcard.tw/f/f2e/p/252598230 - https://forum.gamer.com.tw/C.php?bsn=60076&snA=7835159 - https://forum.gamer.com.tw/C.php?bsn=60292&snA=8421 我會確保您的文章被數千、數萬人閱讀!身為寫作者,通常文章四處發表,會到處被不同工程師嘴砲、開嗆,沒關係,這很正常,我會擋在砲火最前面!您不用被這些負面訊息轟炸,我只會回報有意義的正面留言給您! 如果有很棒的留言或 feedback,我會貼回 VIP 群組內通知您! # 我想加入,但我沒什麼寫作靈感,怎麼辦? 首先,如果您有想發表的技術文章,當然可以直接當成寫技術部落格,寫一篇發表! 再來,您可以在 LINE 群組,看看新手們都在問些什麼,然後就當作在回答他們,直接公開寫一篇完整回答! 最後,也可以是您近期的一些技術筆記、工作隨筆,稍微整理之後發表,這種筆記也常常對後人很有價值! # 結論 我真的覺得繁體中文世界,需要有一個優質的討論區、寫作園區,知識才能有效累積,這個國家的軟體產業才能進步、發達 另外,這個 CodeLove 論壇是有 [文章 API](https://codelove.tw/@howtomakeaturn/post/jqeDka) 功能的 您可以在這邊大量寫作,之後呼叫 API 串接到自己的部落格,markdown 格式與 html 格式的轉換我都已經幫您做好了 以上,各位熱心的工程師,誠摯歡迎您加入「CodeLove 前輩分享寫作計畫」!一起造福眾生吧! https://line.me/ti/g2/9V19e5igoaUts-hrn1Vr3nNHMcGLLa1hJiaFRg 有問題歡迎直接留言與我討論!

回應網友提問:我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢?

昨天在我們新手寫程式 LINE 群組,有幾個業界工程師&剛轉職的新手在討論: 我是新手前端,公司叫我學一點 php + laravel 串 API,該從哪邊學起呢? https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好,我決定單獨寫一篇文章討論這件事情 --- 我猜你面臨的情況,老闆不是真的叫你從無到有寫後端,應該是去硬改現成的後端專案 因為是公司馬上需要的,先求速成為主,背後細節就先別管了 就分幾個步驟來做吧 # Step 1 laravel 官網 `Installation` 章節讀一讀,然後看你用什麼作業系統,網路上 laravel 安裝教學找幾份試試看 先想辦法把環境跑起來,讓目前專案可以在電腦上跑 然後找一款有 GUI(圖形化介面)的資料庫管理軟體,在 UI 上點一點,準備好資料庫 # Step 2 `Routing` `Controllers` `Requests` `Responses` 這幾個章節讀一讀 至少稍微看懂,後端是哪些地方在接收參數、回應參數 # Step 3 把 `Eloquent ORM` 章節讀一讀,這個類別提供很多神奇的方法,很輕易就能做到 CRUD 至少稍微看懂,後端是哪些地方在跟資料庫互動,自己有辦法新增資料、更新資料、刪除資料這樣 --- 除此之外,上網找幾份 laravel 的簡易 CRUD 範例教學,不太懂背後原理沒關係,按照指示,做個部落格之類的 然後就去硬改公司現成的後端專案,頂著用,不然短期內也沒辦法真的學精 laravel,就先這樣吧!先能滿足公司需求就好! 其實,以上所說,真的是很混的學習方法:ORM 背後的觀念、資料庫的 SQL 觀念,幾乎都沒學到 長遠來說,如果是真的要學 php + laravel 後端,我都是建議先從「純 php + mysql」開始學起 也就是我鼓勵新手用純 php 寫一個部落格網站,寫純 SQL 去連接資料庫,先搞懂這種最純粹的寫法 然後再開始學 laravel 以及 ORM 等等好用套件工具 不然的話,我知道很多人直接從 laravel 開始寫起,半知半解,工作很久了,卻連哪些功能是 php 提供的,哪些是 laravel 提供的都分不出來 然後在需要換框架 比如 CodeIgniter 或者 Yii 的時候,很多觀念無法融會貫通,長遠來說,根本事半功倍 --- 話說回來,如果老闆不是叫你硬改現成的後端專案,而是叫你從無到有寫後端 那這工作內容實在不太合理,除非你一開始應徵的就是「全端工程師」的職缺&薪資 以上,簡單幾個方向分享,希望對你有點幫助!

[技術文章] 一篇文章馬上帶你學會JQuery!

## 前情提要 還在問說要不要學JQUERY?別問了,學就對了,沒人說學了一定要用好嗎。 以下讓我們先看一段純純的JS,就跟國中生的戀愛一樣, 牽牽小手,超純。 ## JS純 ``` // 純 JavaScript 選取元素清單 let list = document.querySelectorAll(".navigation li"); function activeLink(event) { // 使用 forEach 迴圈移除所有元素的 "hovered" 類別 list.forEach((item) => { item.classList.remove("hovered"); }); // 在滑鼠移過的元素上新增 "hovered" 類別 event.target.classList.add("hovered"); } // 使用 forEach 迴圈為每個元素加上滑鼠移過事件的監聽器 list.forEach((item) => { item.addEventListener("mouseover", activeLink); }); ``` ## 轉大人 接下來我們要轉大人了。 ### 選擇器 關於querySelectorAll這種querySelector很簡單,JQ都是用$這個字符來選取。 ## 修改class item.classList.remove("hovered"); event.target.classList.add("hovered"); 這兩個的話JQ有寫出兩隻API: removeClass addClass 所以很方便很好用 ## 事件監聽 addEventListener的話JQ則是用on來表達,這個看過幾次就能夠理解了唷! ## JQ的寫法寫出來 ``` // 使用 jQuery 選取元素清單 let list = $(".navigation li"); function activeLink() { // 移除所有元素的 "hovered" 類別 list.removeClass("hovered"); // 在滑鼠移過的元素上新增 "hovered" 類別 $(this).addClass("hovered"); } // 使用 jQuery 的 each 方法為每個元素加上滑鼠移過事件的監聽器 list.each(function () { $(this).on("mouseover", activeLink); }); ``` ## 心得 JQ到底有沒有被拋棄或是需不需要學習,其實都是假議題,一堆人嘴上用JQ,然後嘴砲JQ 我們身為學習者其實就是花個一小時 就能學起來的東西,沒必要故意閉著眼睛不去了解。 以上,一篇文章馬上帶你學會JQuery! 比較想要玩切版可以看這個: https://ithelp.ithome.com.tw/articles/10312922 [【前端動手玩創意】置頂按鈕,老梗經典|帶你的網頁搭電梯](https://ithelp.ithome.com.tw/articles/10312922)