# Using Fluent UI and building up an ecosystem ## Customer roles ### Consumer A developer who wants to use Fluent UI. They know how to build things, they have their own opinions on things. They just want to know how to use the doodads. ### Advanced consumer A developer who aspires to build components to share, and wants to leverage tools and patterns but is really application focused and may not contribute. ### Contributor A developer who is contributing to Fluent UI ecosystem and must follow conformance guidelines. ## Scenarios ### Scenario 1: Paul needs to use/customize Fluent UI. What do they need to do? Paul needs to learn these things: * How to get started (give me some sandbox links, or CRA instructions) * Fundamentals of how components work in Fluent UI * Get fonts working * Using components * Learn about tokens * Learn about shorthand * Applying a theme * Using fonts and icons * Check out some application samples ### Scenario 2: Paul wants to build components for his app and wants to apply the same development patterns and utilities. ### Scenario 3: Paul wants to add a Task component for Fluent UI in his own repo. Paul will follow these guidelines: * What dependency versions? * Keep React and Typescript updated to >= Fluent UI repo version * What utilities do I import? * yarn install `@fluentui/create-component` * `npx @fluentui/create-component Task` This will generate the scaffolded file structure for your component: * Your repo must support these things: * TypeScript build * Sass build ## Scenario 1 ### Concepts ### What are the requirements for a Fluent UI React component? ## End outcome Public docs which clearly and consistently describe a component that feels like part of the ecosystem. That means: - [ ] Props are named consistently - [ ] Customizability works consistently - [ ] Theming works consistently - [ ] Default look fits in with the rest of the suite - [ ] Accessibility works consistently * Focus rects only show when you use the keyboard * Aria/role attributes are set correctly, but can be overridden Conformance requirements * Filename structure * Typings * Props and namings * General expectations * "as" prop * Unhandled props to root * Shorthand/slots * Base unstyled components * Layer on the styling/tokens using compose Accessibility Contrast ratios, keyboarding, narrator API Interfaces Design Tokens? Component Naming conventions Package Naming conventions Registering & Discovery of components Unit tests?