@reach/auto-id - npm Package Compare versions

Comparing version 0.6.1 to 0.7.0

es/index.js

		@@ -40,5 +40,15 @@ /*
		*
		* After the render, we patch up the components with an incremented ID. It
		* doesn't have to be incremented, though; we could do something random, but
		* incrementing a number is probably the cheapest thing we can do.
		* After the render, we patch up the components with an incremented ID. This
		* causes a double render on any components with `useId`. Shouldn't be a problem
		* since the components using this hook should be small, and we're only updating
		* the ID attribute on the DOM, nothing big is happening.
		*
		* It doesn't have to be an incremented number, though--we could do generate
		* random strings instead, but incrementing a number is probably the cheapest
		* thing we can do.
		*
		* Additionally, we only do this patchup on the very first client render ever.
		* Any calls to `useId` that happen dynamically in the client will be
		* populated immediately with a value. So, we only get the double render after
		* server hydration and never again, SO BACK OFF ALRIGHT?
		*/
		@@ -45,0 +55,0 @@ import { useState, useEffect, useLayoutEffect } from "react";

index.js

		@@ -47,5 +47,15 @@ "use strict";
		*
		* After the render, we patch up the components with an incremented ID. It
		* doesn't have to be incremented, though; we could do something random, but
		* incrementing a number is probably the cheapest thing we can do.
		* After the render, we patch up the components with an incremented ID. This
		* causes a double render on any components with `useId`. Shouldn't be a problem
		* since the components using this hook should be small, and we're only updating
		* the ID attribute on the DOM, nothing big is happening.
		*
		* It doesn't have to be an incremented number, though--we could do generate
		* random strings instead, but incrementing a number is probably the cheapest
		* thing we can do.
		*
		* Additionally, we only do this patchup on the very first client render ever.
		* Any calls to `useId` that happen dynamically in the client will be
		* populated immediately with a value. So, we only get the double render after
		* server hydration and never again, SO BACK OFF ALRIGHT?
		*/
		@@ -52,0 +62,0 @@ var serverHandoffComplete = false;

package.json

		{
		"name": "@reach/auto-id",
		"version": "0.6.1",
		"version": "0.7.0",
		"description": "Autogenerate IDs to facilitate WAI-ARIA and server rendering.",
		"repository": {
		"type": "git",
		"url": "git+https://github.com/reach/reach-ui.git",
		"directory": "packages/auto-id"
		},
		"main": "index.js",
		@@ -23,3 +28,3 @@ "module": "es/index.js",
		],
		"gitHead": "c1e249448a3672ccc65698218f0f38ef9814ab90"
		"gitHead": "c6c10662e6eaf229594e4d6e6a38d8c9baa35ffa"
		}

src/index.js

		@@ -40,5 +40,15 @@ /*
		*
		* After the render, we patch up the components with an incremented ID. It
		* doesn't have to be incremented, though; we could do something random, but
		* incrementing a number is probably the cheapest thing we can do.
		* After the render, we patch up the components with an incremented ID. This
		* causes a double render on any components with `useId`. Shouldn't be a problem
		* since the components using this hook should be small, and we're only updating
		* the ID attribute on the DOM, nothing big is happening.
		*
		* It doesn't have to be an incremented number, though--we could do generate
		* random strings instead, but incrementing a number is probably the cheapest
		* thing we can do.
		*
		* Additionally, we only do this patchup on the very first client render ever.
		* Any calls to `useId` that happen dynamically in the client will be
		* populated immediately with a value. So, we only get the double render after
		* server hydration and never again, SO BACK OFF ALRIGHT?
		*/
		@@ -45,0 +55,0 @@

New alerts