mirror-media-nuxt's Issues
將 dev 設為 default branch
因為 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。
調整 webpack 針對副檔名的處理
目前的 codebase 中因 nuxt 的 webpack 預設設定,可在 import Vue SFC 時允許不加副檔名。
如此可能會造成閱讀上的混淆,應調整 webpack 設定使行為變成強制加上 .vue
副檔名。
Response header 處理
未來改動:
適用 URL | Header 設定 | done |
---|---|---|
靜態資源 assets |
|
|
文章 /story, /story/amp, /app 等內容用頁面 html |
|
done |
首頁, section, category, topic 等列表用頁面 html |
|
done |
preview 頁面 html(給 cms 用) |
|
done |
任何 response 錯誤 | 待訂 | |
Front-End API 正確 response |
|
done |
Front-End API ERR 錯誤 response |
|
done |
任何 html 的 response |
|
X |
現行規則:
-
Front-end server API(以下簡稱 FE API) 取 JSON 檔案:
- Cache-Control: public, max-age=600
-
FE API 接第三方 Oath API:
- Cache-Control: public, max-age=300
-
其他 FE API:
- Access-Control-Allow-Origin: *
- Access-Control-Allow-Headers: X-Requested-With
- Cache-Control: public, max-age=600
-
API 過 Redis:
- Cache-Control: public, max-age=300
-
preview 頁面 html(給 cms 用):
- Cache-Control: no-cache, no-store, must-revalidate
- Pragma: no-cache
- Expires: 0
-
非 preview 頁面 html:
- Cache-Control: public, max-age=600
-
任何 html 的 response:
- Content-Type: text/html
- Server: express version 資訊、vue-server-renderer version 資訊
-
任何 response 錯誤:
- Cache-Control: no-cache
修改 metadata
#160
og 和 fb 的 meta 名應該是 property
而非 name
。
設定 Helmet
參照 正式作業最佳作法:安全
Prop Name Casing
Vue 官網建議在 templates
上使用 kebab-case,在聲明時使用 camelCase。原因是遵循每個語言自己的約定。
但 prop name 都用 camelCase,有以下好處:
- 腦袋不需多一層轉換。
- 可以直接複製貼上。
- 方便在不同檔案之間搜尋。
- 可以區分哪些是 HTML 本來就有的屬性,哪些是透過 Vue 才能加上去的。
結論
- prop name 都使用 camelCase。
行動
Sass breakpoint 共用變數
可以參考 Bootstrap 的寫法。
createWrapper factory function in tests
Server: Log 處理
預期目標:用 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 使用
gzip compression 處理
目前 mirror-media-nuxt 的 server 本身沒有處理 gzip 壓縮(沒看到有使用 compression
,mirror-voice 有使用)
在正式作業中,如果網站的資料流量極高,落實執行壓縮最好的作法是在反向 Proxy 層次實作它(請參閱使用反向 Proxy)。在該情況下,就不需使用壓縮中介軟體。如需在 Nginx 中啟用 gzip 壓縮的詳細資料,請參閱 Nginx 說明文件中的 ngx_http_gzip_module 模組。
建議由 Nginx 來做 gzip 壓縮,而目前用 HTTP Compression Test 和 Gift of Speed 來確認測試機狀況,結果是有啟用 gzip 壓縮的,所以就不會在 server 用 compression
做處理
lodash bundle size optimizations
We should add babel-plugin-lodash and lodash-webpack-plugin.
將一些 nuxt packages 從 modules 移動到 buildModules
https://nuxtjs.org/guide/modules/#build-only-modules
nuxt 建議一些 packages 擺放在 nuxt.config.js 中 buildModules 而非 modules,因為確實會對效能造成一些影響。
以我們目前的擺放方式,有以下兩個 packages 需要移動:
將 sass 改成 scss
要先麻煩 @kwhsiung 改 sass 資料夾裡的檔案,我們再改自己的 component 的 style(只改 component 的 style,如果用到 @include media-breakpoint-**
,會報錯)。
node升版到v16
(WIP)
我有一個提案,想跟大家討論:將週刊使用的node version,從14升到16。
原因有三:
- 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,能夠大幅提升開發上的體驗。 - V8引擎升級,提升效能:
16版使用了9.0版的V8 引擎,依據官方change log,這能帶來更好的效能。但這部分,就開發上很難肉眼看得出來,也許需要一些分析工具檢測是否屬實。 - 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 上。(待補)
在 vue 中使用 auto-loadmore/infinite-scroll 的解決方案
關於 auto-loadmore/infinite-scroll 不知道 @hsuehyungtan 跟 @yeefun 有沒有一些解決方案或意見可以提供?
我目前知道的一些方案有:
- https://github.com/ElemeFE/vue-infinite-scroll
- 目的單純:單純透過 custom directive 告知需不需要 loadmore。
- 沒在維護了。
- https://github.com/PeachScript/vue-infinite-loading
- 功能多元:除了核心的告知 loadmore 功能,還多了很多其他功能(如 loading icon)。
- 目前還有在維護。
- 自幹
我個人用過 1.,雖然久沒維護了,但目前也沒有遇到什麼問題。
由於我個人預想的目的是希望在使用上能夠簡單易用(使用者不用做一堆手動 import 或額外在 mounted hook 中設置 event handler),可能會比較朝先直接用 1. or 2.,有時間再深入研究如何走 3.。
需新增/重構的測試檔
測試檔名稱 | 測試單位 | 測試內容(概述) | 待改動原因 |
---|---|---|---|
UiYoutubeSubscribe.spec | UiYoutubeSubscribe | 測試元件是否有存在、有無既定屬性 | 原測試單位已被棄用,須針對新的元件做測試 |
API request 共用工具
想問你們使用上偏好哪一種方式 @kwhsiung @yeefun
問題 A : plugin Injected function 風格
-
$request('/getlist', { page: 1, maxResults: 10 })
完全彈性,但需要自己填上 endpoint -
$requestGetList({ page: 1, maxResults: 10 })
每個 endpoint 都有對應的 function
問題 B: params where
處理
-
$xxx({ page: 1, where: { categories: { $in: [ 'xxxx', 'xxxx ] }}})
完全依照原本後端階層,不做任何簡化 -
$xxx({ page: 1, where: { categories: [ 'xxxx', 'xxxx ]}})
將 where 下特定的 key 的階層做簡化 -
$xxx({ page: 1, categories: [ 'xxxx', 'xxxx ]})
攤平 where 這一層並做簡化,轉換後除了page
,maxResults
等原本第一層的之外,都會放在where
下
問題 C: 空陣列處理
目前如果 request 的資料是空的話,會回 status code 200 然後是空陣列,需要轉為 throw error 嗎?
vue-lazyload 套件問題
lazy-component 的@show
事件有時會被觸發兩次。若開啟observer
選項,讓套件使用 IntersectionObserver 判斷,那 lazy-component 的@show
事件會出問題 。放入 lazy-component 的 data 會失去響應性,需要用 key 去切換。data-srcset
沒有作用。
lazy-component 部分,已自製並更換成 vue-lazy-renderer 套件,見 c04be13。
search listing page 相關更動
- 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}§ion={sectionTitle}
,會牽涉到兩個地方的改動。/pages/search/_keyword.vue
/components/UISearchBarWrapper.vue
組 path 的形式 cc @yeefun
build failure
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)
把 default-og-img.png 放回 static 資料夾
等到官網全部變成新版後,記得把 default-og-img.png 放回 static 資料夾。
Refactoring 眾多 listing pages,使重複的程式碼減少
Reference: #63
目前的 listing pages 條列如下,當中有許多程式碼屬重複部分,可考慮重構:
- 已實作:
在 nuxt 中令多個 routes 可共用同一個 page component 而減少 page components 數量的方法參考:nuxt/nuxt#2693 (comment)
Dockerfile copy improperly built dependencies to image
`ENV NUXT_PORT 3000
COPY . $APP_DIR
RUN yarn build
RUN yarn cache clean`
It shoud't COPY . $APP_DIR
commit message type 規範
延續 #613 的討論,我們是不是要有一個既定的commit type?
依據 @nickhsine 的提議,有幾個commit type可以參考:
feat
: 新增功能。fix
: 修復既有功能的bug。perf
: 提升程式碼執行的效能。refactor
: 重構程式碼,不改變程式碼的功能,但提高程式碼的易讀性與復用性。style
: 修改 CSS。docs
: 修改程式碼的文件。test
: 加入或修改測試。chore
: 非以上幾種 commit type 的 commits。
而 @kjwen310 則覺得可以加入revert
,以及init 專案是使用build
還是chore
?
我覺得有幾個方向可以討論:
- 就conventional commit message 跟angular commit message的規定,
style
比較偏向coding style的改動,比如說camelCase、空格等,但是就mirror media的開發情境,或許把style定義成沒有新增功能的修改CSS,也許比較符合我們的需求。此外,nick提出style
本質上也是用於提升程式碼的易讀性與復用性,如果是偏向coding style的改動,也許可以使用refactor
。 - 需不需要保留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的定義需不需要調整。
如果大家有其他想法也歡迎提出討論~
用 viewport 取代 user agent 判斷裝置
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.