---
# System prepended metadata

title: 'FluentUI Web AOLs: Sprint 43 (Feb 10 - Feb 23)'
tags: [status]

---

---
tags: status
---
# FluentUI Web AOLs: Sprint 43 (Feb 10 - Feb 23)

As we're moving into rhythm of sprints to organize work, we'll reset these AOL mails now to be on a biweekly basis.

Much of the web team has been focused on the workstreams below with a heavy focus on unifying repos. 

## Quick links

[Sprint 43: Feb 10 - Feb 21, 2020][sprint43]

[Full VSO backlog][backlog]

[Shared OneNote for eng process][onenote]

### Achievements ([Sprint 42][sprint42])

See something missing? Please add it in the next update.

#### [One library][onelib]

* Last week we established some initial work items to move closer towards one library:
	* FocusZone to move to react-focus
	* Goal to have one shared package for focus things
	* Used as an exercise to vet out other discrepencies we can add to backlog
* We discovered a number of other differences in utilities which we added to ["Converge utilities" backlog feature](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/5376).
	* Align native eventing
	* Align what-input
	* Align positioning logic
	* Assess if we really need lodash

#### [One repo][onerepo]

* Merged an initial PR of the v0 code into the repo, builds!
* Upgrade of TypeScript 3.7.
* Still more work to do in terms of publishing, inner loop, CI.

#### [Theming][theming] & [Composition][composition]

* Discussion from JD/Marija/Shift on theme bundle size, icon bundle size
* Shift with RFC PR to propose ideas on addressing icons in theme: https://github.com/microsoft/fluent-ui-react/pull/2320

#### [Performance][performance]

* Partner investigations:
	* Office.com looking at max bundle size 170k
		* Asked for trimmed down Card
	* ODSP looking at 150ms startup time
		* Asked for trimmed down Button and Card
	* Office Shared comments team asked for optimizations in `Persona` and `FocusTrapZone`
* Discussion around using pure CSS, as CSSinJS is the primary bottleneck we are responsible for, contributing to slow web apps.
* Dissection of bundle size in v0 code led to some observations that lodash isn't tree shaking well, added work items to evaluate alternatives.
* EventGroup and BaseComponent in v7 are contributing to large bundle size as well - Aneesha tasked with removing all instances and normalizing on Shift's EventListener package.

#### [Shield][issues]

* Triaged and fixed new issues as they came in.
* Re-triaged and tried to close backlogged issues that no longer were applicable (went from ~500 to ~450 issues in the past 2 weeks).
* Worked with Anita’s team and Paul on accessibility bug triaging workflow. Shared out small set of existing bugs to a11y testers to experiment getting impact assessment from them.
* Clarified ownership with ODSP over List components and made decision on triaging plan towards List components. Requested ODSP team to help with List accessibility bug fixing.
* Started getting rid of non-breaking deprecated stuff in the repository. 

#### [Fabric Bot Services](https://fabric-cp.azurewebsites.net)

* Did a new release of Fabric Bot, which includes new features like "inline special values", and massive perf improvements. Received positive feedback from partners including many partners which immediately started utilizing the new features.
* Continue to plough away at the Scheduled-search rate limiting problem - we've taken a two-pronged approached here:
  - Implementing cluster-based two-lane throttling as a custom octokit plugin
      - This is a very complex approach that is hard to simulate/re-produce and test on dev enlistments, and so requires an iterative approach where we deploy, monitor, observe and continue to tweak.
      - Some snafus we hit that we're on the process of refining/iterating include that a rate limit sliding window begins AFTER a request is fulfilled by GitHub, but the very nature of throttling means the throttle window begins BEFORE you send the request (because it is the sending of the request that is being throttled). This is usually not a problem if the request is fulfilled nearly instantly (e.g. up to a few hundred ms), but falls apart when due to entrophy, a request takes 10s to complete its roundtrip instead.
  - Having Scheduled Search capability and our bot config templates run somewhat less frequently and be staggered by default. (i.e. instead of "run every hour", the options we now expose are Run 8/6/4/3/2 times a day, where the bot takes care of staggering the runs to spread out the load by default. Users can still go into advance config using our custom clock UI to have a task run every hour if they so desire).
* Implemented the changes to support Scheduled Search staggering - also went to convert the hundreds of  existing Scheduled Search configuration to conform to the new automatic staggering scheme (tasks that were running every hour now runs every 3 hours instead, by default).
* Based on feedback provided by Xu and Elizabeth about false-positives, made email-cleanser capability be more reliable by doing an additional GraphQL check to double confirm with GitHub that the issue comment was indeed made by e-mail (after our cheaper, heuristics based approach).
* Converted our Release Announcement capability to make use of the same inline special value architecture both on backend and on the front-end UI (i.e. release announcement inline special values has now gained "Intellisense" support)
* Fabric Bot Shield
  - Continue to support partner escalations, onboarding requests, etc.
  - Notable incidents:
    - Addressed issue with Office UI Fabric React bot config where we were incorrectly closing "Needs: Attention" issue that no one on the team looked at. 
      - This is not a bug with the bot but a poorly implemented bot rule by some team members who have access to modify the bot rules. 
      - Along the way, we also improved the original rule such that it directly @mention the people to whom the issue is assigned to.
    - Discovered that Azure had onboarded one of their repos incorrectly (Azure/azure-rest-api-specs was incorrectly onboarded by them as Azure/azure-api-rest-specs). Worked with the relevant owners in Azure to deal with this.
        - Although the affected team did send us e-mail asking about why the bot was not functioning in their repo a few days later, we discovered this issue first after an SMS alert that we had set up to detect higher than normal memory usage triggered. 
        - What happened was that because of the incorrect repo onboarding, our deadlock detection service (BeeKeeper) failed to detect and release a deadlock from the real repo on GitHub (BeeKeeper scans for deadlocks based on the repos it knows about).
        - Discovered as well in the process of working on this incident that we never updated the tenantadmin APIs that handle tenant renames to work with our new DB layout that Brian did as a backend perf work in December. Did the work to update the APIs first (although not without hitting more quirks with Azure Cosmos DB along the way first and having to work around them. Notably, one big stumbling block was that you cannot edit the value of a field that is being used by CosmosDB as a shard key).
    - Discovered that our auto-merge config had used the term statuses and check runs inconsistently and it was confusing the PowerShell team, we deployed a hotfix to address this.
    - Roslyn compiler team escalated an auto-merge failure where after investigation, we realized that GitHub was, for some reason, attributing some small fraction of Azure Devops CI outcome to the msftbot (usually, GitHub attributes these payloads to "ghost"). 
      - This is likely a GitHub bug but it triggered our safety net where we usually ignore events from the bot (to ensure the bot does not get into an infinite loop). 
      - Deployed a hotfix to remove the safety net for this specific case.


New partners who requested to onboard:
- pwa-builder/PWABuilder-cli
- pwa-builder/CloudAPK
- microsoft/accessbility-insights-for-android-service
- microsoft/FluidFramework
- microsoft/Office-Online-Test-Tools-and-Documentation
- microsoft/wopi-validator-core
- microsoftdocs/wsl

### Objectives ([Sprint 43][sprint43])

#### [One library][onelib]

* [5191: Share a single `@fluentui/react-focus` package](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/5191) - If we can get one component shared, that's progress that can be multiplied. (Mak)
    * Package has been published, see demo: https://codesandbox.io/s/serene-pare-n66oo
    * Integrate into v7, remove existing code
    * Determine patch/minor deltas from v0 code and merge into package
    * Stage major deltas in vNext package
    * Integrate into v0, remove existing code

* [5377: Developers have one way to do native eventing](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/5377) - In Fabric we use EventGroup. We will be removing all references in favor of unifying on one of the following solutions:
    * useEventListener
    * EventListener react component
    * native eventing in some cases (with super careful consideration of removing)

* [5425: Components in v0 and v7 should have aligned names](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/5425) - Jon is working through the process of aligning component naming. Process is being established and documented in the OneNote here.


#### [One repo][onerepo]

* Jason will visit Prague for 2 weeks (won't see him in Redmond until March, sad face 😢).
* An import script has been developed to take in FUI code at will into the Fabric repo (it is in preparation for a future cut off move; these are trial moves as we work thru issues)
* `gulp docs` now works on the FUI docs inside Fabric repo (R/O for now)
* A new `yarn start` experience has landed inside Fabric to allow devs to start the innerloop for a chosen project
* Work is under way to port over FUI CI process
    * current challenge: the feature branch to forked branch contribution model 
    * danger is aaaaaaalmost working
    * next work item: blob storage / perf DB integration
* Work is under way to provide the same `yarn relase:minor` capability from FUI (probably thru a set of prepublish script and a specific FUI release build job)

#### [Theming][theming] & [Composition][composition]

* [4565: Consumers should have a single provider that can be used in Fabric and FluentConsumers should have a single provider](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4565) - Marija

#### [Performance]

* No work items specifically targetting performance other than the [normalization of eventing](https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/5377) for now, we should lower bundle sizes in v7.
* Levi and David to start evaluating perf/bundle improvements in going back to raw css with variables for theming, before we commit.

#### [Shield][issues]

* Continue to drive down the total number of open issues by responding to new issues and reviewing older ones.
* Add documentation related to Shield process in Fluent UI Onenote.
* Ensure issue management is not disrupted with repo merge.

#### [Fabric Bot](https://fabric-cp.azurewebsites.net)

* Continue the iterative process to push through and resolve rate limiting issues properly.
* However, primary goal besides Bot Shield is to do work related to bot funding efforts.

### Learnings (Sprint 42)

* We are doing a large dissection of all utilities across v0 and v7 to break up further workitems to unify utilities.
* Teams theme includes all component styles and icons; biggest bundle concern.
* Lodash adds 9k (gzipped) minimum to the bundle even with the babel transforms. Needs investigation.

[backlog]: https://dev.azure.com/microsoftdesign/fluent-ui/_backlogs/backlog/fluent-ui%20Team/Epics
[issues]: https://github.com/OfficeDev/office-ui-fabric-react/issues
[onenote]: https://microsoft.sharepoint-df.com/:o:/t/FluentUIInternal/Ev_x5WbQI6tJmn2s87RzRPMBTG3d0gmYJN6QCpQttOFyzw?e=rnbj9H
[sprint42]: https://dev.azure.com/microsoftdesign/fluent-ui/_sprints/backlog/fluent-ui%20Team/fluent-ui/Sprint%2042
[sprint43]: https://dev.azure.com/microsoftdesign/fluent-ui/_sprints/backlog/fluent-ui%20Team/fluent-ui/Sprint%2043

[onelibrary]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4469
[theming]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4464
[performance]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4462
[composition]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4465
[onerepo]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4468
[onelib]: https://dev.azure.com/microsoftdesign/fluent-ui/_workitems/edit/4469
