IndexedDB 사용 권장사항

널리 사용되는 상태 관리 라이브러리인 IndexedDB 간에 애플리케이션 상태를 동기화하기 위한 권장사항을 알아봅니다.

Philip Walton

사용자가 웹사이트나 애플리케이션을 처음 로드할 때 종종 상당한 양의 작업이 관련되어 있습니다. UI를 렌더링하는 데 사용되는 초기 애플리케이션 상태를 생성합니다. 예를 들어 앱이 사용자 클라이언트 측에서 인증한 다음 여러 API 요청을 해야 페이지에 표시해야 하는 데이터입니다.

애플리케이션 상태 저장 IndexedDB를 사용하면 색인 생성 속도를 높일 수 있습니다. 반복 방문의 로드 시간 그러면 앱이 백그라운드에서 모든 API 서비스와 동기화할 수 있습니다. 새로운 데이터로 UI를 느리게 업데이트할 수 있습니다. stale-while- revalidate 전략입니다.

IndexedDB는 사용자 제작 콘텐츠를 임시 저장소로 저장하는 데에도 유용합니다. 서버에 업로드되기 전이나 원격 데이터의 클라이언트측 캐시로 데이터를 전송할 수 있습니다.

하지만 IndexedDB를 사용할 때는 색인 생성에 적합하지 않을 수 있는 API를 처음 접하는 개발자에게 즉시 드러납니다. 이 도움말에서는 일반적인 질문에 대한 답변과 IndexedDB에 데이터를 유지할 때 유념해야 할 가장 중요한 몇 가지 사항을 설명합니다.

앱의 예측 가능성 유지

IndexedDB와 관련된 많은 복잡성은 검색 시 여러 요소가 존재한다는 사실에서 비롯됩니다. (개발자)가 통제할 수 없습니다. 이 섹션에서는 염두에 두어야 하는 여러 가지 문제를 살펴봅니다. IndexedDB를 사용할 때 이를 고려해야 합니다

일부 플랫폼에서는 모든 항목을 IndexedDB에 저장할 수 없습니다.

이미지나 동영상과 같이 사용자가 생성한 대용량 파일을 저장하는 경우 File 또는 Blob 객체로 전달합니다. 이 방법은 일부 플랫폼에서는 작동하지만 다른 플랫폼에서는 작동하지 않습니다. Safari 사용 특히 iOS는 Blob을 IndexedDB에 저장할 수 없습니다.

다행히 Blob를 ArrayBuffer로 변환하거나 그 반대로 변환하는 것은 그리 어렵지 않습니다. 저장 IndexedDB의 ArrayBuffer는 잘 지원됩니다.

그러나 Blob에는 MIME 유형이 있지만 ArrayBuffer에는 없습니다. 다음 작업을 수행해야 합니다. 변환을 올바르게 실행할 수 있도록 유형을 버퍼와 함께 저장합니다.

ArrayBuffer를 Blob로 변환하려면 Blob 생성자를 사용하면 됩니다.

function arrayBufferToBlob(buffer, type) {
  return new Blob([buffer], { type: type });
}

다른 방향은 약간 더 복잡하며 비동기식 프로세스입니다. FileReader 객체를 사용하여 blob을 ArrayBuffer로 읽습니다. 읽기가 끝나면 loadend 이벤트가 판독기에서 트리거됩니다. 다음과 같이 이 프로세스를 Promise에 래핑할 수 있습니다.

function blobToArrayBuffer(blob) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.addEventListener('loadend', () => {
      resolve(reader.result);
    });
    reader.addEventListener('error', reject);
    reader.readAsArrayBuffer(blob);
  });
}

스토리지에 쓰기가 실패할 수 있음

IndexedDB에 작성할 때 오류는 다양한 이유로 발생할 수 있으며 경우에 따라 개발자가 제어할 수 없는 이유입니다 예를 들어 일부 브라우저는 현재 시크릿 브라우징 모드에서 IndexedDB에 쓰기. 또한 사용자가 디스크 공간이 거의 없는 기기를 사용하고 있을 가능성도 있습니다. 어떤 파일도 저장하지 못하도록 제한합니다.

그렇기 때문에 항상 올바른 오류 처리를 구현하는 것이 IndexedDB 코드. 즉, 일반적으로 애플리케이션 상태를 메모리에 유지하는 것이 좋습니다( 시크릿 브라우징 모드에서 실행하거나 시크릿 브라우징을 할 때 UI가 중단되지 않도록 저장공간이 필요한 다른 앱 기능이 합니다.

error 이벤트에 이벤트 핸들러를 추가하여 IndexedDB 작업에서 오류를 포착할 수 있습니다. IDBDatabase, IDBTransaction 또는 IDBRequest 객체를 만들 때마다 발생합니다.

const request = db.open('example-db', 1);
request.addEventListener('error', (event) => {
  console.log('Request error:', request.error);
};

저장된 데이터가 사용자가 수정했거나 삭제했을 수 있습니다.

무단 액세스를 제한할 수 있는 서버 측 데이터베이스와 달리 클라이언트 측 데이터베이스는 브라우저 확장 프로그램 및 개발자 도구에 액세스할 수 있으며 사용자가 삭제할 수 있습니다.

사용자가 로컬에 저장된 데이터를 수정하는 경우는 드물지만, 사용자는 일반적으로 지웁니다. 애플리케이션에서 오류 없이 이 두 사례를 모두 처리할 수 있어야 합니다.

저장된 데이터가 오래되었을 수 있습니다.

이전 섹션과 마찬가지로 사용자가 데이터를 직접 수정하지 않았더라도 스토리지에 있는 데이터가 이전 버전의 코드로 작성된 것일 수도 있고 버그가 있는 버전을 볼 수 있습니다.

IndexedDB에는 스키마 버전 및 스키마 버전을 위한 IDBOpenDBRequest.onupgradeneeded() 메서드; 하지만 사용자가 직접 처리할 수 있는 방식으로 업그레이드 코드를 작성해야 합니다. 문제가 있을 수 있습니다 (버그가 있는 버전 포함).

단위 테스트는 여기서 매우 유용할 수 있습니다. 가능한 모든 것을 수동으로 테스트하는 것이 불가능한 경우가 많기 때문입니다. 업그레이드 경로 및 케이스

앱 성능 유지

IndexedDB의 주요 기능 중 하나는 비동기 API이지만 사용할 때 성능에 대해 걱정할 필요가 없다고 생각하는 것이 좋습니다. 여러 가지 이유로 부적절한 사용으로 인해 여전히 기본 스레드가 차단되어 버벅거림과 응답이 없을 수 있습니다.

일반적으로 IndexedDB에 대한 읽기 및 쓰기는 데이터에 필요한 크기보다 크지 않아야 합니다. 있습니다

IndexedDB를 사용하면 규모가 큰 중첩된 객체를 단일 레코드로 저장할 수 있습니다. 개발자의 관점에서 상당히 편리함) 이 방법은 피해야 합니다. 이 그 이유는 IndexedDB가 객체를 저장할 때 먼저 객체를 만들어야 하기 때문입니다. 구조화된 클론 구조화된 클론 프로세스가 기본 스레드에서 일어납니다. 클수록 객체일수록 차단 시간이 길어집니다.

대부분의 경우 IndexedDB로 애플리케이션 상태를 유지하는 방법을 계획할 때 이로 인해 몇 가지 문제가 발생합니다. 많이 사용되는 상태 관리 라이브러리 (예: Redux)는 전체 상태 트리를 단일 JavaScript 객체로 표시합니다.

이러한 방식으로 상태를 관리하면 많은 이점이 있지만 (예: 코드를 쉽게 추론하고 단순히 전체 상태 트리를 IndexedDB에 단일 레코드로 저장하는 동안 제한되거나 디바운싱되었더라도 모든 변경 후에 이 작업을 수행하면 기본 스레드가 불필요하게 차단되면 쓰기 오류 발생 가능성이 높아지고 경우에 따라 브라우저 탭이 다운되거나 응답하지 않을 수도 있습니다.

전체 상태 트리를 단일 레코드에 저장하는 대신 개별 항목으로 분할해야 합니다. 실제로 변경되는 레코드만 업데이트합니다.

IndexedDB에 이미지, 음악, 동영상과 같은 대용량 항목을 저장하는 경우에도 마찬가지입니다. 각 항목 저장 자체 키로 가져올 수 있으므로 구조화된 데이터를 검색할 수 있습니다. 바이너리 파일을 가져오는 비용을 지불하지 않고 비용을 절감할 수 있습니다

대부분의 권장사항과 마찬가지로 이는 '모 아니면 도' 규칙이 아닙니다. 그렇게 할 수 없는 경우에는 상태 객체를 분할하고 최소한의 변경 집합을 작성하여 데이터를 하위 트리로 분할하기만 하면 됩니다. 이것만 작성하는 것이 항상 전체 상태 트리를 작성하는 것보다 더 낫습니다. 리틀 개선이 전혀 개선되지 않는 것보다 낫습니다

마지막으로, 항상 성능에 미치는 영향을 측정해야 합니다 일어날 수 있는 일입니다 IndexedDB에 대한 작은 쓰기 작업이 큰 데이터보다 더 잘 수행됨 이는 애플리케이션이 수행하는 IndexedDB에 대한 쓰기로 인해 실제로 장기 작업 기본 스레드를 차단하고 사용자 환경을 저하시킵니다. 측정이 중요하므로 어떤 기준으로 최적화해야 하는지를 이해할 수 있습니다

결론

개발자는 IndexedDB와 같은 클라이언트 스토리지 메커니즘을 활용하여 여러 세션에 걸쳐 상태를 유지할 뿐만 아니라 애플리케이션이 실행되는 시간을 반복 방문의 초기 상태를 로드하는 데 걸린 시간

IndexedDB를 적절히 사용하면 사용자 환경을 크게 개선할 수 있지만 이를 잘못 사용하거나 오류 사례를 처리하지 못하면 앱이 손상되고 사용자의 만족도가 떨어질 수 있습니다.

클라이언트 스토리지에는 제어할 수 없는 많은 요인이 포함되므로 코드가 잘 작동하는 것이 중요합니다. 오류를 올바르게 처리할 수 있도록 합니다.