프론트
프론트
첫번째 질문) 세부 탭별로 라우팅을 전부 사용해야 할까요? 현재 라우팅은 네비게이션 메뉴에 있는 것만 나누고 각 메뉴별 탭들은 배열의 activeIndex 값을 상태관리를 통해 이동을 하고 있습니다. 탭별로 별도의 페이지라고 생각하고 url을 각자 부여해야할지 고민이 됩니다. 각 페이지별 첫번째 탭들이 default 페이지처럼 사용되고, 첫번째 탭이 아닌 곳으로 바로 이동하는 흐름은 현재 없어서 라우팅 처리를 하지 않았습니다. (예시코드 참고 부탁드립니다)
두번째 질문) 라우팅처리를 한다면 특정 id 값은 url에 보이게 해야할까요, 전역관리 해야할까요? url에 보이면 useParam을 이용해서 일관적으로 명확하게 id 값을 받아와 API 요청이 가능하겠지만, 그러난 부분에 대해 사용자가 임의조작을 할 가능성을 막아둬야할 것 같습니다. 전역관리로 현재 보고 있는 특정 id값을 관리하면 사용자의 임의조작은 막겠지만 전역상태로 관리해야할 페이지들의 id값이 많아서 전역상태를 수정하거나 접근하는 로직이 복잡해질 것 같습니다. 보통 어떤 방식으로 url을 만드나요? (예시 url 참고부탁드립니다)
세번째 질문) 탭별로 라우팅 처리를 한다면 지금 구성한 url 괜찮나요? (url 참고부탁드립니다)
네번째 질문) 무한스크롤 라이브러리를 선택할 때 react-infinite-scroll-component과 react-intersection-observer 라이브러리 중 react-infinite-scroll-component를 선택했습니다. 사용량이나 최신 업데이트 유무에서는 후자가 더 좋지만, 전자가 무한스크롤에만 집중한 라이브러리라서 더 간단하고 빠르게 적용할 수 있다는 면에서 선택을 했는데, 구현을 하고보니 무한스크롤을 구현했다고 어필할 수 있을지 모르겠습니다. 단순하게 만들어진 라이브러리를 이용해서 자세한 동작원리를 모른 채 그저 적용을 한 것인데 무한스크롤을 구현했다고 할 수 있을까요? 좀 더 근본적인 질문은 라이브러리를 이용해서 구현한 기술도 어필포인트가 될 수 있나요?(npm trends 참고)
다섯번째 질문) 운동 기록 탭이나 식단 관리 탭에서 이미지와 동영상을 다루는데 용량을 줄여서 렌더링 속도를 더 올리고자 이미지 리사이징을 거쳐서 S3 버킷에 저장하려고 합니다. 클라이언트와 서버 모두 이미지 리사이징이 가능한데, 어디서 하는 게 더 효율적인가요?
여섯번째 질문) 운동 기록 탭이나 식단 관리 탭에서 이미지 용량을 줄여 렌더링 속도를 향상시키기 위해 이미지 리사이징을 거쳐 S3 버킷에 저장하려고 합니다. 이에 따라 기준이 되는 이미지 사이즈를 고정할 필요가 있습니다. 기본 사이즈를 픽스하고 이미지 사용 시, 이미지 박스를 고정된 상태로 유지하면서 이미지를 박스에 꽉 채워 크롭 및 줌을 해서 사용하는 방식과, 이미지를 원본 그대로 보여주되 빈 공간을 검은색 등으로 레터박스를 만드는 방식 중 어떤 것이 더 나은지 조언 부탁드립니다.