---
# System prepended metadata

title: Function component conversions
tags: [pitch]

---

---
robots: noindex, nofollow
tags: pitch
---
<!-- For instructions on shaping a project see here: [Shaping a Project](/kX02SXVbS6KzMOQd56i6Cg) -->

# Function component conversions

### Problem

Most v7 components are class components, which have some disadvantages and are not the currently recommended pattern. 

We want to convert a substantial portion of our existing v7 components to function components for v8, and some of this work has been started. However, it lacks clear direction, and people have had trouble getting traction on conversion PRs (which are difficult and time-consuming to review). There have also been some other process-related issues reducing effectiveness and efficiency of the work.

### Appetite

3-4 weeks

### Solution

The solution for this month will focus primarily on defining future work, refining processes, and ensuring PRs move forward. Actual component conversions will be a secondary priority as time allows.

- Determine final prioritized list of components to convert or not for version 8.
  - Ensure [github project](https://github.com/microsoft/fluentui/projects/35) is complete and stays up to date
  - Include risk assessment and current test coverage level
  - Could consider partner priority components
- Drive status and make sure nothing is stuck, we agree on what's next, and people are not working at cross purposes.
- Help review incoming PRs, or if an area expert is needed bring them into the review. 
- Identify improvements in the process. Some possibilities:
  - Develop clear guidance for what types of breaking changes are/aren't allowed, and how to document them.
  - Use screen share for large code reviews, to talk through the reviewer's intent and where different pieces of code moved to
  - Develop clear guidance for how to ensure changes are validated.
  - How to ensure v7 fixes are also included in v8
- Identify patterns across reviews and conversions to identify opportunities for shared code or other improvements in the code. Some possibilities:
  - Add hooks providing previous props/state access like `componentWillReceiveProps` and `componentDidUpdate` did (only to be used as an escape hatch/last resort in case we have trouble replicating the existing behavior with standard hooks patterns and decide we must preserve it)
  - Document how to test with hooks (`act` issues) -- talk to Michael about what he's found so far?
- Probably: work on one or more actual conversions, starting with TextField
- Set up sync with Levi and Justin about plan for improving test coverage

### Risks (Rabbit holes)

- We could get stuck in discussion regarding any of the decision points
- I can easily get stuck on decisions trying to find the absolute "best" alternative -- need to bias towards getting input from others earlier
- Feature creep during project review :)
- Breaking components due to lack of test coverage

### Out of scope (No-gos)

- Convert all components this month
- Any work on experiments or charting (though we can provide guidance if the component owners are interested)