SSR tabs are not reused on client

[mskec]

Bug report

• Package version(s): 1.4.0
• Browser and OS versions: Chrome 54.0.2840.98, OSX 10.11.6

Steps to reproduce

I don't have clean repo to provide with example, but sample usage example for tabs with SSR enabled project will be enough to reproduce the problem.

Actual behavior

I am getting this warning when rendering Sample Usage example.

Warning: React attempted to reuse markup in a container but the checksum was invalid. This generally means that you are using server rendering and the markup generated on the server was not what the client was expecting. React injected new markup to compensate which works but you have lost many of the benefits of server rendering. Instead, figure out why the markup being generated is different on the client or server:
 (client) trols="pt-tab-panel-0" aria-disabled="fa
 (server) trols="pt-tab-panel-20" aria-disabled="f

Every time I reload page, server rendered tabs get ID that is increasing.
I think the problem is in the way IDs are generated here. Module scoped variable is used to count tabs which gets initialized on 1st import and keeps increasing on each server render.

Expected behavior

Expected behavior would be that tabs are rendered in isolation and markup is reused on client.

[adidahiya]

Fair point; the code you pointed out is a lazy implementation of tab IDs. We should probably use something like the uuid module.

[giladgray]

Wow this is a nasty problem that has not been solved in the React ecosystem. See facebook/react#4000 and facebook/react#5867 for more context.

I think required ids are going to be our best friends here, although it pushes the uniqueness problem to the consumer. In my new Tabs API, each Tab will require a (locally) unique id and we'll use activeTabId instead of the current index approach. If we simply require a "unique" id on the Tabs parent then we should have enough information to generate unique IDs that are consistent on both server and client.

Example:

<Tabs id="tabs1" activeTabId="pear">
    <Tab id="apple" text="Apple" />    // #__tab-tabs1-apple
    <Tab id="banana" text="Banana" />  // #__tab-tabs1-banana
    <Tab id="pear" text="Pear" />      // #__tab-tabs1-pear
</Tabs>
<Tabs id="tabs2" activeTabId="apple">
    <Tab id="apple" text="Apple" />    // #__tab-tabs2-apple
    <Tab id="banana" text="Banana" />  // #__tab-tabs2-banana
    <Tab id="pear" text="Pear" />      // #__tab-tabs2-pear
</Tabs>

I hypothesize that folks won't use many Tabs in a single application so managing this should not be fairly painless for consumers.

[adidahiya]

@giladgray I agree with your assessment. Users are probably already supplying unique key prop values as well