최근 만들던걸 다 만들어서 주변인들과 함께 애니감상회를 열고 있는데, 별로 상정하지 않았던 문제를 발견해서 공유해봅니다.
koderpark
Storage hooks
Plasmo를 편의상 사용하게 되면서, React Component에서 바로 꺼내다 사용할 수 있는 Storage Hooks를 발견, 적극적으로 사용했었습니다.
이걸 사용하면 Background Service Worker가 계산한 값을 Event로 쏴서
그걸 받아서 다시 상태동기화를 하고 State를 쪼개서 관리하고
이런 고민을 일절 할 필요 없게 됩니다.
Setting값 같은것들을 바로 Storage에 저장할 수 있음은 물론, Storage가 하나의 신뢰 가능한 상태 저장소로 작동하게 됩니다.
Service Worker는 Storage에 값을 적재하거나 삭제하는 역할을 뒤에서 수행하며,
항상 Storage에서 hook을 통해 값을 일방향적으로 가져와 사용하게 됩니다.
박성훈
이는 위 article에서 알아봤듯 Service Worker가 항상 작동해주기 때문이며,
SW가 백엔드와 알아서 상태를 관리해주고 Popup / Content Script는 그걸 일괄적으로 받아서 사용하기만 하면 됩니다.
처음에 이러한 방법을 선택한 이유는 Plasmo의 공식문서에서 storage API를 추천하고 있었기 때문이며, 소스코드 작성 중에 이런 형태로 수렴했습니다.
문제: Storage Api Limit
문제는
const [hailingFrequency] = useStorage({
key: "hailing",
instance: new Storage({
area: "local"
})
})와 같이 Plasmo의 useStorage가 area:"local"을 optional하게 받으며, 기본이 sync storage라는데 있습니다.
크롬의 sync storage는 구글 계정으로 로그인한 모든 기기에 동기화 되는 상태이기 때문에, storage 접근 시 rate limit이 설정되어 있어서 적정량 이상의 호출을 진행하면 해당 요청을 무시당하게 된다는 것입니다.
여러명이 모여서 채팅을 주고받다 보면 "초당 2회" 라는 제한은 너무나도 쉽게 달성하기 때문에, 채팅을 주고받는 관련 기능이 작동하지 않았습니다.
해결
Plasmo에서 제공하는 wrapper없이, Event를 주고받으며 클라이언트 단에서 State를 관리하면 됩니다.
저장을 localStorage에 해두는것도 충분히 좋은 방법의 하나로 고민중이었으나, video나 채팅같은건 한 30초만 지나도 무의미해지는 휘발성이 높은 데이터였기 때문에 그냥 event로 주고받기를 선택했습니다.
참고로 테스트 도중에 HMR이 작동하면 Storage에 쓰던 값을 미처 지우지 못하게되는 경우가 왕왕 있었는데, 이 역시 앞단에서 useState로 관리하면서 말끔히 해결되기도 했습니다.
결론
plasmo의 useStorage hook은 편리해보이지만, 자주 변동되는 상태를 관리하기엔 적합하지 않은 형태라는 사실을 알았습니다.
plasmo를 도입해 보았다는 다른 article들에서도 wrapper를 사용해보았지만 결국 크롬 확장의 기본 기능들을 사용했다 라는 후기가 많았는데, 얼추 맞는말인것도 같습니다...
크롬 확장을 만들때는 Service Worker도 그렇고 storage도 그렇고 어떤 상태를 일관적으로 들고있기가 굉장히 힘들기 때문에, 어떻게하면 stateless하게 만들어서 굴릴수 있을지 고민해보는게 조금 더 건설적인 고민이 될지도 모르겠습니다.
