Architecture

Conception

TEDI design system is divided in two parts:

1. Community components
2. TEDI components (TEDI-READY)

Repository structure will be following:

tedi-design-system/
 ├── libs  
 │   ├── react-components/  
 │   │   ├── src/  
 │   │   │   ├── tedi/  
 │   │   │   │   ├── components/  
 │   │   │   │   │   ├── Button/  
 │   │   │   │   │   │   ├── Button.tsx  
 │   │   │   │   │   │   └── Button.stories.tsx  
 │   │   │   │   │   └── ...  
 │   │   │   └── community/  
 │   │   │   │   ├── components/  
 │   │   │   │   │   ├── Card/  
 │   │   │   │   │   │   ├── Card.tsx  
 │   │   │   │   │   │   └── Card.stories.tsx  
 │   │   │   │   │   └── ...  
 │   │   │   └── ...  
 │   │   └── ...  
 │   ├── angular-components/  
 │   │   ├── src/  
 │   │   │   ├── ...  
 │   │   │   └── ...  
 │   │   └── ...  
 ├── nx.json  
 ├── tsconfig.base.json  
 └── package.json

Community components

All current components in Disainipesa are by default community components in TEDI. This means that responsibility for development, quality direction, etc., lies with the contributor. The goal of community components is to serve as a central repository for sharing reusable components (similar to how Disainipesa operates today). Currently, we have agreed that the TEDI team (maintainer) does not control the content or intervene except in the following ways: One of the code reviewers by default is also a developer from the TEDI team. However, only one developer is still mandatory as the reviewer for PRs, and waiting for acceptance from a TEDI team developer is not obligatory. The aim as a maintainer is to stay informed about what's happening with community components so that in the future, they can be converted into TEDI components or provide guidance to ensure that the design system doesn't deviate too far. The maintainer is responsible for the release process. Meaning, the TEDI team ensures that during the development of community components, TEDI components are not (accidentally) altered. This is because, for the convenience of developers, the same repository and libraries are shared.

TEDI-READY components

TEDI components are maintained by a maintainer. To become a TEDI component, it must meet the DoD. This means that a contributor can create a TEDI component, submit the corresponding pull request, and the maintainer must accept it in all parts described in the DoD.