Upgrading the ORIC element
Upgrading the ORIC element
Hand-written, next to the generated reference. The generator keeps this file and does not check it. Newest first.
1.2.0 to 1.2.1
This patch preserves the service error when its retry wait cannot fit the request deadline. A rate-limit response with a 60-second Retry-After and the default 10-second deadline now reports FAIR_USE_CEILING instead of TIMEOUT. No retry is sent early.
Update the exact script URL and integrity together:
<script
src="https://cdn.comms.id/oric/1.2.1.js"
integrity="sha384-edKu47AjDk/VBQl3jkhN3RXlYS0CST1yzVH32LNMcZmsAxQCbc3dJ5WzF9kkGkS6"
crossorigin="anonymous"
></script>
The bundle is 39,483 bytes (11,181 bytes gzipped). Attributes, events and theme defaults are unchanged. Earlier exact-version files remain available with their original bytes; the major alias takes this patch when the CDN is deployed.
1.1.0 to 1.2.0
The element now uses the shared Comms.ID theme for default colours, borders, focus and corner radius. It inherits light/dark tokens when the host imports @comms-id/theme/tokens.css; without that stylesheet it uses the light defaults. Existing --comms-id-* overrides and ::part() styles keep priority. Fonts still inherit from the host page.
The public attributes, events, requests and shadow isolation are unchanged. Review the new default appearance before updating a version-pinned script. The major alias https://cdn.comms.id/oric/v1.js takes this release when the CDN is deployed; older exact-version files stay unchanged.
<script
src="https://cdn.comms.id/oric/1.2.0.js"
integrity="sha384-AHmBxVYCQDXqnwMxxte20TLMYMgReirt0VC4hdhBLGyHjJuH0ye28LuGcFvSCT26"
crossorigin="anonymous"
></script>
The new file is 39,415 bytes (11,105 bytes gzipped, below the 15,000-byte limit). The element remains a CDN asset; the theme dependency is bundled into it, so a plain script install needs no npm step.
1.0.0 to 1.1.0
In one line
Change the script’s version and its integrity hash. Nothing else on your page changes.
What changed
- A lookup answer may carry
identifierState(platform #576):{ value, state, since?, successors? }, present only when the source establishes it. ORIC deregistration establishes it:current, orretiredwith the deregistration date. The element passes the answer through unchanged, so the field appears in the answer your page already reads; it shows nothing new. - Nothing else changed. The attributes, events, properties, parts, custom properties and content security policy needs are the same as in 1.0.0. The size is 36,871 bytes (1.0.0: 36,380).
- URLs.
https://cdn.comms.id/oric/1.1.0.jsis new. The major aliashttps://cdn.comms.id/oric/v1.jsfollows it once the CDN is deployed.1.0.0.jsstays served and unchanged; it already accepts answers that carry the new field.
Script tag
Before (1.0.0):
<script
src="https://cdn.comms.id/oric/1.0.0.js"
integrity="sha384-y9CFsFiT1zdEhxWqw+F/4csKr7Y0RgEKqAmxAvflNQAs5kg1DN6GrF4d1JTf5OJq"
crossorigin="anonymous"
></script>
After (1.1.0):
<script
src="https://cdn.comms.id/oric/1.1.0.js"
integrity="sha384-NnQCnqs/dbekRDOYjqdel3bSpnx/OBlJOjbER3IlXdQw0fBdTzJSzbbwCaXbjXoM"
crossorigin="anonymous"
></script>
npm
No npm change is needed for the element: it is served from the CDN only. The typed client @comms-id/oric carries identifierState from 0.5.0.
0.1.0 to 1.0.0
In one line
Change the script’s version and its integrity hash. Nothing else on your page changes.
What changed
- One behaviour you can see: the element waits 400 ms after the last key before it asks for suggestions (it was 200 ms). The old wait was shorter than the usual gap between keys, so a person who types at an ordinary speed sent a request after almost every key, and every
suggestrequest counts against the fair-use ceiling (150 requests a product a day to start). With the new wait the same person sends onesuggestrequest for a pause, not one for each key. To keep the old wait, adddebounce="200"to the element. - Nothing else changed. The two files differ in one character, the default wait (200 became 400 in the bundled controller). The attributes (the
debounceattribute still overrides the default), events, properties, parts, custom properties and content security policy needs are the same as in 0.1.0. 1.0.0 is the launch release; the 0.x releases were prereleases. The size is the same (36,380 bytes; gzipped 10,307 to 10,309 of the 15,000 allowed). - New URLs.
https://cdn.comms.id/oric/1.0.0.jsis new, and so is the major aliashttps://cdn.comms.id/oric/v1.js, which follows the newest 1.x release (1.0.0 now). The aliashttps://cdn.comms.id/oric/v0.jsis not changed by this release and keeps serving 0.1.0.
Script tag
Before (0.1.0):
<script
src="https://cdn.comms.id/oric/0.1.0.js"
integrity="sha384-qzB5Y7/VMHqNmGq2S6Xm3fx48OSGP5R30RMBFqFabAXU7N/0TtodggEtas/8IpK9"
crossorigin="anonymous"
></script>
After (1.0.0):
<script
src="https://cdn.comms.id/oric/1.0.0.js"
integrity="sha384-y9CFsFiT1zdEhxWqw+F/4csKr7Y0RgEKqAmxAvflNQAs5kg1DN6GrF4d1JTf5OJq"
crossorigin="anonymous"
></script>
If you use the major alias https://cdn.comms.id/oric/v0.js, change it to https://cdn.comms.id/oric/v1.js to take 1.0.0. The alias cannot carry an integrity hash, because its bytes change with each release. 0.1.0.js stays served and unchanged, so a page that is not upgraded keeps working as before.
npm
No npm change is needed for the element: @comms-id/oric-element is not published to npm, the element is served from the CDN only. The default wait comes from the controller, so the npm packages that run it get the same default in their next minor release: @comms-id/oric (0.3.0 now, then 0.4.0) and, as a patch, @comms-id/oric-react (0.2.0 now). The API does not change: only the default of debounceMs (200 became 400); pass debounceMs: 200 to keep the old wait. A range such as ^0.3.0 stays on 0.3.x for a 0.x package, so to take the new default change the range to ^0.4.0.
Check a release yourself
The CDN manifest lists every released version with the hash of its exact bytes:
curl -s https://cdn.comms.id/manifest.json
curl -s https://cdn.comms.id/oric/1.1.0.js | openssl dgst -sha384 -binary | openssl base64 -A
The second command, for the version you are moving to, must print the hash in that version’s script tag above (for 1.1.0: NnQCnqs/dbekRDOYjqdel3bSpnx/OBlJOjbER3IlXdQw0fBdTzJSzbbwCaXbjXoM). A released file never changes, so a page that has not been upgraded keeps working.
After the change, the element must still be defined and answer: open the page and use the field, and the element works as before. A wrong hash blocks the script; the browser console names the integrity failure.