ຮູບແບບອອກແບບສະຖາປັດຕະຍະກຳສຳລັບຫຼາຍ layout ແລະຫຼາຍ theme

ຈະອອກແບບ frontend ແນວໃດໃຫ້ຮອງຮັບ 100+ themes ແລະຫຼາຍ layouts ໂດຍບໍ່ໃຫ້ logic ສະເພາະຂອງລູກຄ້າໄຫຼເຂົ້າໄປໃນຄອມໂພເນັນຮ່ວມ? ບົດຄວາມນີ້ຈະອະທິບາຍການແບ່ງຊັ້ນ core / view / theme leaf, ການຕັ້ງຄ່າແບບກຳນົດປະເພດ, ການທົດສອບຄວາມຄົບຖ້ວນຂອງກຸ່ມ theme ແລະການໂຫຼດ theme CSS ຕາມຄວາມຕ້ອງການ ພ້ອມກັບຂໍ້ແລກປ່ຽນຂອງແຕ່ລະຊັ້ນ.

2026/09/26 · ອັບເດດເມື່ອ 2026/10/04 · ອ່ານ 3 ນາທີ

ໂຄງສ້າງທີ່ແບ່ງປັນຂ້າງເທິງເຊື່ອມຕໍ່ຮູບແບບແລະສາມຮູບແບບຫົວຂໍ້, ສະແດງໃຫ້ເຫັນການວາງຊັ້ນຂອງສະຖາປັດຕະຍະກໍາທາງຫນ້າ.

ຂ້ອຍເຄີຍຮັບຜິດຊອບປັບໂຄງສ້າງແພລດຟອມ frontend ຂະໜາດໃຫຍ່ທີ່ສ້າງດ້ວຍ Nx / Angular. ມັນຕ້ອງຮອງຮັບ 100+ themes ແລະຫຼາຍ layouts, ແຕ່ມັກມີສະມາຊິກຄົນອື່ນໆທີ່ເຮັດວຽກຍ່ອຍໃນຫົວຂໍ້ຫຼາຍ layout ແລະຫຼາຍ theme ຕາມວິທີພັດທະນາທີ່ຕົນເຄີຍຊິນ. ເມື່ອສະສົມໄປດົນໆ ມັນກໍກາຍເປັນໜີ້ທາງເຕັກນິກ: ຂໍ້ກຳນົດດຽວກັນມີ logic ການປະຕິບັດຫຼາຍແບບຢູ່ພ້ອມກັນ.

ບົດຄວາມນີ້ຈະອະທິບາຍແນວຄິດອອກແບບຫຼັກໃນຕອນນັ້ນໃຫ້ຊັດເຈນ: ແບ່ງຊັ້ນແນວໃດ, ຮັກສາໃຫ້ themes ຫຼາຍກວ່າ 100 ມີອົງປະກອບຄົບຖ້ວນແນວໃດ, ແລະເຮັດແນວໃດໃຫ້ browser ດາວໂຫຼດສະເພາະ CSS ທີ່ໃຊ້. ບໍ່ສາມາດເຜີຍແຜ່ source code production ຕົ້ນສະບັບໄດ້, ຂ້ອຍຈຶ່ງໃຊ້ code ທີ່ຂ້ອຍຂຽນເອງ ແລະ themes ສົມມຸດສາມອັນມາສ້າງໃໝ່ໄວ້ໃນ ກໍລະນີສຶກສາ frontend engineering, ພ້ອມທັງມີ Demo ອອນລາຍ ທີ່ລອງໃຊ້ໄດ້ໂດຍກົງ. Code ໃນບົດຄວາມນີ້ມາຈາກລຸ້ນສາທາລະນະນັ້ນ.

ຂໍສະຫຼຸບກ່ອນ: ແຍກວ່າສິ່ງຕ່າງໆ “ໜ້າຕາແນວໃດ” ອອກຈາກ “ເຮັດຫຍັງ”, ແລ້ວໃຫ້ compiler ແລະ tests ຊ່ວຍຮັກສາໃຫ້ themes ຫຼາຍກວ່າ 100 ມີຄວາມສອດຄ່ອງກັນ.

ບັນຫາບໍ່ແມ່ນການປ່ຽນສີ

ຈຸດເລີ່ມຕົ້ນທີ່ພົບເລື້ອຍທີ່ສຸດໃນການຮອງຮັບຫຼາຍ theme ຄືການເພີ່ມເງື່ອນໄຂໃນຄອມໂພເນັນທີ່ໃຊ້ຮ່ວມກັນ. ຕົວຢ່າງ: theme A ຕ້ອງການປຸ່ມເພີ່ມອີກໜຶ່ງປຸ່ມ ສ່ວນ theme B ຕ້ອງປ່ຽນໄປຍັງໜ້າອື່ນໃນຊ່ວງກິດຈະກຳ:

if (theme === 'a') {
  showExtraButton = true;
} else if (theme === 'b' && isCampaign) {
  redirectTo = '/campaign';
}

ເມື່ອມີພຽງສາມ themes, ຂຽນແບບນີ້ໄດ້ໄວດີ. ແຕ່ເມື່ອມີໜຶ່ງຮ້ອຍ themes, ຄອມໂພເນັນຮ່ວມທຸກອັນກໍຕ້ອງແບກສາຂາເງື່ອນໄຂເປັນພວງທີ່ “ໃຊ້ໄດ້ສະເພາະກັບບາງ theme ເທົ່ານັ້ນ”. ຜົນທີ່ຕາມມາຄື:

ການປັບຕາມຂໍ້ກຳນົດຂອງ theme A ອາດເຮັດໃຫ້ theme B ເສຍໂດຍບໍ່ຮູ້ຕົວ ແລະບໍ່ມີໃຜຮັບຜິດຊອບກວດ B.
ຄວາມແຕກຕ່າງແບບດຽວກັນຖືກຂຽນຊ້ຳໃນຄອມໂພເນັນຕ່າງກັນ ແຖມວິທີຂຽນຍັງບໍ່ຄືກັນ.
ເມື່ອເພີ່ມ theme ໃໝ່ ບໍ່ມີໃຜແນ່ໃຈວ່າ “ຈຸດທີ່ຕ້ອງເພີ່ມ ຖືກເພີ່ມຄົບແລ້ວຫຼືຍັງ”.

ດັ່ງນັ້ນ ສິ່ງທີ່ຕ້ອງແກ້ບໍ່ແມ່ນພຽງການປ່ຽນສີ ແຕ່ແມ່ນ: ໃຫ້ແຕ່ລະ theme ແຕກຕ່າງກັນໄດ້ທັງດ້ານຮູບລັກແລະຜະລິດຕະພັນ ພ້ອມກັບຮັກສາໃຫ້ຄອບຄົວ theme ທັງໝົດຄົບຖ້ວນ ແລະຄາດເດົາໄດ້.

ແຍກໃຫ້ຊັດກ່ອນ: layout ແລະ theme ແມ່ນຄົນລະເລື່ອງ

ປຽບທຽບກັບເຮືອນແລ້ວເຂົ້າໃຈງ່າຍທີ່ສຸດ:

ໂຄງສ້າງແລະລະບົບທໍ່: ເສົາ, ລະບົບໄຟຟ້າແລະນ້ຳ. ທຸກຫ້ອງແຖວເໝືອນກັນ ແລະບໍ່ຄວນປ່ຽນຕາມຄວາມມັກຂອງຜູ້ຢູ່.
layout: ແຜນຜັງຫ້ອງ. ຈະເປັນສອງຫ້ອງນອນຫຼືສາມຫ້ອງນອນ, ຫ້ອງຮັບແຂກຢູ່ໃສ. ກຳນົດວ່າ “ຈັດວາງສິ່ງຕ່າງໆແນວໃດ”.
theme: ການຕົບແຕ່ງ. ສີຜະໜັງ, ວັດສະດຸ, ຂະໜາດມຸມໂຄ້ງ. ກຳນົດວ່າ “ສິ່ງຕ່າງໆເບິ່ງແນວໃດ”.

ໃນ frontend, ສາມສິ່ງນີ້ແຍກໄປຢູ່ຄົນລະຊັ້ນ. ເມື່ອເອົາມາປົນກັນ ກໍຈະເກີດສະພາບເຊັ່ນ “ປ່ຽນພຽງສີໜຶ່ງສີ ແຕ່ຕ້ອງໄປແກ້ data flow”.

ໂຄງສ້າງສີ່ຊັ້ນ

Runtime theme id
      │
      ▼
  selector ──► theme leaf (complete typed config)
                   │
                   ▼
              shared view ◄── data service
                   │     └──► actions facade
                   ▼
               pure core

ເບິ່ງຈາກລຸ່ມຂຶ້ນເທິງ:

core: ຮັບຜິດຊອບພຽງການ render

ຄອມໂພເນັນ core ຮັບພຽງຂໍ້ມູນທີ່ “ກຽມພ້ອມແລ້ວ ແລະ render ໄດ້ໂດຍກົງ” ແລະສົ່ງອອກພຽງເຈດຕະນາ (intent) ຂອງຜູ້ໃຊ້. ມັນບໍ່ຮູ້ວ່າຕອນນີ້ເປັນ theme ໃດ, ບໍ່ແຕະ routing, ບໍ່ແຕະຮູບແບບຂໍ້ມູນທີ່ API ສົ່ງກັບມາ ແລະບໍ່ອ້າງອີງໄຟລ໌ສື່ຂອງແບຣນໃດໆ.

export class ThemeCardCoreComponent {
  readonly appearance = input.required<ThemeAppearance>();
  readonly content = input.required<ThemeContent>();
  readonly items = input.required<readonly ShowcaseItem[]>();
  readonly selectedId = input<string | null>(null);

  readonly itemSelected = output<ShowcaseItem>();
  readonly selectionCleared = output<void>();
}

core ຖືກໃຊ້ຮ່ວມກັນໃນທຸກ theme ຈຶ່ງມີຂອບເຂດຜົນກະທົບກວ້າງທີ່ສຸດ ແລະມີກົດເຂັ້ມງວດທີ່ສຸດ: ຮັບເຂົ້າສະເພາະສິ່ງຈຳເປັນ, ສົ່ງອອກສະເພາະເຈດຕະນາ.

view: ຮັບຜິດຊອບການປະສານງານ

view ເປັນຕົວກາງ. ມັນດຶງຂໍ້ມູນຈາກ data service ແລ້ວແປງໃຫ້ເປັນຮູບແບບທີ່ core ຕ້ອງການ; ເມື່ອ core ສົ່ງເຈດຕະນາອອກມາ ກໍສົ່ງຕໍ່ໃຫ້ actions facade ຈັດການ.

@Component({
  selector: 'case-study-theme-card-view',
  providers: [FeatureActionsFacade, FeatureDataService],
  template: `
    <case-study-theme-card-core
      [appearance]="appearance()"
      [content]="themeContent()"
      [items]="data.items()"
      [selectedId]="actions.selectedId()"
      (itemSelected)="select($event)"
      (selectionCleared)="actions.reset()"
    />
  `,
})
export class ThemeCardViewComponent { /* ... */ }

ທັງທີ່ມາຂອງຂໍ້ມູນ (data service) ແລະສິ່ງທີ່ຈະເຮັດເມື່ອກົດ (actions facade) ຕ່າງກໍມີຂອບເຂດທີ່ຊັດເຈນ ບໍ່ໄດ້ກະຈາຍຢູ່ຕາມຄອມໂພເນັນຂອງໜ້າຈໍ.

layout ເໝາະທີ່ຈະວາງໄວ້ໃນຊັ້ນນີ້. ແຜນຜັງທີ່ແຕກຕ່າງກັນສາມາດເປັນ shared view ຄົນລະອັນ; ພວກມັນໃຊ້ data service ແລະ facade ຊຸດດຽວກັນ ພຽງແຕ່ຈັດວາງ core ຄົນລະແບບ. Demo ສາທາລະນະມີ shared view ພຽງອັນດຽວເພື່ອໃຫ້ງ່າຍ; ສ່ວນການປັບໂຄງສ້າງ production ຄັ້ງນັ້ນໄດ້ນຳມາໃຊ້ 26 ອັນ.

theme leaf: ໜຶ່ງ leaf ຕໍ່ໜຶ່ງ theme

ແຕ່ລະ theme ເປັນຄອມໂພເນັນທີ່ບາງຫຼາຍ ເຮັດພຽງຢ່າງດຽວ: ເລືອກຊຸດການຕັ້ງຄ່າຮູບລັກທີ່ຄົບຖ້ວນ ແລ້ວສົ່ງໃຫ້ shared view.

@Component({
  selector: 'case-study-theme-aurora',
  imports: [ThemeCardViewComponent],
  template:
    '<case-study-theme-card-view [appearance]="appearance" data-theme-leaf="aurora" />',
})
export class ThemeAuroraComponent {
  protected readonly appearance = THEME_APPEARANCES.aurora;
}

ຂ້າງໃນບໍ່ມີເງື່ອນໄຂທາງທຸລະກິດໃດໆ. ໃນ production, ຫຼັງປັບໂຄງສ້າງ theme leaf ທີ່ຄົບຖ້ວນແລະເປັນຕົວແທນໜຶ່ງອັນແລ້ວ ມີ 23 ແຖວ; ເສັ້ນທາງດຽວກັນໃນວິທີຂຽນເກົ່າມີຫຼາຍຮ້ອຍແຖວ.

selector: ລະບຸສະມາຊິກໃນກຸ່ມໃຫ້ຊັດເຈນ

selector ເບິ່ງຈາກ theme id ຂອງ runtime ແລ້ວ render leaf ທີ່ກົງກັນ:

@switch (theme()) {
  @case ('aurora') { <case-study-theme-aurora /> }
  @case ('summit') { <case-study-theme-summit /> }
  @default { <case-study-theme-default /> }
}

ມັນເບິ່ງທຳມະດາດີ, ແຕ່ຈຸດສຳຄັນແມ່ນ “ຄວາມຊັດເຈນ”: ມີ theme ໃດແດ່ ແລະແຕ່ລະອັນກົງກັບ leaf ໃດ ສາມາດເຫັນໄດ້ທັນທີ ແລະໃຫ້ tests ກວດເທື່ອລະອັນໄດ້.

ໃຫ້ compiler ຊ່ວຍກວດລາຍຊື່

ຍິ່ງມີ themes ຫຼາຍ ຍິ່ງຢ້ານວ່າຈະຕົກຫຼົ່ນ. ເພີ່ມ theme ໃໝ່ແລ້ວລືມເພີ່ມ config; ປ່ຽນຮູບແບບ config ແລ້ວມີ themes ເກົ່າບາງອັນຕາມບໍ່ທັນ.

ວິທີເຮັດແມ່ນກຳນົດລາຍຊື່ theme ໄວ້ຈາກແຫຼ່ງຂໍ້ມູນດຽວກ່ອນ ແລ້ວໃຊ້ satisfies ຂອງ TypeScript ບັງຄັບໃຫ້ແຕ່ລະ theme ມີ config ທີ່ຄົບຖ້ວນໜຶ່ງຊຸດ:

export const DEMO_THEMES = ['default', 'aurora', 'summit'] as const;
export type DemoTheme = (typeof DEMO_THEMES)[number];

export interface ThemeAppearance {
  readonly density: 'comfortable' | 'compact';
  readonly id: DemoTheme;
  readonly stylesheetHref: `themes/${string}.css`;
}

export const THEME_APPEARANCES = {
  default: { id: 'default', density: 'comfortable', stylesheetHref: 'themes/default.css' },
  aurora: { id: 'aurora', density: 'comfortable', stylesheetHref: 'themes/aurora.css' },
  summit: { id: 'summit', density: 'compact', stylesheetHref: 'themes/summit.css' },
} satisfies Record<DemoTheme, ThemeAppearance>;

ເພີ່ມ theme ໃໝ່ໃນ DEMO_THEMES ແຕ່ບໍ່ເພີ່ມ config ໃນ THEME_APPEARANCES, ການ compile ຈະລົ້ມເຫຼວ. ຊື່ field ພິມຜິດ ຫຼືຮູບແບບເສັ້ນທາງ CSS ບໍ່ຖືກ ກໍເຊັ່ນກັນ.

ຂໍ້ດີຂອງ satisfies ເມື່ອທຽບກັບການກຳນົດ type ໂດຍກົງແມ່ນ: ມັນກວດຮູບຮ່າງຂໍ້ມູນ ແຕ່ຍັງຮັກສາ type ສະເພາະຂອງແຕ່ລະຄ່າໄວ້; ເມື່ອນຳ THEME_APPEARANCES.aurora ໄປໃຊ້ຕໍ່ ມັນຈຶ່ງບໍ່ຖືກຂະຫຍາຍເປັນ ThemeAppearance ທົ່ວໄປ.

ໃຫ້ tests ຮັກສາຄວາມຄົບຖ້ວນຂອງທັງກຸ່ມ

compiler ກວດ config ໄດ້ ແຕ່ກວດບໍ່ໄດ້ວ່າ “theme ນີ້ render ອອກມາໄດ້ຈິງຫຼືບໍ່”. ສ່ວນນີ້ໃຫ້ tests ຄວາມຄົບຖ້ວນຂອງກຸ່ມກວດ ໂດຍໄລ່ລາຍຊື່ theme ທຸກອັນທີ່ປະກາດໄວ້:

it.each(DEMO_THEMES)('renders the %s family leaf', (theme) => {
  const fixture = TestBed.createComponent(ThemeSelectorComponent);
  fixture.componentRef.setInput('theme', theme);
  fixture.detectChanges();

  expect(
    fixture.nativeElement.querySelector(`[data-theme-leaf="${theme}"]`),
  ).toBeTruthy();
});

ຝັ່ງ config ກໍມີ tests ທີ່ກົງກັນ: field id ຂອງ config ແຕ່ລະ theme ຕ້ອງຄືກັນກັບ key ຂອງມັນໃນຕາຕະລາງ config; ເສັ້ນທາງ CSS ກໍຕ້ອງຕົງຕາມກົດຂອງກຸ່ມ.

ການກວດສອງແບບນີ້ລວມກັນ ປ່ຽນວຽກທີ່ເຄີຍຕ້ອງອາໄສການ review ດ້ວຍມືວ່າ “ມີ theme ໃດໃນກຸ່ມ sibling ຕົກຫຼົ່ນຫຼືບໍ່” ໃຫ້ກາຍເປັນຂໍ້ຜິດພາດທີ່ CI ຈະຂັດໄວ້. ຖ້າມີ themes ຫຼາຍກວ່າໜຶ່ງຮ້ອຍ ສາຍຕາຄົນກວດບໍ່ໝົດດອກ.

ດາວໂຫຼດສະເພາະ theme CSS ທີ່ກຳລັງໃຊ້

ການແບ່ງຊັ້ນແກ້ບັນຫາການບຳລຸງຮັກສາ ແຕ່ການມີຫຼາຍ theme ຍັງມີຕົ້ນທຶນຢ່າງໜຶ່ງທີ່ກະທົບໂດຍກົງຕໍ່ຜູ້ໃຊ້: CSS.

ວິທີເກົ່າລວມ stylesheet ຂອງ 136 themes ໄວ້ໃນຊຸດດຽວ. ບໍ່ວ່າຜູ້ໃຊ້ຈະໃຊ້ theme ໃດ ກໍຕ້ອງດາວໂຫຼດແລະວິເຄາະທັງໝົດ. ຫຼັງປ່ຽນມາໂຫຼດຕາມຄວາມຕ້ອງການ ຊັບພະຍາກອນຂອງ theme ດຽວຫຼຸດຈາກປະມານ 2.4 MB ເຫຼືອ 17 KB, ຫຼຸດລົງປະມານ 99%.

ກົນໄກເອງງ່າຍຫຼາຍ: config ຂອງແຕ່ລະ theme ປະກາດ stylesheetHref ຂອງຕົນ, ແລ້ວໃຫ້ loader ພຽງໜຶ່ງອັນ ຈັດການ <link> ຂອງ theme ທີ່ຢູ່ໃນໜ້າ:

@Injectable()
export class ThemeStylesheetLoader {
  readonly #document = inject(DOCUMENT);

  load(href: ThemeAppearance['stylesheetHref']): void {
    const id = 'case-study-theme-stylesheet';
    const existing = this.#document.getElementById(id) as HTMLLinkElement | null;
    const link = existing ?? this.#document.createElement('link');

    link.id = id;
    link.rel = 'stylesheet';
    if (link.getAttribute('href') !== href) link.setAttribute('href', href);
    if (!existing) this.#document.head.append(link);
  }
}

ແພລດຟອມເອີ້ນໃຊ້ມັນໃນຕອນປ່ຽນ theme:

effect(() => {
  const appearance = THEME_APPEARANCES[this.selectedTheme()];
  this.#stylesheetLoader.load(appearance.stylesheetHref);
});

ຈຸດສຳຄັນຄື “ມີພຽງໜຶ່ງອັນ”. ຖ້າແຕ່ລະຈຸດເພີ່ມ <link> ຂອງຕົນເອງ, ເມື່ອສະຫຼັບໄປມາຫຼາຍຄັ້ງ ກໍຈະເຫຼືອ style ຂອງ theme ເກົ່າ ຫຼື CSS ສອງຊຸດຂຽນທັບກັນໄປມາ. tests ຈະກວດຢືນຢັນວ່າ ຫຼັງສະຫຼັບຫຼາຍຄັ້ງແລ້ວ ໜ້າເວັບຍັງມີ stylesheet ທີ່ຖືກຈັດການຢູ່ພຽງອັນດຽວ.

theme CSS ມີໜ້າທີ່ກຳນົດພຽງ design token (ຕົວປ່ຽນ CSS); ສ່ວນ style ຂອງ core ອ່ານແຕ່ຕົວປ່ຽນເຫຼົ່ານີ້:

:root {
  --demo-surface: #fffaf1;
  --demo-text: #3b2620;
  --demo-accent: #c65367;
  --demo-radius: 30px;
}

ດັ່ງນັ້ນ ການປ່ຽນ theme ກໍຄືປ່ຽນຕາຕະລາງຕົວປ່ຽນອີກຊຸດໜຶ່ງ; style ຂອງ core ບໍ່ຕ້ອງປ່ຽນເລີຍ. ໂໝດສະຫວ່າງແລະມືດກໍເປັນຕົວປ່ຽນອີກຊຸດໜຶ່ງໃນໄຟລ໌ດຽວກັນ.

ຂໍ້ແລກປ່ຽນ

ການອອກແບບນີ້ກໍມີຕົ້ນທຶນຄືກັນ:

ມີໄຟລ໌ເພີ່ມຂຶ້ນ. ໜຶ່ງ leaf ຕໍ່ໜຶ່ງ theme ແລະໜຶ່ງ view ຕໍ່ໜຶ່ງ layout ເຮັດໃຫ້ຈຳນວນໄຟລ໌ນ້ອຍໆເພີ່ມຂຶ້ນ. ສິ່ງທີ່ໄດ້ຄື ເຫັນໜ້າທີ່ຂອງແຕ່ລະໄຟລ໌ໄດ້ທັນທີ ແລະກວດຄວາມຄົບຖ້ວນໄດ້.
config ບໍ່ຄວນກາຍເປັນພາສາຂຽນໂປຣແກຣມ. config ເໝາະສຳລັບອະທິບາຍຮູບລັກແລະຄວາມແຕກຕ່າງທີ່ມີຂອບເຂດ. ຖ້າເລີ່ມຂຽນເງື່ອນໄຂຫຼືຂັ້ນຕອນເຂົ້າໄປໃນ config, ກໍແມ່ນພຽງແຕ່ຍ້າຍ if/else ໄປຊ່ອນໄວ້ບ່ອນອື່ນ.
core ຕ້ອງມີ tests ສັນຍາການໃຊ້ງານທີ່ເຂັ້ມແຂງຂຶ້ນ. ມັນຖືກໃຊ້ຮ່ວມກັນໃນທຸກ theme, ການປ່ຽນຄັ້ງດຽວຈຶ່ງກະທົບຫຼາຍກວ່າ 100 themes.
ການປ່ຽນ CSS ໃນ runtime ຕ້ອງມີ owner ພຽງຜູ້ດຽວ. ການເອີ້ນ stylesheet ໂດຍບໍ່ປະສານກັນອາດເຮັດໃຫ້ກະພິບຫຼືມີ style ຄ້າງ; ນີ້ຄືເຫດຜົນທີ່ loader ຕ້ອງມີພຽງໜຶ່ງອັນ.
ການ cache ຍັງສຳຄັນ. ເຖິງຈະໂຫຼດພຽງ theme ດຽວ, ຊື່ໄຟລ໌ທີ່ຄົງທີ່ແລະ cache header ກໍຍັງກຳນົດຄວາມໄວເມື່ອກັບມາໃຊ້ອີກ.

ຄວນໃຊ້ວິທີນີ້ເມື່ອໃດ

ຖ້າຜະລິດຕະພັນຂອງເຈົ້າມີພຽງໂໝດສະຫວ່າງແລະມືດ, CSS variables ກໍພຽງພໍແລ້ວ ບໍ່ຈຳເປັນຕ້ອງໃຊ້ລະບົບທັງຊຸດນີ້.

ເມື່ອເລີ່ມພົບສະພາບເຫຼົ່ານີ້ ກໍຄວນພິຈາລະນາ:

ມີ themes ຫຼືລຸ້ນສຳລັບລູກຄ້າເກີນສິບອັນ ແລະຍັງເພີ່ມຂຶ້ນຕໍ່ໄປ.
ຄວາມແຕກຕ່າງລະຫວ່າງ themes ບໍ່ໄດ້ມີພຽງສີ ແຕ່ຍັງມີການຈັດວາງ, ການເປີດປິດຟີເຈີ ແລະຂໍ້ຄວາມ.
ການປັບຕາມຂໍ້ກຳນົດຂອງ theme ໜຶ່ງ ມັກສົ່ງຜົນກະທົບຕໍ່ອີກ theme ໜຶ່ງໂດຍບັງເອີນ.
ເມື່ອເພີ່ມ theme ໃໝ່ ບໍ່ມີໃຜແນ່ໃຈວ່າຕ້ອງເພີ່ມຫຍັງບ່ອນໃດ.

ຂອບເຂດຂອງຫຼັກຖານ

ຕ້ອງລະບຸຂອບເຂດຂອງຕົວເລກ production ທີ່ກ່າວເຖິງໃນບົດຄວາມນີ້ໃຫ້ຊັດເຈນ:

23 ແຖວ ແມ່ນ theme leaf ທີ່ຄົບຖ້ວນແລະເປັນຕົວແທນໜຶ່ງອັນຫຼັງປັບໂຄງສ້າງ; ບໍ່ໄດ້ໝາຍຄວາມວ່າ leaf ຫຼືໄຟລ໌ທຸກອັນມີ 23 ແຖວ.
migration ຄັ້ງນັ້ນນຳໃຊ້ໂມດູນໃໝ່ໃນສະຖາປັດຕະຍະກຳ 70 ໂມດູນ (facade 24 ອັນ, data service 10 ອັນ, theme config 10 ຊຸດ, shared view 26 ອັນ). ນີ້ແມ່ນຂອບເຂດການປັບປຸງ ບໍ່ແມ່ນຜົນງານດ້ານປະສິດທິພາບຫຼືການຫຼຸດຈຳນວນ code.
2.4 MB → 17 KB ແມ່ນຜົນວັດຈິງໃນ production. CSS ຂະໜາດນ້ອຍສາມຊຸດໃນ Demo ສາທາລະນະບໍ່ສາມາດສະແດງຜົນຕົວເລກນີ້ຄືນໄດ້.
ໃນໂຄງການປັບຄຸນນະພາບດຽວກັນ, Lighthouse Performance ຂອງໜ້າທີ່ວັດເປັນຫຼັກດີຂຶ້ນຈາກ 50+ ເປັນ 90+, ແຕ່ນັ້ນແມ່ນຜົນລວມຈາກການປັບປຸງຫຼາຍຢ່າງ ບໍ່ແມ່ນຜົນຈາກການໂຫຼດ CSS ຕາມຄວາມຕ້ອງການຢ່າງດຽວ.

ສິ່ງທີ່ repo ສາທາລະນະພິສູດແມ່ນກົນໄກຂອງສະຖາປັດຕະຍະກຳເອງ: ສັນຍາແບບກຳນົດປະເພດ, ການສະຫຼັບໃນ runtime, tests ຄວາມຄົບຖ້ວນຂອງກຸ່ມ, CSS ທີ່ໂຫຼດຕາມຄວາມຕ້ອງການ ແລະ CI ທີ່ຮັນການກວດເຫຼົ່ານີ້. ຕາຕະລາງທຽບຂໍ້ອ້າງອີງກັບຫຼັກຖານທັງໝົດຢູ່ໃນ repo ທີ່ ການກວດສອບຂອບເຂດຫຼັກຖານ.

ຖ້າຢາກເບິ່ງຜົນໂດຍກົງ ເປີດ Demo ອອນລາຍ ເພື່ອສະຫຼັບສາມ themes, ພາສາ ແລະໂໝດສະຫວ່າງຫຼືມືດ ແລ້ວປຽບທຽບກັບ source code ເທິງ GitHub.