Nested `SSRProvider`s don't guarantee unique IDs

[jfuchs]

🐛 Bug Report

Given this tree of SSR providers (cribbing from SSRProvider.test.js):

<SSRProvider>
  <SSRProvider>
    <Test />
    <SSRProvider>
      <Test />
    </SSRProvider>
  </SSRProvider>
  <SSRProvider>
    <Test />
  </SSRProvider>
</SSRProvider>

Each <Test>, when calling useId, should get a unique ID, but two of those tests do not.

🤔 Expected Behavior

I don't have a preference for what the IDs are so long as they are unique and namespaced and deterministic.

😯 Current Behavior

Here's a snapshot test showing the current behavior:

it("it should generate consistent unique ids with nested SSR providers", function () {
  let tree = render(
    <SSRProvider>
      <SSRProvider>
        <Test />
        <SSRProvider>
          <Test />
        </SSRProvider>
      </SSRProvider>
      <SSRProvider>
        <Test />
      </SSRProvider>
    </SSRProvider>
  );

  let divs = tree.getAllByTestId("test");
  expect(divs).toMatchInlineSnapshot(`
    Array [
      <div
        data-testid="test"
        id="react-aria-1-1"
      />,
      <div
        data-testid="test"
        id="react-aria-2-1"
      />,
      <div
        data-testid="test"
        id="react-aria-2-1"
      />,
    ]
  `);
});

💁 Possible Solution

I believe a possible fix would be making each ID essentially a path through the tree of SSRProviders, so that for the above example, the IDs would be:

react-aria-1-1
react-aria-1-1-1
react-aria-1-2

🔦 Context

I stumbled into this looking at different implementations for SSR-stable unique ID generation in react.

💻 Code Sample

See the current behavior above

🌍 Your Environment

I was running tests on main as of 2021 Aug 12 (v3.0.3 of @react-aria/ssr)

[ansavchenco]

I ran the forementioned test on the latests main and it failed.

// Provided tree
<SSRProvider>
  <Test />
  <SSRProvider>
    <Test />
    <SSRProvider>
      <Test />
    </SSRProvider>
  </SSRProvider>
  <Test />
  <SSRProvider>
    <Test />
  </SSRProvider>
</SSRProvider>

// Expected
[
  "react-aria-1",
  "react-aria-2-1",
  "react-aria-2-2-1",
  "react-aria-3",
  "react-aria-4-1",
]

// Actual
[
  'react-aria-1',
  'react-aria-1-1',
  'react-aria-1-1-1',
  'react-aria-2',
  'react-aria-2-1'
]

Can you please tell what behaviour is expected so that I can come up with a PR that fixes either the test or the behaviour? To me it seems that the actual behaviour is alright since all ids are unique. Also the logic behind generation in the actual result can be inferred just by looking and the code sample. In the expected result it's not clear why the first prefix is incremented in the second id but not incremented in the third id.