關於 auto-loadmore/infinite-scroll 不知道 @hsuehyungtan 跟 @yeefun 有沒有一些解決方案或意見可以提供？
我目前知道的一些方案有：

1. https://github.com/ElemeFE/vue-infinite-scroll
   • 目的單純：單純透過 custom directive 告知需不需要 loadmore。
   • 沒在維護了。
2. https://github.com/PeachScript/vue-infinite-loading
   • 功能多元：除了核心的告知 loadmore 功能，還多了很多其他功能（如 loading icon）。
   • 目前還有在維護。
3. 自幹

我個人用過 1.，雖然久沒維護了，但目前也沒有遇到什麼問題。
由於我個人預想的目的是希望在使用上能夠簡單易用（使用者不用做一堆手動 import 或額外在 mounted hook 中設置 event handler），可能會比較朝先直接用 1. or 2.，有時間再深入研究如何走 3.。

想問你們使用上偏好哪一種方式 @kwhsiung @yeefun

問題 A : plugin Injected function 風格

1. $request('/getlist', { page: 1, maxResults: 10 })
   完全彈性，但需要自己填上 endpoint

2. $requestGetList({ page: 1, maxResults: 10 })
   每個 endpoint 都有對應的 function

問題 B: params where 處理

1. $xxx({ page: 1, where: { categories: { $in: [ 'xxxx', 'xxxx ] }}})
   完全依照原本後端階層，不做任何簡化

2. $xxx({ page: 1, where: { categories: [ 'xxxx', 'xxxx ]}})
   將 where 下特定的 key 的階層做簡化

3. $xxx({ page: 1, categories: [ 'xxxx', 'xxxx ]})
   攤平 where 這一層並做簡化，轉換後除了 page, maxResults 等原本第一層的之外，都會放在 where 下

問題 C: 空陣列處理
目前如果 request 的資料是空的話，會回 status code 200 然後是空陣列，需要轉為 throw error 嗎？

We should add babel-plugin-lodash and lodash-webpack-plugin.

目前 mirror-media-nuxt 的 server 本身沒有處理 gzip 壓縮（沒看到有使用 compression，mirror-voice 有使用）

依照 Express 官方建議：

在正式作業中，如果網站的資料流量極高，落實執行壓縮最好的作法是在反向 Proxy 層次實作它（請參閱使用反向 Proxy）。在該情況下，就不需使用壓縮中介軟體。如需在 Nginx 中啟用 gzip 壓縮的詳細資料，請參閱 Nginx 說明文件中的 ngx_http_gzip_module 模組。

建議由 Nginx 來做 gzip 壓縮，而目前用 HTTP Compression Test 和 Gift of Speed 來確認測試機狀況，結果是有啟用 gzip 壓縮的，所以就不會在 server 用 compression 做處理

@kwhsiung @yeefun

#160
og 和 fb 的 meta 名應該是 property 而非 name。

(WIP)
我有一個提案，想跟大家討論：將週刊使用的node version，從14升到16。
原因有三：

1. 16版是m1 native，在m1 的電腦上有更好的開發體驗：
   對我而言，這是升到v16的最主要原因。
   依據官方的v16 change log，v16 有支援m1 native。雖然我個人沒有看得很懂，但爬了一下文，大概就是在m1上有更快的速度。
   而根據我自己實測（mac m1 2020 8G），在v14 中，下yarn dev後大約需要40秒才會compile完成，v16則只需要25秒左右；v14中yarn build需要約50秒才能build好，v16則只需要25-30秒。此外，在HMR（hot module replacement）模式下，v14大約仍須體感1-1.5秒才能complied 完畢，v16則幾乎不用時間。簡單來說，我認為升級到v16，能夠大幅提升開發上的體驗。
2. V8引擎升級，提升效能：
   16版使用了9.0版的V8 引擎，依據官方change log，這能帶來更好的效能。但這部分，就開發上很難肉眼看得出來，也許需要一些分析工具檢測是否屬實。
3. 14版目前已經進入maintain mode，而且將於2023.4進入為End-of-Life：
   依據node官方的Release plan，目前LTS（Long Time Support）的版本分別有14跟16，但是14目前已經進入maintain mode，而且明年將進入EOL(End-of-Life)。這意味著明年四月後，node官方將不再處理bug與security issue。我認為，除非有套件是指定使用低版本的node，不然使用沒有團隊維護的node，是件危險且沒必要的事。

綜合上述三點，我認為升到16沒有壞處，只有好處，而且也有升級的必要性。

而我目前把node升版後所衍生的bug與相關的解法，會放在 #642 上。（待補）

參照 正式作業最佳作法：安全

`ENV NUXT_PORT 3000

COPY . $APP_DIR
RUN yarn build

RUN yarn cache clean`

It shoud't COPY . $APP_DIR

1. lazy-component 的 @show 事件有時會被觸發兩次。
2. 若開啟 observer 選項，讓套件使用 IntersectionObserver 判斷，那 lazy-component 的 @show 事件會出問題 。
3. 放入 lazy-component 的 data 會失去響應性，需要用 key 去切換。
4. data-srcset 沒有作用。

lazy-component 部分，已自製並更換成 vue-lazy-renderer 套件，見 c04be13。

預期目標：用 winston 取代 console 並且能在 Cloud Logging 上出現在對應的 severity

方案 1. 用 winston 的 createLogger 搭配 .error(...), .warn(...), .info(...)
=> 能 Cloud Logging 上分類到正確的 container 和 cluster，但是 severity 無法正確對應，都是 info

方案 2. winston 搭配 @google-cloud/logging-winston [ref]
=> Cloud Logging 上的 severity 可以正確對應，但是預設 log 存放位置在 globe > winston_log，即使可以指定 logName 跟 resource，來分類到正確的 container 和 cluster，也缺少 resource.labels 下的完整資訊

new LoggingWinston({
  projectId: 'xxxxx',
  keyFilename: 'xxxxx',
  logName: 'projects/xxxxx/logs/mirror-media-nuxt',
  resource: {
    labels: {
      cluster_name: 'xxxxx',
      container_name: 'xxxxx',
    },
    type: 'xxxxx',
  },
})

目前先維持原本的 console 使用

gyp verb find Python Python is not set from command line or npm configuration
gyp verb find Python Python is not set from environment variable PYTHON
gyp verb find Python checking if "python3" can be used
gyp verb find Python - executing "python3" to get executable path
gyp verb find Python - "python3" is not in PATH or produced an error
gyp verb find Python checking if "python" can be used
gyp verb find Python - executing "python" to get executable path
gyp verb find Python - "python" is not in PATH or produced an error
gyp verb find Python checking if "python2" can be used
gyp verb find Python - executing "python2" to get executable path
gyp verb find Python - "python2" is not in PATH or produced an error
gyp ERR! find Python
gyp ERR! find Python Python is not set from command line or npm configuration
gyp ERR! find Python Python is not set from environment variable PYTHON
gyp ERR! find Python checking if "python3" can be used
gyp ERR! find Python - "python3" is not in PATH or produced an error
gyp ERR! find Python checking if "python" can be used
gyp ERR! find Python - "python" is not in PATH or produced an error
gyp ERR! find Python checking if "python2" can be used
gyp ERR! find Python - "python2" is not in PATH or produced an error
gyp ERR! find Python
gyp ERR! find Python **********************************************************
gyp ERR! find Python You need to install the latest version of Python.
gyp ERR! find Python Node-gyp should be able to find and use Python. If not,
gyp ERR! find Python you can try one of the following options:
gyp ERR! find Python - Use the switch --python="/path/to/pythonexecutable"
gyp ERR! find Python (accepted by both node-gyp and npm)
gyp ERR! find Python - Set the environment variable PYTHON
gyp ERR! find Python - Set the npm configuration variable python:
gyp ERR! find Python npm config set python "/path/to/pythonexecutable"
gyp ERR! find Python For more information consult the documentation at:
gyp ERR! find Python https://github.com/nodejs/node-gyp#installation
gyp ERR! find Python **********************************************************
gyp ERR! find Python
gyp ERR! configure error
gyp ERR! stack Error: Could not find any Python installation to use
gyp ERR! stack at PythonFinder.fail (/app/node_modules/node-gyp/lib/find-python.js:302:47)
gyp ERR! stack at PythonFinder.runChecks (/app/node_modules/node-gyp/lib/find-python.js:136:21)
gyp ERR! stack at PythonFinder. (/app/node_modules/node-gyp/lib/find-python.js:179:16)
gyp ERR! stack at PythonFinder.execFileCallback (/app/node_modules/node-gyp/lib/find-python.js:266:16)
gyp ERR! stack at exithandler (child_process.js:310:5)
gyp ERR! stack at ChildProcess.errorhandler (child_process.js:322:5)
gyp ERR! stack at ChildProcess.emit (events.js:310:20)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
gyp ERR! stack at onErrorNT (internal/child_process.js:469:16)
gyp ERR! stack at processTicksAndRejections (internal/process/task_queues.js:84:21)

這部份因目前已有多處測試需要使用的需求，待抽出成一個可以共用的 module。

Originally posted by @kwhsiung in #29

Vue 官網建議在 templates 上使用 kebab-case，在聲明時使用 camelCase。原因是遵循每個語言自己的約定。

但 prop name 都用 camelCase，有以下好處：

• 腦袋不需多一層轉換。
• 可以直接複製貼上。
• 方便在不同檔案之間搜尋。
• 可以區分哪些是 HTML 本來就有的屬性，哪些是透過 Vue 才能加上去的。

結論

• prop name 都使用 camelCase。

行動

• 更改 eslint-plugin-vue 的設定。

因為 PR #16 中的 message 已經含有 resolve issue 的關鍵字，但 merge 之後發現沒有 close issue #15

據 Closing Issues via Pull Requests 提到：

And the referenced issue will automatically be closed when the PR is merged
into the default branch.

而以我們現在的 workflow 來說 PR 大多發在 dev branch，若想透過 PR 來自動 close issue 我們需要在 GitHub 上將 dev 設為 default branch。

要先麻煩 @kwhsiung 改 sass 資料夾裡的檔案，我們再改自己的 component 的 style（只改 component 的 style，如果用到 @include media-breakpoint-**，會報錯）。

延續 #613 的討論，我們是不是要有一個既定的commit type？

依據 @nickhsine 的提議，有幾個commit type可以參考：

• feat: 新增功能。
• fix: 修復既有功能的bug。
• perf: 提升程式碼執行的效能。
• refactor： 重構程式碼，不改變程式碼的功能，但提高程式碼的易讀性與復用性。
• style: 修改 CSS。
• docs: 修改程式碼的文件。
• test: 加入或修改測試。
• chore: 非以上幾種 commit type 的 commits。
  而 @kjwen310 則覺得可以加入 revert，以及init 專案是使用 build 還是 chore ？

我覺得有幾個方向可以討論：

1. 就conventional commit message 跟angular commit message的規定， style比較偏向coding style的改動，比如說camelCase、空格等，但是就mirror media的開發情境，或許把style定義成沒有新增功能的修改CSS，也許比較符合我們的需求。此外，nick提出 style 本質上也是用於提升程式碼的易讀性與復用性，如果是偏向coding style的改動，也許可以使用refactor。
2. 需不需要保留angular commit message的build跟ci?
   就angular的說明，build跟 ci是指

build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci: Changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)

其實定義並沒有很清楚，而且就我們的開發情境，很難區分build跟ci。也許比較合適的情境，是都使用chore並在commit message進一步說明改動的檔案/目的。

我覺得可以就這兩個方向討論，以及各個commit type的定義需不需要調整。
如果大家有其他想法也歡迎提出討論～

Reference: #63

目前的 listing pages 條列如下，當中有許多程式碼屬重複部分，可考慮重構：

• 已實作：
  • /pages/author/_id.vue
  • /pages/category/_name.vue
  • /pages/search/_keyword.vue
  • /pages/section/_name.vue
  • /pages/section/topic.vue
  • /pages/tag/_id.vue
  • /pages/topic/_id.vue

在 nuxt 中令多個 routes 可共用同一個 page component 而減少 page components 數量的方法參考：nuxt/nuxt#2693 (comment)

可以參考 Bootstrap 的寫法。

https://nuxtjs.org/guide/modules/#build-only-modules
nuxt 建議一些 packages 擺放在 nuxt.config.js 中 buildModules 而非 modules，因為確實會對效能造成一些影響。
以我們目前的擺放方式，有以下兩個 packages 需要移動：

1. @nuxtjs/google-analytics
2. @nuxtjs/style-resources

未來改動：

現行規則：

• Front-end server API(以下簡稱 FE API) 取 JSON 檔案：

  1. Cache-Control: public, max-age=600

• FE API 接第三方 Oath API：

  1. Cache-Control: public, max-age=300

• 其他 FE API：

  1. Access-Control-Allow-Origin: *
  2. Access-Control-Allow-Headers: X-Requested-With
  3. Cache-Control: public, max-age=600

• API 過 Redis：

  1. Cache-Control: public, max-age=300

• preview 頁面 html（給 cms 用）：

  1. Cache-Control: no-cache, no-store, must-revalidate
  2. Pragma: no-cache
  3. Expires: 0

• 非 preview 頁面 html：

  1. Cache-Control: public, max-age=600

• 任何 html 的 response：

  1. Content-Type: text/html
  2. Server: express version 資訊、vue-server-renderer version 資訊

• 任何 response 錯誤：

  1. Cache-Control: no-cache

@kwhsiung @yeefun 看有沒有什麼想法

等到官網全部變成新版後，記得把 default-og-img.png 放回 static 資料夾。

• The fetch hook is not called on query string changes by default. To watch for query changes you can add a watcher on $route.query and call $fetch
• （待確認）將 search listing page 的 URL pattern 由 /search/:keyword?section={sectionId} 更改為 /search?keywords={keyowords}&section={sectionTitle}，會牽涉到兩個地方的改動。
  • /pages/search/_keyword.vue
  • /components/UISearchBarWrapper.vue 組 path 的形式 cc @yeefun

目前的 codebase 中因 nuxt 的 webpack 預設設定，可在 import Vue SFC 時允許不加副檔名。
如此可能會造成閱讀上的混淆，應調整 webpack 設定使行為變成強制加上 .vue 副檔名。