Bleeding edge

BOJ-ADDON 1.0.8 본문

Side Project

BOJ-ADDON 1.0.8

codevil 2023. 1. 22. 00:33

이전에 Context API를 선택했던 이유

전역상태를 관리하는 파일을 최대한 가볍게 하고 싶어서, 이미 내장되어있고, 자주 바꾸지 않기 때문에 Context API를 사용 했었는데 지금 고민해보니 굳이 Context API에 대해 다시 한번 고민을 하게 되었다.

다시 고민하게 된 이유

1. 내정되면 가벼운가?

번들링을 이용하면 필요한 함수만 불러 오기 때문에 Context API가 리액트에 있다고 하더라도 Context API를 사용하지 않는다면 Context API는 사용되고 있지 않았을 것이다 즉 Context API를 사용한 것과 만일 바꾸게 될 새로운 전역 변수 함수에 대해서 고민해보면

React(ContextAPI를 제외한 일부) + Context API + BOJ

React(ContextAPI를 제외한 일부) + BOJ + 새로운 전역 상태 관리툴

요런식으로 번들링이 될 것이고, 백준을 들어갈 때마다 이 파일을 받아서 사용할 것이 아니기 때문에 굳이 무게가 아주 과한게 아니라면 신경쓸 필요가 없다고 생각이 들었다.

2. 사용 빈도수

이전에 Context API의 단점을 내부에 있는 컴포넌트들의 리랜더가 된다는 것을 알고 있었지만, 에디터의 색상을 얼마 바꾸지 않을 것 같아서 선택을 했었는데, 지금와서 생각해보니, 예제를 추가를 많이하는 사람이 있을 수도 있고(요즘은 예제 추가를 자주하는 편이다) 앞으로 전역상태를 자주 변경해야 하는 경우를 고려해서 전역 상태를 관리하는 툴을 바꿀 필요가 필요가 있었다.

Recoil

다른 전역 상태 관리 툴에 비해서 Recoil이 다음과 같은 장점이 있어서 Recoil을 선택하였다.

  1. Context API와 사용하는 방법이 비슷해서 수정이 얼마 걸리지 않는다
  2. 다시 고민한 이유의 2번의 리랜더링이 안된다.

마무리

Context API에서 Recoil로 이번에 변경을 몇가지 에러가 있었지만 어찌어찌든 잘 해결했다. 문제는 요즘은 크롬 익스텐션을 업데이트하면서 실수가 나면 사람들이 사라지는 것이 너무 싫어서 패치를 적용하기 전에 어느정도 지금 진행한 것이 맞나 테스트를 더하고 업데이트할 예정이다. 그리고 요즘 다른 라이브러리를 보면 버전별로 package를 관리를 하던데 나도 이런식으로 관리를 해야할 필요성을 느껴서, 이것에 대해 다시 공부해야할 것 같다.

'Side Project' 카테고리의 다른 글

뒤 늦은 프로젝트 회고  (0) 2023.08.20
로컬에서 npm 패키지 배포하기  (0) 2023.03.08
Notion prettier 개발기  (2) 2023.01.16
BOJ-ADDON 1.0.7  (0) 2023.01.15
⛏️백준 애드온 리액트 리팩토링 리뷰  (0) 2022.11.13