Angular 專案結構規劃

前陣子被同事問了 Angular Project 的專案結構建議要怎麼擺放比較有彈性!? 說實在的,從 angular v1(angularJS) ~ angular v9 (2019.12),就是看官方的 Style guide (大概就是長那樣),而且在開發版本提升的同時,為了因應新 feature 的加入也有可能異動。 查了別人開發架構加上自己的經驗大概是是這樣子,根據 (1)一次性? (2) 會持續大於 30/40個 component嗎?(3)是否需多人共同維護, 是否需要其他 project dependency ? (4) 是否需要 lazy-loading ? 中小型專案 | 簡易版 如果是一次性開發,且 lazy-loading module的需求很低的狀態下。 |-- app/ |-- core/ # Core components |-- [+] authentication/ |-- [+] services/ |-- [+] guards/ |-- [+] interceptors |-- [+] models/ |-- users # Users Components |-- [+] user-edit/ |-- [+] user-view/ |-- [+] user-list/ ├── user....

2019-12-25 · 3 分鐘 · Randy IN tech

Typescript 匯入路徑 (import paths)

在建置 angular 專案時,一開始就先設定好些方便開發的小技巧, 對之後的開發體驗可以省下不少工時。 自訂 Typescript 匯入路徑 (import paths) 編輯 tsconfig.json 檔案,在 compilerOptions 新增 paths 並在這裡設定 import path 的自動匯入路徑,這麼做可以讓路徑長度變短一點. { "compilerOptions": { "paths":{ "@core-models/*":["app/core/models/*"], "@core-services/*":["app/core/services/*"], "@core-guards/*":["app/core/guards/*"], "@public/*":["app/public/*"], "@pages/*":["app/pages/*"], "@app/*":["app/*"], }, 設定完之後,在撰寫程式碼時即可使用自訂命名來取代原有的絕對路徑. import { UserService } from '@core-services/user.service'; import { UserProfile } from '@core-models/users.model'; @Component({ selector: 'app-account', templateUrl: './account.component.html', styleUrls: ['./account.component.css'] }) export class AccountComponent implements OnInit, OnDestroy { } Routing 不可以把 default route 定義為 lazy-loading,在這裡可以用 ngx-quicklink 只要將 router prefetch strategy 設定好,就會預先自動讀取雨下載 view 中 routerLink 所指定的 lazy loading route,加快載入速度!大幅增加操作體驗!

2019-12-19 · 1 分鐘 · Randy IN tech

[changela] commit 的型態

Commit Types 照抄了Conventional-Commits 中可能有的 commit 情境,定義了 以下12種 (雖然有幾種 type 例如:improv/chore/perf/refactor,在單一commit中怎麼套用有所爭論),但全部列舉出來由使用者自行分類我覺得 會比較好。 /* * Conventional Commits * BREAKINGCHANGE = 3 // type = fix、feat 或 choreSemVer 的 MAJOR */ export enum CommitTypes { build = 'build', // Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) ci = 'ci', // Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs) chore = 'chore', // docs = 'docs', // Documentation only changes feat = 'feat', // New Features, SemVer's MINOR fix = 'fix', // Bug Fixes, SemVer's PATCH improv = 'improv', perf = 'perf', // A code change that improves performance refactor = 'refactor', // A code change that neither fixes a bug nor adds a feature revert = 'revert', style = 'style', // Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) test = 'test', // Adding missing tests or correcting existing tests } Commit Scopes Commit Scopes : 定義是一個 commit 修改了哪些範圍,其預設值是先定義幾個比較常見的,例如: 動畫、元件、文件、範例、編譯器、API 等, 之後可以讓使用者自由新增、刪除與排序,我覺得這是比較好的設計。...

[changela] 開發 changela 動機

changelog 講的是可描述一份產品/專案/事件/公司的演進,其重要性不言可喻,雖然有一些基礎標準/組織在討論類似的事, 例如 Conventional-Commits, 但是目前看到的形式不是整合在開發工具(Plugin),就是獨立一份changelog.md(文字檔),其開放性的風格又很難遵守, 也就是說這一份資訊不同公司的產出差異非常大,再加上通常只會附屬在某一個軟體工具的子功能(陽春)。 產品沿革,更因產品經理/開發人員/行銷人員的撰寫風格因人而異,因此想有一個簡單介面的 changelog 發佈工具可以幫助這樣 的流程。 初步目標 遵守 Semantic Versioning v2.0.0 遵守 Conventional-Commits 1.0.0 操作介面可拖拉 可替版本標籤化 (tag) 可排序 (sort) 可篩選 (filter) 可使用者訂閱 (subscription) 可轉成 PDF 下載 (saved as PDF) 開發環境 Angular NodeJS Cloud function 服務命名 在把一番想法跟 Ellington Su 討論後,把此服務命名為 changela 其他 寫 changela 還有一個原因,就是實際使用新版 angular,用一個明確題目來練習會比較實際