---
# System prepended metadata

title: Using Fluent UI and building up an ecosystem

---

# 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?


