---
robots: noindex, nofollow
tags: pitch
---
# Applying FocusZone contentious changes to lean versions closer together
### Problem

We have two versions of the `FocusZone` component after merging, one for version 0 and one for version 7 of our library. A developer onboarding to use our library will be confused as to which version to use if we continue having two versions.

### Appetite

We'd want to spend 2 weeks working in this project with a potential extra week at the beginning to start figuring out decisions that need to be done. There have already been significant strides in writing less contentious changes to both `FocusZone` versions to bring them closer together so there's been precedence to similar changes being made.

### Solution

We need one version that works for all the scenarios to avoid the confusion of having two versions of a component serving very similar objectives. However, the two versions have some differences that need to be ported to the other version before this work can be done.

What we're missing are potentially contentious changes based on what is different between both `FocusZones` to bring them to parity. This set of changes includes:

1. Merging props that exist in both versions of the `FocusZone` but have different names in each version. This would be done by deprecating the old prop and adding the new one while maintaining backwards compatibility.
* `onBeforeFocus` vs `shouldReceiveFocus`
* `isInnerZoneKeyStroke` vs `shouldEnterInnerZone`
* `doNotAllowFocusEventToPropagate` vs `stopFocusPropagation`
* `IPoint's` `x` and `y` vs `Point's` `left` and `top`
* `onFocusNotification` vs `onFocus`
2. Bringing version specific props and methods to the other version.
* From v0 to v7:
* `restoreFocusFromRoot`
* `focusLast`
* `defaultTabbableElement`
* `preventDefaultWhenHandled`
* `shouldFocusOnMount`
* `shouldFocusInnerElementWhenReceivedFocus`
* `shouldResetActiveElementWhenTabFromZone`
* From v7 to v0:
* `defaultActiveElement`
* `allowFocusRoot`

### Risks (Rabbit holes)

There are some potential risks that need to be taken into consideration in order for the project to succeed:

1. There needs to be time allocated to figuring out decisions: Since these are contentious changes there is sure to be some discussion about how to approach bringing the two versions closer together. Time needs to be allocated for these discussions to take place.
- This should be mitigated by allocating a week for decision-making.
2. Reliance on people reviewing PRs: These changes need to be reviewed by people that usually have huge workloads and might not have a lot of time to review PRs, or even take a look, at PRs.
- The list of people include, but might not be limited to a subset of: David, Levi, Shift and Juraj.

### Out of scope (No-gos)

There is one contentious change that we need to leave out of scope, which is the underlying RTL mechanisms, which are different across both versions. Since these mechanisms are tied to the theme and the provider it will be impossible for us to make this change until we have that part of our story figured out.

Because of this, it will also be impossible for us to merge both versions of `FocusZone` into one, be it in the current package or in the `@next` version.

Both of these issues are left for later after we have these dependencies resolved.