Terdapat beberapa cara bagaimana Sistem Reka Bentuk boleh diasaskan — bawah-atas, atas-bawah, luaran, berasal daripada keperluan reka bentuk atau pembangunan dan mungkin beberapa yang lain. Satu perkara yang pasti — penting untuk memulakan perkara yang kecil, sambil memerhatikan persediaan masa hadapan, yang penting untuk pertumbuhan yang mampan.
Asas yang anda bina hari ini mesti menyokong keperluan semasa sambil tangkas dan difikirkan dengan teliti untuk mencukupi evolusi keperluan secara beransur-ansur dalam projek atau organisasi. Artikel ini memfokuskan pada tulang belakang teknikal, yang penting untuk mencipta Sistem Reka Bentuk yang boleh memenuhi cita-cita yang semakin berkembang.
The ? Templat Pemula Sistem Reka Bentuk (DSS) dibina di atas komponen teras yang mewujudkan asas teknikal yang kukuh untuk Sistem Reka Bentuk boleh skala dan boleh diselenggara. Komponen ini memastikan reka bentuk dan pembangunan adalah konsisten, fleksibel dan cekap.
⭐️ https://github.com/XOP/design-system-starter
Dalam bahagian berikut, kami akan meninjau keseluruhan modul primer dan sekunder templat DSS, serta perkhidmatan dan perkakasnya. Di samping itu, kami akan meneroka keberkesanan kos mereka pada peringkat awal Sistem Reka Bentuk dan potensinya dalam peringkat yang lebih matang.
Pustaka UI DSS berfungsi sebagai tiang utama Templat DSS, dibina dengan react-aria untuk memastikan komponen UI tanpa kepala yang diutamakan kebolehaksesan. Walaupun React ialah rangka kerja dipilih untuk templat, DSS bertujuan untuk mudah disesuaikan kepada rangka kerja lain seperti Vue atau Solid. Kebolehsuaian ini membolehkan pasukan memilih teknologi yang paling sesuai dengan keperluan projek mereka tanpa dikunci dalam timbunan tertentu
Untuk penggayaan UI DSS bergantung pada ekstrak vanila, yang menyediakan asas CSS masa jalan sifar berskala yang teguh. Sekali lagi, ini adalah pilihan yang fleksibel, membenarkan pendekatan alternatif seperti modul CSS, CSS Panda, Tailwind dll.
Untuk kestabilan, komponen UI bergantung pada perpustakaan ujian, memfokuskan pada kefungsian pada mulanya. Senario ujian khusus mungkin tidak berkaitan dalam kes komponen bertema (tanpa kepala), tetapi penting dalam senario lain.
Struktur komponen yang terhasil kelihatan agak mudah:
Switch/ index.ts Switch.css.ts - styles created with vanilla-extract Switch.spec.tsx - tests using testing-library Switch.stories.tsx - documentation with Storybook stories Switch.tsx - component based on react-aria
Perlu dinyatakan bahawa walaupun UI DSS tidak mengikuti pendekatan berbilang pakej, ia masih membenarkan penggoncangan pokok, memanfaatkan pilihan rollup masing-masing dalam konfigurasi Vite:
// named import
import { Button } from '@ds-starter/ui';
// default import
import Button from '@ds-starter/ui/components/Button/Button';
Aspek kritikal perpustakaan UI ialah penggabungan awal Token Reka Bentuk. Token adalah asas untuk mengekalkan penggayaan yang konsisten merentas Sistem Reka Bentuk, membenarkan walaupun projek yang tidak menggunakan perpustakaan UI penuh mendapat manfaat daripada bahasa reka bentuk yang padu. Dengan adanya token semantik yang betul, warna boleh ditukar dengan mudah tanpa memerlukan pemfaktoran semula secara besar-besaran. Selain itu, dengan pendekatan modular kami tidak begitu peduli bagaimana Token Reka Bentuk dibina, sebaliknya apa yang sedang dikeluarkan.
Token Reka Bentuk adalah penting kepada ketekalan dan fleksibiliti Sistem Reka Bentuk. Ia menyediakan pendekatan piawai untuk tema dan penggayaan merentas semua modul dan aplikasi, memastikan setiap elemen UI kekal padat.
DSS token warna dijana menggunakan ? Unicornix, alat yang membolehkan untuk mencipta palet warna yang boleh diakses dan disesuaikan, menyediakan permulaan yang mudah dengan mod terang dan gelap. Tipografi dan beberapa token lain dicipta dengan ? Penjana Token Reka Bentuk. Ini secara keseluruhannya menyediakan asas yang kukuh untuk penskalaan lanjut tanpa menghadapi sekatan jalan raya yang besar.
Unicornix - penjanaan palet warna bertema dan boleh diakses. Versi terkini: 0.7.0-beta.0, terakhir diterbitkan: 9 hari yang lalu. Mula menggunakan unicornix dalam projek anda dengan menjalankan `npm i unicornix`. Terdapat 1 projek lain dalam pendaftaran npm menggunakan unicornix.
npmjs.com
DSS Tokens are available in both CSS and JavaScript formats, to reflect and support different project needs, from simple websites to complex web applications. Theming can be done in several ways, and here we fully rely on CSS custom properties.
Here is an excerpt from the generated CSS.
It’s easy to note that theme can be swapped completely by changing a single data attribute:
:root[data-theme="light"], [data-theme="light"] {
--awsm-color-content-strong: rgb(24, 26, 27);
--awsm-color-content-regular: rgb(45, 47, 49);
--awsm-color-background-regular: rgb(255, 255, 255);
--awsm-color-background-subtle: rgb(236, 237, 237);
}
:root[data-theme="dark"], [data-theme="dark"] {
--awsm-color-content-strong: rgb(255, 255, 255);
--awsm-color-content-regular: rgb(229, 230, 231);
--awsm-color-background-regular: rgb(0, 0, 0);
--awsm-color-background-subtle: rgb(9, 10, 11);
}
JS tokens can be consumed as CSS refs, containing the references to values, rather than the color strings. This approach is great for semantic variables and theming without sacrificing performance:
export const tokens = {
content: {
strong: "var(--awsm-color-content-strong)",
regular: "var(--awsm-color-content-regular)",
},
background: {
regular: "var(--awsm-color-background-regular)",
subtle: "var(--awsm-color-background-subtle)",
}
}
The Icons and Fonts modules add depth to the visual language. Icons are managed through an efficient process that generates components from SVG files using SVGR and tsup. This ensures that icons are consistent and can be flexibly integrated across the system.
Similar to UI components, icons can be also imported individually:
// named import
import { IconX } from '@ds-starter/icons';
// default import
import IconX from '@ds-starter/icons/lib/IconX';
// Source (SVG) import
import IconXSrc from '@ds-starter/icons/svg/x.svg';
The Fonts package offers a convenient solution for managing typography within the Design System. It supports both base64-encoded fonts for quick setups and Google Fonts integration for more robust implementations, giving teams the flexibility to choose the best approach for their project’s needs while maintaining consistent typography across all digital products.
It’s worth noting that while base64 encoding is efficient, it’s not effective for production setup. Yet in the early stages it can be a common denominator for consistent typography. Of course going further this should be replaced with the more appropriate fonts-loading strategy.
Now, the question arises — should you setup Icons and Fonts packages from the start? The answer naturally depends, however in most typical scenarios it will be a “no”. More agile environment in the early stages is crucial and less dependencies is the key. Yet, keeping in mind the upcoming structure and incorporating that in the early setup is a good idea, shaving off a couple of dozen “story points” in the future refactorings.
Storybook is an important tool for UI development, serving primarily as a development environment and a documentation portal on early stages of Design System. It allows to visualize and interact with UI components in various states and configurations, resolving issues early in the development process.
Storybook in DSS is a standalone app that does not itself host any stories — they all are collected across the packages and composed in one central hub. This way DSS Storybook can document color palettes, typography, iconography etc. along with the UI components from different sources after a simple setup.
? Note that there is no storybook composition per se,
yet it’s also possible as one does not deny the other.
Explore the deployed demo here: https://ds-starter-storybook.vercel.app/
Beyond its direct functionality, DSS Storybook is additionally equipped with Visual Regression Testing (VRT) and Accessibility Testing using Playwright. Such automation is essential for large design systems, where manual testing could quickly grow ineffective and time-consuming. By integrating these tests into the development workflow (early), DSS ensures that the Design System can evolve fast without fear of regressions.
While being an irreplaceable tool for early-stage documentation, consolidating component documentation and visual examples into a single platform, Storybook is not actually a documentation website. With time, more sophisticated, content-oriented and customizable solution is demanded, especially for the Design System consumers far apart from technology.
As the Design System matures, the need for more detailed and accessible documentation becomes paramount. The DSS Documentation Website (DSS Docs) addresses this need by providing a dedicated application for organizing and presenting information about the Design System.
Explore the deployed demo here: https://ds-starter-docs.vercel.app/
DSS Docs is designed to be minimalistic yet highly functional and customizable. It includes several modules that can be tweaked and modified to meet the project purpose. Powered by Astro and enhanced with nanostores state manager, DSS Docs implies two main types of content: Articles and Component Documentation.
Articles offer in-depth insights into Design System concepts, provide guidelines, patterns and describe foundational layers in detail. To add a new Article is as easy as simply to place a Markdown file into the respective folder.
Component Documentation includes interactive examples dynamically loaded from the Storybook stories. This integration solves a couple of issues — it ensures consistency across the “Dev” and “Prod” documentation and avoids redundancy in content creation.
? As a bonus — component examples can be edited in the UI library and will be automatically picked up by Docs running in dev mode. Not a Storybook replacement, but can be useful for cosmetic updates.
New Component Documentation can be added with a MDX file, following a particular schema. Apart from the main description, extra sections can be added following the “Usage” pages example.
Expandable structure of DSS Docs allows for easy updates and tweaks, making it an essential tool for teams looking to step up from Storybook without significant effort and creating redundancy. The Documentation app is themed with DSS Tokens to ensure a consistent look and feel of the main product.
DSS leverages a series of scripts to handle essential tasks like testing, linting, formatting, and dependency management. Turborepo offers great help for running scripts effectively, especially when every module adheres to a unified standard.
What’s more, everything that we run locally, including Visual Regression Testing — can be done on CI, thanks to Github Actions. Apart from the thorough quality checks, Github Actions will take care of apps deployment too (powered by Vercel). Naturally, all scripts are configurable and optional.
DSS uses Changesets to automate the processes of changelog generation and packages releases, ensuring every change is tracked and properly versioned. Needless to say, both processes are supported by Github Actions as well.
Here are some examples of published NPM packages:
@ds-starter/fonts
@ds-starter/icons
@ds-starter/tokens
@ds-starter/ui
To further enhance productivity, DSS includes a Turbo-powered Generator that simplifies the process of scaffolding new UI components. Apart from saving time, this allows to greatly reduce the human-error-copy-paste factor.
# Run a generator $ pnpm run gen:ui
After replying to a series of prompts, you will get the following:
New component scaffolded in the DSS UI package, containing all respective files
Same component added to the DSS Docs application, with the correct MDX frontmatter data
Like almost everything in DSS, generator template can and most probably need to be tweaked to the project needs. This is a completely arbitrary operation, however using generator can be very beneficial for contributors, onboarding of team members and scenarios like codebase migration.
Design System technological stack is an arbitrary matter, however it’s for sure not random. It’s a natural effect of multiple contributing factors, including, but not limited to:
product scope and project peculiarities
initial size and future ambitions
teams expertise and proficiency
contributors and consumers proficiency
client requirements and technical stack
overall codebase age and historical reasons
existing technical debt
cross-platform and cross-browser support
maintainability requirements
existing or upcoming deadlines
industry trends and market volatility
organization structural changes
dan banyak lagi…
? Adakah anda berminat dengan artikel khusus mengenai perkara ini? Beritahu saya!
⭐️ Selain itu, anda sudah melepasi 2000 perkataan, juara membaca!
Matlamat templat DSS bukan untuk mematuhi setiap senario, tetapi untuk mencadangkan amalan terbaik purata industri yang boleh disesuaikan lagi dengan pengalaman yang diingini. Boleh difahami, Templat tidak sesuai dengan banyak sistem, walau bagaimanapun corak dan coretan yang dibentangkan boleh diterokai, digunakan semula, ditambah baik dan diharapkan dapat memberi inspirasi kepada ciptaan baharu.
Sepanjang artikel itu, kami melihat pelbagai teknologi digunakan untuk mengarang Templat DSS dan memberikan pengalaman pembangun yang holistik dan berfungsi. Sebenarnya, masih banyak lagi, dialu-alukan untuk menerokai dokumentasi komprehensif.
Teknologi tersebut pada asasnya boleh dikumpulkan ke dalam kategori "Terpilih", "Disyorkan" dan "Berpendapat", supaya setiap yang berikutnya lebih berat sebelah daripada yang sebelumnya.
Pertimbangkan contoh:
Daripada semua pilihan teknologi lain, saya ingin (selain itu) menyerlahkan yang Berpendapat:
Akhir sekali, Typescript ialah teknologi yang menonjol berada dalam ketiga-tiga kumpulan serentak. Ia telah lama wujud untuk menjadi standard industri, ia biasanya disyorkan untuk projek kompleks seperti Sistem Reka Bentuk dan saya juga akan menggunakannya lebih lanjut untuk sebab yang sama.
Membina sebarang produk memerlukan asas yang kukuh, pelan hala tuju yang jelas, persediaan rapi dan semakan tepat pada masanya pada setiap peristiwa penting. Apabila keperluan berkembang dari semasa ke semasa, teknologi anda harus cukup berdaya tahan untuk menyesuaikan diri dengan tetapan baharu secara berkesan.
Dengan Sistem Reka Bentuk, ia adalah semua itu, tambah elemen gerakan kekal. Bolehkah anda memikirkan pendekatan pembangunan sejagat yang boleh mengendalikan ketidakpastian projek dan serba boleh melangkaui Penandaan dan Gaya yang baik? Mungkin kemudian, tetapi buat masa ini, ini hanya caranya.
The ? Templat Pemula Sistem Reka Bentuk boleh membantu anda dalam mewujudkan teras teknologi yang kukuh dan malah boleh menjadi titik permulaan yang hebat, menyediakan penyelesaian modular dan fleksibel untuk Reka Bentuk anda yang seterusnya Cabaran sistem. Walau bagaimanapun, sebahagian besarnya, ia adalah asas untuk cerapan dan cetusan inspirasi. Ini telah berlaku kepada saya beberapa kali semasa pembangunan DSS sehingga tahap berputar pada alatan, itulah sebabnya saya fikir ia berguna. Saya pasti tidak sabar untuk dan menjemput anda ke pertemuan seterusnya.
Atas ialah kandungan terperinci Templat Pemula Sistem Reka Bentuk - Semua Teknologi Yang Anda Perlukan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
