![Screenshot 2019-12-16 10 51 05](https://user-images.githubusercontent.com/793565/70934095-fd91ed80-1ff1-11ea-93b5-746e816585ec.png)
There's seems to be circumstances where unmounted DOM/Fibers are kept alive by React DevTools. They're kept alive in `primaryFibers`:
https://github.com/facebook/react/blob/34527063083195558f98108cde10b5d6ad0d6865/packages/react-devtools-shared/src/backend/renderer.js#L772

It seems like a WeakSet would be appropriate and would remove the leak. Otherwise we'd need to understand why recordUnmount isn't called.

CC @bvaughn  
case PROVIDER_NUMBER:
          case PROVIDER_SYMBOL_STRING:
            return ElementTypeContext;
          case CONTEXT_NUMBER:
          case CONTEXT_SYMBOL_STRING:
            return ElementTypeContext;
          case STRICT_MODE_NUMBER:
          case STRICT_MODE_SYMBOL_STRING:
            return ElementTypeOtherOrUnknown;
          case PROFILER_NUMBER:
          case PROFILER_SYMBOL_STRING:
            return ElementTypeProfiler;
          default:
            return ElementTypeOtherOrUnknown;
        }
    }
  }
   Map of one or more Fibers in a pair to their unique id number.
   We track both Fibers to support Fast Refresh,
   which may forcefully replace one of the pair as part of hot reloading.
   In that case it's still important to be able to locate the previous ID during subsequent renders.
  const fiberToIDMap: Map<Fiber, number> = new Map();
   Map of id to one (arbitrary) Fiber in a pair.
   This Map is used to e.g. get the display name for a Fiber or schedule an update,
   operations that should be the same whether the current and work-in-progress Fiber is used.
  const idToArbitraryFiberMap: Map<number, Fiber> = new Map();
   When profiling is supported, we store the latest tree base durations for each Fiber.
   This is so that we can quickly capture a snapshot of those values if profiling starts.
   If we didn't store these values, we'd have to crawl the tree when profiling started,
   and use a slow path to find each of the current Fibers.