---
# System prepended metadata

title: Platform Team Docs/Dev Process

---

# Platform Team Docs/Dev Process
Platform for "hosted experiences team" HEX.

## Fluent UI (react-nothstar)

Fluent UI repo contains previously Fabric and Stardust projects.  The Stardust project was renamed to `react-northstart` and all packages from Stardust were placed in the confusing and recursively named `fluentui/packages/fluentui` package :P.

Stardust == `fluentui/packages/fluentui`

Docs live in:
    `fluentui/packages/fluentui/docs/`

Example files (currently):
    `fluentui/docs/src/examples/components/Button/Types/ButtonExample.tsx`

We plan to move examples out of the `docs` package co-located with the components themselves.  At the least, we want to enable our docs to ship standalone and be used with any compoents so examples need to move out of `docs`.
    

## Authoring

### Components

* One directory per component, including its subcompoents
* One component per file
* Use a docblock on the default component export and on each prop in typings. This will be picked up by Fluent UI docs and tools.

### Unit Tests

Fluent UI uses Jest and Enzyme for unit testing in a jsdom env.

* One test file per component
* One `describe()` block per prop
* One `test()` per assertion for that prop, limit to effects visible to your consumers, not internal component effects

Benefits:
- Ensures clear path to testing 100% of the public API and its expected behavior
- Encourages NOT testing internal logic, which should never be tested any way (e.g. "state was set to active on click", instead, test what the user will see and expect, like "indicator is displayed on click")

#### Conformance Testing

You'll find most of your tests are duplicated since you want consistent prop behavior across components. Example, a click handler should behave the same on all components that have onClick.  Instead of re-writing the test X times, write a helper that takes in your component and runs the test against it.

Fluent UI calls these "conformance tests".  We have several assertions for common cases.  You can take a look at:

`fluentui/packages/fluentui/react-northstar/test/specs/commonTests`

Especially have a look at `isConformant()`:
`fluentui/packages/fluentui/react-northstar/test/specs/commonTests/isConformant.tsx`

### Doc

#### Examples

- Author examples using real-world code. Use the same syntax you would use in a real app in a real component file.  Sample:

    ```jsx
    import React from 'react'
    import { Button } from '@fluentui/react-northstar'

    const ButtonExample = () => <Button content="Click here" />

    export default ButtonExample
    ```
    Benefits of doing this (using real files and real syntax, fully isolated):
    - Can be linted
    - Can be compiled
    - Can be tested in isolation
    - Can be imported as a regular file
    - Is 100% identical to what your users will do with your code
    - Forces you to use your components like your consumers do
    - Allows direct porting to CodeSandbox and other tools, easily
    - Align you with future Fluent tools and docs

### Building

See `fluentui/scripts/gulp` for Fluent UI v0 build scripts.  Each package links back up to this directory.

Don't stress this directory too much, this is the part we want to make a "repo in a box" for others to use.

Suggested minimum build:

- eslint
- prettier
    - with eslint plugin
    - with eslint config
- typescript, lean toward as strict as possible as this ensures the most interop with other projects


### Repo requirements?
- Typescript
- Webpack
- Example folder structure
- Example component
- Jest + example test
- Conformance test
- Prettier
- ESLint (+ baseline config)
- Storybook?
- beachball?
- Doc site
- VR Tests? - Screener
