Strict mode compliance (function component conversions part 2)

--- robots: noindex, nofollow tags: pitch ---  # Strict mode compliance (function component conversions part 2) (Previous related project: [Function component conversions](/ydwqgpavTPqOpqA3QAq_Rw?both)) ### Problem One of our goals for version 8 is [React.StrictMode](https://reactjs.org/docs/strict-mode.html) compliance, so that our consumers can start testing with [concurrent mode](https://reactjs.org/docs/concurrent-mode-intro.html) and adopt it quickly when it releases. As documented on the github project (https://github.com/microsoft/fluentui/projects/35), there are a few remaining components which have specific issues making them non-compliant with strict mode: `UNSAFE_` methods, `findDOMNode` usage, or string ref usage. ### Appetite 3-4 weeks ### Solution We'd previously started working on [function component conversions](/ydwqgpavTPqOpqA3QAq_Rw?both), but there are a lot of components left, and many of the remaining ones are complex. In the interest of time, to meet our goal of releasing version 8 soon, we're going to re-focus specifically on doing *only* the function component conversions or in-place fixes needed to unblock strict mode (and put other conversions on hold). While we do want to move away from classes long-term, their very presence doesn't block strict mode and therefore doesn't need to block this release. We may also consider *not* converting some of the components with problems for now, and just fixing the strict mode issues in the class component instead. I'll be directing this project and help as time allows, but most of the work will be done by Michael, Caleb, and Jon. Major groups of components/work: - Lists: Together the list components contain *all* the possible invalid patterns. Due to the complexity and risk of regressing partners (mainly ODSP), we don't plan to convert these ones to function components. Even converting in place, we'll need to get help from component owners in reviewing and validating the changes. - Pickers: These currently rely on class inheritance, so converting to function components would require a major architectural change. We also have experimental versions of most of the pickers. Jon will work on figuring out a short- and long-term plan here, and probably help implement the short-term changes (or hand off to someone else if needed). - Dropdown/ComboBox plus Autofill - Various utilities using `findDOMNode` in ways that won't work with function components (and cause warnings in strict mode) - Assorted other components We also need an easy way to test components in strict mode, which I've already started here: https://github.com/microsoft/fluentui/pull/14327 ### Risks (Rabbit holes) - The major risk is taking too long and/or regressing behavior. As mentioned above, we're addressing this mainly by scaling back which components we're working on and potentially doing some fixes in-place. - As mentioned above, there's serious regression risk with the list components. We need to mitigate this by having the component owners help review and test any changes, both in PR and in their apps. ### Out of scope (No-gos) - Trying to convert all class components to function components this month - Fixing any strict mode issues in experiments or charting (these must be addressed by component owners if/when it becomes important to them)