Portfolio

px, rem 같이 쓴 게 종종 보이는데 하나로 통일하는 게 좋을 것 같다

rem을 쓸거라면 모바일, pc 해상도에 따른 폰트 크기를 고려해보면 좋을 것 같다

차크라 ui에서 prop으로 많이 달고 있는게 좋은 건지는.. 모르겠다 나중에 고려해보길.. (리팩토링 말씀하시는 듯) -> 커스텀하기가 쉽지 않고 라이브러리에서 에러가 생기면 고치기도 쉽지 않고 가독성 문제도 있기 때문에 실무에서 외부 디자인 시스템을 잘 안쓴다..

user.ts?를 상수로 보기는 어렵지 않나.. 그냥 하드코딩 박아놓은 거 아닌가.. 관련해 생각해보시길

폰트를 빌드하면 용량이 크다고 워닝이 뜨는데 해결할 방법? 폰트 자체를 들고 오면 프로젝트가 커지니 웹 폰트 쪽으로 풀어보시길

소셜 로그인과 이메일 로그인 구분? (ex 소셜 로그인은 비밀번호 변경이 안되어야함) 소셜 로그인을 한 다음에 토큰 받는 건 똑같은데, 유입 경로를 구분하고 싶은 건가? 네. 필요 없을까요? 필요가 없다기 보다는 페이지가 다르게 보인다는 명확한 요구사항이 있는 게 아닌 상황으로 보여서 굳이? 싶다

(API PR 코드 리뷰) 베이스 인스턴스 자체가 url이나 config값 지정하고 넘어가는데 깡으로 각자 api에서 지정하는 거 같은데 웬만하면 개별 api 호출부에서는 url, request 바디에 들어갈 데이터만 넘길 수 있도록 구성하길... config 어쩌고가 베이스 인스턴스에 있어도 상관이 없을 거 같아 보인다

인스턴스가 두개인데 반복되는 건 삭제해야 할 것 같다

팁) 401 떨어졌을 때 팝업 등을 띄우고 로그인 페이지로 이동하는 로직이 추가되면 좋을 것 같습니다

서버 쪽에서 error 객체에 넣어줄 데이터가 있는 게 아니면 굳이 커스텀을 만들어야할 이유가 없을 거 같다 (벡엔드랑 협의해서 하게 된다면 하면 좋을 거 같다)

취향차이인데, 타입스크립트는 보수적으로 쓰기 위함이 크다고 생각이 되기 때문에 제너릭보다는 타입으로 지정하는 걸 추천드립니다 (고정된 상수이고 어떤 타입이 들어올지는 협의할 수 있는 부분이니 타입으로 하는 건 어떨지하는 의견!)

제너릭이 any 타입과 같은 느낌이...? ㄴㄴ 다르다. any는 정말 어쩔 수 없는 경우 아니면 쓰지말길..

중복되는 코드를 interface로 선언하고 extend로 확장하면 확장한 타입의 이름만 보이던데 왜 안보여주는 걸까요? 처음부터 끝까지 interface만 썼으면 크게 상관이 없을 거 같긴한데.. 타입을 쓰니까 보이고 인터페이스를 쓰니까 안보이더라구용.. 확실히 이유를 모르겠어서 보고 답변드리겠습니당

이야기가 나와서 하는 말인데 속성이 다른 두 개를 합칠 때는 무조건 인터페이스입니다 기본적인건 인터페이스, 인터페이스가 안되면 타입으로 쓰길~!

pr 올릴 때 패키지를 바꾼 게 아닌데 package-lock이 변했다? 이건 올리면 안됨..

슬랙에 올린 상황에서는 node module을 재설치하는 과정이 문제일 수도.. 똑같이 설치된다는 보장이 없다

동건님이 말씀하신 경우가 npm ci의 문제는 아닌 거 같습니다. 커맨드 문제라기보다는 패키지 디펜던시가 원래 꼬여있을 가능성이 커보임 롤업 문제가 아니었을까~ 하는 생각!

하실 때는 npm ci, npm i 둘 중 하나로 통일하는 게 좋을 거 같습니다 (이런데 시간 낭비하는 건 시간 아까우니까 리액트에 집중한다!는 마인드로 ㄱㄱ) ci도 상관 없는데 ci는 설치하는 시간이 좀 더 걸릴 거 같아서 그게 단점일 거 같다. 아예 i로 통일하는 게 좋지 않을까~하는 생각입니다

웹이랑 모바일을 프로젝트 초창기부터 고려해야할지? 아니면 웹 먼저 고려하고 모바일을 고려해야할지 궁금합니다 처음에 세팅해두고 진행하는 게 비용이 덜 들어요. 모바일 먼저하고 pc를 하기도 하는데 이런 경우 pc를 고려하지 않는 코드들이 있을 수 있어 초창기부터 고려하는 게 좋아보인다. 근데 이건 우선순위가 낮은 부분이라 생각이 된다. 지금은 기능 구현이 중요하다고 생각이 된다. 기능 하나 더 붙이는 게 좋지 않을까

스와이퍼는 swiper.js라는 많이 쓰는 라이브러리 쓰시길 추천드립니다 (그냥 구현하기 쉽지 않음)

뭔가 담당한 기능이 안보이는 분들이 있는데, 굵직한 기능을 맡도록 나눠주시면 좋을 거 같다

모달은 하나씩만 뜬다면 차크라 ui에서 제공해주는 거 써도 크게 문제 없을 거 같다 이슈가 생긴다면 뭐 컴포넌트에서 모달을 띄우던가 하는 식으로 하면 되지 않을까,,

jwt 토큰을 필요로 하지 않는 요청에서 담아서 둬도 상관이 없나요? 상관 없을 거 같다 그걸 뽑아 쓰는 건 서버 쪽이기 때문에

vscode에서 가로줄? 생기는 거 어캐하셨는지.. Indenticator 익스텐션입니다

4주차 커피챗