디자인 시스템을 구축할 수 있는 방법에는 여러 가지가 있습니다. 즉, 다운탑, 탑다운, 외부, 디자인 또는 개발 요구에서 비롯된 것 등이 있습니다. 한 가지는 확실합니다. 지속 가능한 성장을 위해 중요한 미래 준비를 주시하면서 작게 시작하는 것이 중요합니다.
당신이 오늘 구축하는 토대는 현재의 요구 사항을 지원하는 동시에 프로젝트나 조직 내에서 요구 사항이 점진적으로 발전할 수 있도록 민첩하고 신중하게 생각해야 합니다. 이 글은 확장되는 야망을 만족시킬 수 있는 디자인 시스템을 만드는 데 필수적인 기술적 중추에 초점을 맞췄습니다.
? 디자인 시스템 스타터 템플릿 (DSS)은 확장 가능하고 유지 관리 가능한 디자인 시스템을 위한 강력한 기술 기반을 구축하는 핵심 구성 요소를 기반으로 구축되었습니다. 이러한 구성 요소는 설계와 개발이 일관되고 유연하며 효율적이라는 것을 보장합니다.
⭐️ https://github.com/XOP/design-system-starter
다음 섹션에서는 DSS 템플릿의 기본 및 보조 모듈과 해당 서비스 및 도구에 대해 간략히 설명합니다. 또한 디자인 시스템의 초기 단계에서는 비용 효율성을 알아보고 성숙 단계에서는 잠재력을 살펴보겠습니다.
DSS UI 라이브러리는 접근성 우선의 헤드리스 UI 구성 요소를 보장하기 위해 React-aria로 구축된 DSS 템플릿의 중심 기둥 역할을 합니다. React가 템플릿용으로 선택된 프레임워크인 반면, DSS는 Vue 또는 Solid와 같은 다른 프레임워크에 쉽게 적응하도록 되어 있습니다. 이러한 적응성을 통해 팀은 특정 스택에 얽매이지 않고 프로젝트 요구 사항에 가장 잘 맞는 기술을 선택할 수 있습니다
스타일링을 위해 DSS UI는 확장 가능한 강력한 제로 런타임 CSS 기반을 제공하는 바닐라 추출을 사용합니다. 하지만 이는 CSS 모듈, Panda CSS, Tailwind 등과 같은 대체 접근 방식을 허용하는 유연한 선택입니다.
안정성을 위해 UI 구성요소는 우선 기능에 중점을 두고 테스트 라이브러리에 의존합니다. 테마가 있는(헤드리스) 구성 요소의 경우 특정 테스트 시나리오가 관련이 없을 수 있지만 다른 시나리오에서는 필수적입니다.
결과 구성 요소 구조는 다소 간단해 보입니다.
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
DSS UI가 다중 패키지 접근 방식을 따르지 않더라도 여전히 Vite 구성의 각 롤업 옵션을 활용하여 트리 쉐이킹을 허용한다는 점은 언급할 가치가 있습니다.
// named import
import { Button } from '@ds-starter/ui';
// default import
import Button from '@ds-starter/ui/components/Button/Button';
UI 라이브러리의 중요한 측면은 디자인 토큰의 조기 통합입니다. 토큰은 디자인 시스템 전체에서 일관된 스타일을 유지하는 데 기초가 되므로 전체 UI 라이브러리를 활용하지 않는 프로젝트라도 응집력 있는 디자인 언어의 이점을 누릴 수 있습니다. 적절한 의미 토큰을 사용하면 대규모 리팩토링 없이도 색상을 쉽게 변경할 수 있습니다. 또한 모듈식 접근 방식을 사용하면 디자인 토큰이 어떻게 구축되는지가 아니라 무엇이 출력되는지가 중요합니다.
디자인 토큰은 디자인 시스템의 일관성과 유연성에 필수적입니다. 모든 모듈과 애플리케이션에 걸쳐 테마 지정 및 스타일 지정에 대한 표준화된 접근 방식을 제공하여 UI의 모든 요소가 응집력을 유지하도록 보장합니다.
DSS 색상 토큰은 ? Unicornix는 액세스 가능하고 사용자 정의 가능한 색상 팔레트를 생성하여 밝은 모드와 어두운 모드로 쉽게 시작할 수 있는 도구입니다. 타이포그래피 및 기타 토큰은? 디자인 토큰 생성기. 전체적으로 이는 큰 장애물을 겪지 않고 추가 확장을 위한 견고한 기반을 제공합니다.
Unicornix - 테마 설정이 가능하고 접근 가능한 색상 팔레트 생성. 최신 버전: 0.7.0-beta.0, 마지막 게시: 9일 전. `npm i unicornix`를 실행하여 프로젝트에서 unicornix 사용을 시작하세요. npm 레지스트리에는 unicornix를 사용하는 다른 프로젝트가 1개 있습니다.
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
그 외…
? 이에 대한 전용 기사에 관심이 있으십니까? 알려주세요!
⭐️ 게다가 2000단어 돌파, 독서왕!
DSS 템플릿의 목적은 모든 단일 시나리오를 준수하는 것이 아니라 원하는 경험에 더욱 맞춤화할 수 있는 업계 평균 모범 사례를 제안하는 것입니다. 이해할 수 있듯이 템플릿은 많은 시스템에 적합하지 않지만 제시된 패턴과 스니펫을 탐색하고 재사용하고 개선할 수 있으며 희망적으로 새로운 창작물에 영감을 줄 수 있습니다.
기사 전반에 걸쳐 우리는 DSS 템플릿을 구성하고 총체적이고 기능적인 개발자 경험을 제공하기 위해 사용되는 여러 기술을 관찰했습니다. 실제로 내부에는 더 많은 내용이 있습니다. 포괄적인 문서를 살펴보세요.
이러한 기술은 기본적으로 "선정", "권장" 및 "의견이 있는" 범주로 그룹화될 수 있으므로 다음 기술은 기술보다 더 편향됩니다. 이전.
예를 고려하세요:
다른 모든 기술 선택 중에서 (추가로) 의견이 있는 기술 선택을 강조하고 싶습니다.
마지막으로 Typescript는 세 그룹이 동시에 눈에 띄는 기술입니다. 업계 표준이 된지는 꽤 되었으며 일반적으로 디자인 시스템과 같은 복잡한 프로젝트에 권장되며 비슷한 이유로 앞으로도 계속 사용할 것입니다.
모든 제품을 구축하려면 탄탄한 기반, 명확한 로드맵, 신중한 준비, 모든 단계에서 시기적절한 수정이 필요합니다. 시간이 지남에 따라 요구 사항이 발전함에 따라 기술은 새로운 설정에 효과적으로 적응할 수 있을 만큼 탄력적이어야 합니다.
Design Systems를 사용하면 이 모든 것에 더하기 영구 동작 요소가 추가됩니다. 좋은 마크업과 스타일을 넘어 프로젝트 예측 불가능성과 다양성을 처리할 수 있는 보편적인 개발 접근 방식을 생각할 수 있습니까? 나중에 그럴지도 모르지만 지금은 이것이 세상의 방식입니다.
? 디자인 시스템 스타터 템플릿은 강력한 기술 핵심을 구축하는 데 도움을 제공하고 심지어 훌륭한 출발점이 되어 다음 디자인을 위한 모듈식의 유연한 솔루션을 제공할 수 있습니다. 시스템 챌린지. 그러나 대부분의 경우 이는 통찰의 기반이자 영감의 불꽃입니다. DSS를 개발하는 동안 여러 번 도구를 중심으로 이런 일이 발생했기 때문에 유용하다고 생각합니다. 다음 만남도 꼭 기대하고 초대하겠습니다.
위 내용은 디자인 시스템 스타터 템플릿 - 필요한 모든 기술의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
