這陣子在做內部專案要用的元件，像是radio、checkbox，其中在製作有縮合功能的checkbox時，卻碰到了一個狀況，那就是label裡面包著必須包著一個有縮合功能的icon，但點選這個icon時，卻不能選取到這個checkbox。其實要解決這個問題很簡單，但我當下一時腦袋打結了，還以為必須使用什麼神奇的黑魔法，其實只要回歸根本原理開始解決就好了。雖然這個情境的解法應該算是滿直覺的，但是我想應該也還是有一些人在初次遇到這個狀況時，會有一時想不透的點，所以也就特別記錄下來了。點擊input label區域不觸發input事件實作情境最終期待的結果如同以下這樣。但是如果單純在icon上v-bind click事件，卻會變成以下這個狀況。問題發生原因&解決方式為什麼會發生這個問題？這個狀況和HTML tag自己本身的預設行為有關(像是 a, input等這些tag都有預設的行為)，因為label和input已經結合在一起了，所以點擊到label範圍內，當然也就會觸發input的預設事件，這裡type是checkbox，當在點擊被包含在label裡面的icon時，check就會有被點選和取消點選的效果。文科少女寫程式 發表在 痞客邦 留言(0) 人氣(202)
雖然每天主要還是使用Vue，不過因為一些需求，而開始接觸到一些跟React有關的東西，也就開始跟同事討論一些React的寫法。這次就來從最最基本的部分開始從Vue與React的比較學習React！也就是基本到不行的state和props！State部分Vue不論是Vue2還是Vue3，在data(state)部分都有一個特點，就是當data(state)有變動時，畫面上也會顯示對應的變動，不需要另用使用set函式去變更data(state)。
Vue2：在Vue2裡，只要將state放在data(黃框的部分)裡面，就會有這樣自動響應的效果，只要呼叫addCount函式(紅框部分)，count數字就會變動，畫面上顯示的count也會是變動後的數字。
Vue3：在Vue3裡，需要另外用ref或是reactive包裝起來，才會有這樣自動響應的效果，在下面的情境，因為count有使用ref(黃框部分)，所以當count有變動，畫面就會同步顯示變動後的數字。
文科少女寫程式 發表在 痞客邦 留言(0) 人氣(132)
最近開始嘗試script setup的寫法，雖然少寫了很多東西，但在用的過程中，因為使用前沒先看仔細說明書，所以還是有碰到一些小小的雷，這時候就是該來好好學習＆寫筆記的時候啦！
因為會以實際應用的情境為主，所以基本上會專注在我自己在實務過程中，比較常會碰到的用法，那就直接進入正題。<script setup>是什麼？是一種在SFC(Single File Component)中使用的語法糖，在使用這個語法糖時，大多數時候跟使用<setup>沒有太大的差異，但還是有些地方需要注意。另外，這邊也簡單提一下用這個語法糖比較大的優點是什麼，主要是不再需要透過return，才能在template使用特定的變數或函式(也包含import進來的內容)，也因為如此，能讓程式碼看起來更簡潔。
單純用文字說明，可能感受不出差異，直接看範例吧！一般<script>
<script setup>
文科少女寫程式 發表在 痞客邦 留言(0) 人氣(1,269)
前陣子在做公司的專案時，遇到一個用 flex 寫的 layout，明明已經用 flex-basis 限制寬度，但還是因為 layout 裡面的內容物的文字和圖片而把某一個區塊撐開。那時一直想不透是為什麼，所以就開始找資料，才發現跟 flex 本身的特性有關。防止 flex item 因為特殊情況被撐開實作情境以下是模擬當初在實作的情境，主要是一個被分為三欄的 layout，每一欄都會被放入一個元件，其中中間的元件因為是放入類似文字編輯器的元件，所以這個元件內容並不是固定的，會動態的變動，也就有可能因為圖片過大，或出現無斷行文字而把中間這欄撐開。
=> container 裡面分別有三個 item，item2 的 flex-basis 設定成 300px，裡面放了一個含有 10 個 30px 的文字的 component。
<範例 HTML>
<範例 css>
<範例實際畫面>當有比較大的圖片出現時，會出現以下狀況
<HTML (放入圖片後)><實際畫面(放入圖片後)>
中間這欄會被撐開，不只有原先我們希望的 300px 寬。問題發生原因&解決方式為什麼會發生這個問題？這邊先來了解一下這個問題發生的原因！會出現這樣的狀況主要是因為設定flex之後，容器裡面的 item 的 min-width(flex-direction: row) 或 min-height(flex-direction: column) 的預設值為 auto，所以當內容物寬度或高度較大時，這一欄就會被撐開。到這裡，腦子動得比較快的人，可能還是會覺得哪裡怪怪的，這邊先暫時不延伸下去思考，先針對 flex item 被預設的特性下去做修改。
*被預設為 auto 的屬性是 min-width 還是 min-height 主要是看現在被設定的 flex 方向(主軸的方向)，也就是 item 的排列方向是 x 軸還是 y 軸。怎麼解決這個狀況？前面提到跟 min-width 或 min-height 預設是 auto 有關，那這裡我們就只需要把它設定為 0 就可以了。在這個範例中，因為是主軸為 x 軸，所以要設定為 0 的是 min-width。設定 min- 的目的是去讓 item 寬度不要隨著裡面的內容物撐大(ex: img)，就可以讓 item 寬度維持在我們希望的 300px 以內。這樣中間這一欄，就可以恢復成原本我們希望的 300px了。但在這個情境中，圖片會被蓋住，這時候可以依照實際的需求搭配 overflow 來呈現。
(當時我實務中的需求，scroll 的部分是設定在這一欄中的元件)除了我這次的解法外，依照實際的確切情境，也可以透過 overflow 來解決這個狀況。延伸思考重新再回到剛剛前面提到的這個問題產生的原因，應該會有不少人覺得哪裡怪怪的，尤其是這個問題的重要部分-寬度的地方。明明每一欄的 flex-basis 都設定好了，而且合計是 container 的寬度，怎麼中間這欄可以被撐開呢？那其他欄位不就會被擠壓到嗎？
沒錯！這個部分也和 flex 的特性有關，也就是 flex-shrink。當 display 設定為 flex 時，flex item的flex-shrink 預設值會是 1，意思就是當空間不足時，item 就會被擠壓。這也就是讓中間欄位被撐開後，沒有導致其他 item 被擠倒 containe r外的原因。
在這個情況下，如果將另外兩個 item 的 flex-shrink 設定為 0，就會發生以下的狀況，也就是 item 超出 container。 文科少女寫程式 發表在 痞客邦 留言(0) 人氣(280)
11月一整個月都沒有寫部落格，不是耍廢去了，而是去挑戰一個讓自己肝超級爆掉的活動，就是六角學院舉辦的【The F2E 前端 & UI 修練精神時光屋】。
會參加這個活動的原因主要是今年就快要結束了，眼看該產出作品的目標尚未達成，就藉由這個活動逼自己產出一些作品了！
其實一開始本來是想用React這三週的三個主題，但在白天需要上班的狀況下，想要一週產一個主題，對於React還沒有這麼熟練的我難度有點高，所以最後還是決定使用Vue3+TypeScript進行。
這三週我完成了哪些主題？第一週：台灣旅遊景點導覽這一週比自己預想還要快完成，因為有特別挑了一個比較好完成的設計稿，但其實這一週自己還算是在熱身階段，所以做的成品不算完整，也還有很多bug。另外，因為想要加快完成的速度，所以部分元件是使用element ui下去調整樣式來完成。
整體成品畫面大概是下面這張截圖的樣子，由於不太完整，就不貼出成品連結了。目前也預計用React重新寫一次這個主題！
文科少女寫程式 發表在 痞客邦 留言(0) 人氣(157)
又來補強自己的基本觀念了！！沒錯～小女不才，已經入行10個月，這個基本觀念還是沒有確實地建立起來。最近踩了一個大雷，不來好好學習不行了，所以就以這個主題來寫學習筆記了！
好啦！廢話不多說，直接進入正題啦！物件型別的特性－傳址(by reference)物件型別是傳址不是傳值，所以跟其他字串、數字不太一樣，在進行複製動作時，並沒有那麼單純。
物件型別因為是傳址，所以其實可以把物件型別用另一種方式去看，就是當宣告一個陣列變數或物件變數時，除了變數的內容，還隱藏著一個東西就是變數內容儲存的位址，也就是物件型別儲存的位址。這部分尤其在進行複製動作的時候，會有更明顯的感受，因為在進行複製時，由於傳址特性，雖然表面上把值複製出來賦值成另一個變數了，但實際上物件型別儲存的位址還是指向同一個，所以這個物件或陣列其實是一樣的東西，直接看一下小小的範例！
文科少女寫程式 發表在 痞客邦 留言(1) 人氣(170)
先來說說為什麼要寫這一篇好了！主要原因就是我知道有＋、＞、～這幾個CSS選擇器可以使用，但是每次要使用的時候，都會忘記他們到底誰是誰，所以就想說趁這次好好記下他們各自的身分了。雖然說真正在切版時，並沒有常常使用到這三個孩子，但偶爾還是會有需要派他們出場的時候。好啦！廢話不多說，直接來看看這些CSS選擇器到底誰是誰！加號、連接號、大於符號選擇器的用法文科少女寫程式 發表在 痞客邦 留言(0) 人氣(142)
今天來篇心情雜記，記錄一下邁入第九個月的我，心境上有什麼不一樣。
因為已經過了八個月，對於目前在公司身為前端工程師的業務已經比剛進公司時，來得熟悉很多。很多時候，要修一些bug，也不太需要花很多的時間去找原因，甚至是有新的需求時，也都能在短時間內就掌握到該如何進行的方向。另外，自己也和前輩一起完成了方便前端的我們查看API contract的網頁，所以這幾個月相較於前陣子，反而沒有出現太多的自卑感。
與此同時，我也開始有一些有別於以往的想法出現。
首先是最近的我開始認真思考公司內部現有專案的程式碼，有沒有什麼方式可以更好維護？尤其是最近有一些全新的專案，是用vue3進行，雖然近期比較常碰vue3，寫起來有稍微順手一點，但還是有一些部分不知道該怎麼寫比較好。另外，還有一個部分是對於目前公司使用TypeScript的方式有些疑問，主要原因是跟自己在網路上接收到的一些大神們分享的知識有點不太一樣，所以也想好好地去了解該怎麼寫TypeScript才是最好的用法。現在自己的狀況是雖然可以用TypeScript，但是某些用法上，也許並不是那麼地恰當。還有這陣子才發現原來目前code review的流程似乎不太完整，雖然說最主要原因是主管和前輩們都很忙，所以大家沒時間幫小菜鳥的我review也很正常，但對於需要有人給方向的菜鳥階段的我，就不是一種很好的狀況了。最後還有一個部分就是想要開始好好了解design pattern，主要原因是覺得自己往往好像只是為了完成功能而做，但做法可能也不是那麼地合適。
除此之外，隨著對公司業務及作業流程的了解程度的增加，也開始發現到這個產業似乎有點不太適合自己，也或者是說現在的我變得又更了解自己想要的是什麼了！因為剛踏入前端這個領域的職涯時，其實只是單純希望自己可以做前端工程師的工作，並沒有進一步地想到自己希望待在什麼樣的產業，不過最近對於這部分的方向好像漸漸變得明確了，也開始在想是不是應該轉換方向前進。就是因為這樣這陣子比較沒有在懷疑自己的能力，而是不斷地思考自己的職涯方向適不適合自己(雖然自己的能力還是有待加強)。
總之，邁向第九個月的這陣子，不再自怨自艾了，反而都在思考一些該怎麼樣讓自己變得更好，什麼樣的方向才更適合自己。
好了！今天的廢文差不多就寫到這裡囉！打完收工，寫些打家，打家掰掰！
文科少女寫程式 發表在 痞客邦 留言(4) 人氣(315)
打工仔人森 (3)