당신의 친절한 이웃, 코딩맨

당연히! 중복 요청, 필요 없는 요청은 줄이는 게 맞다. 개발할 때도 그렇고, 테스트할 때도 반드시 신경 쓰는 게 프런트 엔드 개발자라면 가져야 할 기본 소양 아닐까?지금 서비스는 탠스택 쿼리 (Tanstack Query)를 쓰고 있다, 캐싱에 짜릿함을 맛보고 UX를 개선했다는 즐거움을 느끼고 있는 와중. api 요청 수를 줄여달라는 요청이 프런트 팀에게 왔다. 현 상황에서 서비스를 전체적으로 보았을 때, 필요한 요청만 보내고 있어보였다. 여기서 앞으로 확장성을 가지고, 유지 보수성을 챙기면서도 요청수를 잘 관리할 수 있는 방법이 있을까 했지만 쉽게 떠오르지 않았다.클로드 코드도, 코덱스도 원하는 답변이 없었고, 요청 하나하나 '깎는 느낌의 작업들을 추천해 줄 뿐이었다' 이런 방식은 이런 상황은 요청을 ..

프런트엔드에서 상태관리는 늘 쉽지 않았다. 그리고 계속 쉽지않아진다.처음에는 redux-toolkit이 가장 안전한 길처럼 보였다. 표준화된 구조, 많은 레퍼런스, 팀원들도 익숙했고.하지만 프로젝트가 커지면서 “안전함”보다 “답답함”이 더 크게 느껴지기 시작했다. 내가 담당한 내부 관리툴은 리스트/검색/필터/페이지네이션이 기본이고,여러 곳에서 같은 데이터를 읽고 쓰는 화면들이 많았다.이런 화면에서 redux-toolkit은 이렇게 느껴졌다.slice가 늘어나고 action이 늘어난다서버 상태와 UI 상태가 한 덩어리처럼 섞이기 시작한다“불러오는 데이터 속도가 저하되면서 개선을 내가 할 수 있는게 있을까?” 라는 의문이 계속 든다그러다 결론이 났다.클라이언트 전역 상태와 서버 상태는 분리하자.그리고 그 기..

프런트 엔드 개발자들은 보통 여러 개의 레포지토리를 갖게 된다. 이유는 다양하다. 서비스가 다양할 수 있고, 기존의 서비스를 여러 개로 분할해서 배포/관리하거나, 내부 업무를 위해 화면을 만들 때도 있기 마련이다. 내 예시로는, 패치 로그를 기록하고 검색해서 볼 수 있는 패치 로그 사이트, 서비스 화면, 관리툴, 권한툴, 디자인 시스템,... 이외에 몇 개 더 있다. 레포지토리가 많아지면 과연 좋을까? 처음엔 독립적으로 여러개의 툴을 따로따로 관리해서 작업하는 레포지토리가 분리되니까 더 효율적일 것이라 생각했다. 쉽게 생각하면 프런트 개발자 5명이서 5개의 레포지토리에서 작업을 하니 절대 컨플릭트 날일도 없고, 독립된 환경에서 병렬로 일이 진행된다 생각했었다. 문제는 사소한 곳에서 시작된다. 각각 레..

XSS를 막기위해 우리가 해야하는 노력들. API가 html구조를 response해서 파싱해야하는데,dangerouslySetInnerHTML을 사용했다가 XSS보안에 대한 경고를 받았다. 태그의 값을 바꾸는 함수에대해 어디까지 알고 있었지?$('h1').innerHTML = '짱짱'이렇게 값을 바꾸던 것에서 앞으로 출시될$('h1').setHTMLUnsafe('짱짱맨')이걸로 shadow 돔을 사용가능한 버전이 나온다. 쉐도우 돔의 설명은:https://ui.toast.com/posts/ko_20170721여기서 참고* eval은 이제 아무도 사용하지 않죠??..??ㅇㅁㅇ 설마 이런거 보안이나 따지고 원래 innerHTML에 script 태그가 있으면 실행되지 않도록 자체적으로 막혀 있는거 모르는 사람..