¿Qué es la API de Cookie Store?
La API de Cookie Store expone las cookies HTTP a los service workers y
ofrece una alternativa asíncrona a document.cookie
. La API hace que sea
más fácil de:
- Evita bloqueos en el subproceso principal accediendo a las cookies de forma asíncrona.
- Evita sondear cookies, ya que se pueden observar cambios en ellas.
- Accede a las cookies desde los service workers.
Estado actual
Paso | Estado |
---|---|
1. Crear explicación | Completo |
2. Crea el borrador inicial de la especificación | Completo |
**3. Recopila comentarios y Iterar según la especificación** | **En curso** |
4. Prueba de origen | Pausada |
5. Lanzamiento | Sin iniciar |
¿Cómo utilizo el almacén de cookies asíncronas?
Habilita la prueba de origen
Para probarlo de manera local, puedes habilitar la API en la línea de comandos:
chrome --enable-blink-features=CookieStore
Pasar esta marca en la línea de comandos habilita la API globalmente en Chrome para la sesión actual.
Como alternativa, puedes habilitar #enable-experimental-web-platform-features
marca en chrome://flags
.
Probablemente no necesites cookies
Antes de pasar a la nueva API, me gustaría indicar que las cookies siguen siendo el peor primitiva de almacenamiento del lado del cliente de la plataforma y debería usarse como último recurso. Esto no es un accidente: las cookies fueron la primera opción del cliente de la Web. mecanismo de almacenamiento de datos. Hemos aprendido mucho desde entonces.
Los motivos principales para evitar las cookies son los siguientes:
Las cookies llevan el esquema de almacenamiento a tu API de backend. Cada solicitud HTTP lleva una instantánea del archivo jar de cookies. Esto hace que sea fácil para para que los ingenieros de backend introduzcan dependencias en el formato actual de las cookies. Una vez esto sucede, tu frontend no puede cambiar su esquema de almacenamiento sin implementar un cambio coincidente en el backend.
Las cookies tienen un modelo de seguridad complejo. Las funciones de la plataforma web moderna siguen la misma política de origen, lo que significa que cada aplicación tiene su propia zona de pruebas y es completamente independiente de otras aplicaciones que el usuario pueda estar ejecutando. Permisos de cookies de crear una historia de seguridad mucho más compleja y simplemente intentar que duplicaría el tamaño de este artículo.
Las cookies tienen costos de alto rendimiento. Los navegadores deben incluir una instantánea de sus cookies en cada solicitud HTTP, por lo que cada cambio en las cookies se debe propagado en las pilas de almacenamiento y red. Los navegadores modernos tienen un de almacenamiento de cookies optimizadas, pero nunca podremos cookies tan eficientes como los otros mecanismos de almacenamiento, que no necesitan hablar a la pila de red.
Por todos los motivos anteriores, las aplicaciones web modernas deben evitar las cookies y almacena un identificador de sesión en IndexedDB y agrega de forma explícita el identificador al encabezado o al cuerpo de las solicitudes HTTP específicas a través de la API de fetch.
Dicho esto, sigues leyendo este artículo porque tienes una buena motivo para usar cookies...
Leer una cookie y eliminar los bloqueos
El venerable
document.cookie
La API es una fuente de bloqueo bastante garantizada para tu aplicación. Por ejemplo:
cada vez que usas el método get document.cookie
, el navegador debe dejar de ejecutarse
JavaScript hasta que tenga la información de la cookie que solicitaste. Esto puede tardar
salto de proceso o lectura de disco, y hará que se bloquee la IU.
Una solución sencilla para este problema es cambiar de document.cookie
get a la API asíncrona de Cookie Store.
await cookieStore.get('session_id');
// {
// domain: "example.com",
// expires: 1593745721000,
// name: "session_id",
// path: "/",
// sameSite: "unrestricted",
// secure: true,
// value: "yxlgco2xtqb.ly25tv3tkb8"
// }
El método set document.cookie
se puede reemplazar de manera similar. Recuerda
que solo se garantiza que el cambio se aplique después de la promesa devuelta por
Se resuelve cookieStore.set
.
await cookieStore.set({name: 'opt_out', value: '1'});
// undefined
Observar, no sondear
Una aplicación popular para acceder a cookies desde JavaScript detecta cuándo
el usuario sale de su cuenta y actualiza la IU. Actualmente, esto se hace mediante sondeo
document.cookie
, que genera bloqueos y tiene un impacto negativo en la batería
la vida.
La API de Cookie Store ofrece un método alternativo para observar las cookies cambios, lo que no requiere sondeo.
cookieStore.addEventListener('change', event => {
for (const cookie of event.changed) {
if (cookie.name === 'session_id') sessionCookieChanged(cookie.value);
}
for (const cookie of event.deleted) {
if (cookie.name === 'session_id') sessionCookieChanged(null);
}
});
Da la bienvenida a los service workers
Debido al diseño síncrono, no se creó la API de document.cookie
.
disponibles para
service workers.
La API de Cookie Store es asíncrona, por lo que está permitida en servicio
trabajadores.
La interacción con las cookies funciona del mismo modo en contextos de documentos y en service workers.
// Works in documents and service workers.
async function logOut() {
await cookieStore.delete('session_id');
}
Sin embargo, observar los cambios de las cookies es un poco diferente en los service workers. Despertarse un service worker puede ser bastante costoso, así que tenemos que describir explícitamente los cambios de las cookies que le interesan al trabajador.
En el siguiente ejemplo, una aplicación que usa IndexedDB para almacenar en caché los datos del usuario supervisa los cambios en la cookie de sesión y descarta los datos almacenados en caché cuando la el usuario sale de su cuenta.
// Specify the cookie changes we're interested in during the install event.
self.addEventListener('install', event => {
event.waitUntil(cookieStore.subscribeToChanges([{name: 'session_id'}]));
});
// Delete cached data when the user logs out.
self.addEventListener('cookiechange', event => {
for (const cookie of event.deleted) {
if (cookie.name === 'session_id') {
indexedDB.deleteDatabase('user_cache');
break;
}
}
});
Prácticas recomendadas
Próximamente.
Comentarios
Si pruebas esta API, envíanos tus comentarios. Dirige
comentarios sobre la forma de la API
repositorio de especificaciones,
e informar los errores de implementación al
Blink>Storage>CookiesAPI
Componente de parpadeo.
Nos interesa, en especial, aprender sobre las mediciones del rendimiento y el uso más allá de los descritos en la explicación.
Recursos adicionales
- Explicación pública
- Especificación
- Seguimiento de errores
- Entrada de chromestatus.com
- Conversación sobre el discurso de WCG
- Componente de parpadeo:
Blink>Storage>CookiesAPI