'분류 전체보기' 카테고리의 글 목록 (9 Page)

이번주는 작업하느라 바쁜 한 주였다.

백3, 프2이라는 상황에 엄청난 작업량을 소화하기 위해 중간중간 잠깐 쉬는 것을 제외하면 거의 작업만 했던것 같다.

디자인이 아직 완성된 것도 아니라서 완성되면 더 많은 작업이 있어야 할 것으로 예상되므로 앞으로도 1주정도는 계속 열심히 작업해야 할 듯 하다.

이번주는 트러블 슈팅으로 적을만한게 몇가지 있었는데 기억 안난다.

크게 막혔던 건 없었다.

다음주부터 런칭이므로 이번주 WIL은 여기서 끝!

이번주는 지금까지 설렁설렁 했던 마음을 다잡고 중간 발표 전까지 열심히 해보자는 생각으로 코드 짜는데에만 전념했던 주이다.

급하게 짜다보니 이것저것 기능이 미비해서 중간 발표가 너무 아쉬웠다.

그럼에도 평가는 그럭저럭 좋게 받아서 기분이 좋았다.

남은 29일 (실질적으로는 22일 정도) 동안은 제대로 공부를 해가면서 코드를 정리하고 완벽한 작품을 만드는데 시간을 쏟아보려고 한다.

 

아래는 우리가 중간 발표로 만든 사이트이다.

 

사이트의 목적은 링크, 메모를 담을 수 있는 사이트이다.

우리가 카톡 같은 곳에다가 '나에게 쓰기'를 활용해서 링크, 메모를 보관하는 것에서 착안해서 기획하게 되었다.

내가 원하는 링크,  메모 등등을 내 모음에 보관을 해놓고, 사람들에게 공유하고 또 다른 사람이 만든 자료들을 검색해서 내가 볼 수 있는 사이트이다.

 

구현하고 싶은 기능들이 정말 많은데, 일단 기획한 부분부터 최대한 빨리 완성하고 완성도를 먼저 높여야 할 것 같다.

 

 

이번주의 트러블 슈팅은 아래와 같다.

1.  a 태그 동작 막기

우리는 폴더를 '모음', 그 안에 내용들을 '조각'이라고 하는데 이 조각 목록에서 [선택 모드]를 활성화 하면 조각을 선택하고 일괄 삭제할 수 있는 기능이 있다.

근데 이 일괄 선택 모드에서 링크들을 클릭했을 때, 링크가 클릭되지 않게 하고 링크들에 테두리가 생겨야 하는데, 링크가 실행되는 문제가 있었다.

그래서 a태그에 onClick 이벤트를 등록하고 [선택 모드]가 활성화되어 있을 때  e.preventDefault()를 사용하여 a태그의 기능이 동작하지 않게 만들었다.

 

2.  카테고리 선택

이번주 최대의 난제였다.

이 카테고리의 선택 조건은 아래와 같다.

1. 화면이 처음 열리면 현재 내 계정에 있는 항목들의 카테고리가 나온다.

2. 기본적으로는 [카테고리 전체]가 선택되어 있는 상태어야 하며, 카테고리 선택부의 하단에는 폴더 목록이 나오는데, 이 폴더 목록들은 카테고리가 선택된 상태에 따라 갱신되어야 하고, [카테고리 전체]를 제외한 카테고리는 다중선택이 가능하다.

3. [카테고리 전체]를 제외한 카테고리들은 클릭시 [카테고리 전체]가 비활성화 되어야 한다.

4. 폴더를 선택해서 폴더 내의 목록이 나오면 카테고리는 새로 갱신되어야 한다.

 

이 로직은 정말로 어려웠다.

사실 이 코드는 지금 완성한 코드도 리팩토링이 필요할 정도로 코드가 복잡하다.

그래서 부끄러우므로 코드는 지금은 안올릴 생각.

 

처음의 문제점은 API가 처음에는 프로필 정보와 같이 카테고리 전체를 출력해주는 API여서 페이지를 처음 들어온 시점에서만 데이터가 넘어오는 것이었다.

그래서 백엔드에 요청을 해서 API를 교체했는데, 이거는 모음, 파일 리스트를 불러올 때, 카테고리 리스트를 같이 불러오는 거였다.

여기서 발생한 문제점은, 카테고리를 클릭하면 그에 해당하는 카테고리 리스트들이 들어오면서 카테고리 리스트도 같이 불러오는데

그걸로 쿼리 데이터가 교체되면서 카테고리 컴포넌트가 다시 렌더링 되는? 증상이 있어 이걸 어떻게 해결해야 할까 2시간 정도 고민한 것 같다. 결국 백엔드에 요청해서 카테고리 API와 리스트 API를 분리하는 방법으로 해결했다.

이렇게 해결하고 나서 생각이 든 건데, 카테고리 데이터를 별도 데이터로 보관하면서 처리하면 되지 않을까? 라는 생각이 문득 들었다.

나중에 한번 그런 방식으로도 해결 가능할지 고민을 해봐야 겠다고 생각 했다.

 

 

이외에도 몇가지 트러블이 더 있긴 한데 코드 너무 열심히 짜느라 기억이 안난다.

앞으로는 더 잘 정리하기 위해서 고민을 좀 더 많이 해봐야 할 것 같다.

 

 

3. 항목 드래그 & 드롭 구현시 링크 + 이미지의 크롬 자체에서 제공되는 드래그 (링크 드래그, 이미지 드래그) 때문에 항목 드래그가 안되는 증상

이것도 꽤 골머리를 앓았다.

우리는 텍스트 타입 + 링크 타입의 두가지 항목이 있는데, 

각 항목을 드래그 하면 오더링이 변경되는데, 링크 드래그 + 이미지 드래그가 되면서 드래그가 잘 되지 않는 것이었다.

그래서 어떻게 하면 좋을까? 고민을 해보다가 링크 드래그에 한해서는 a태그를 div 태그로 교체하고 onClick 이벤트에서 링크를 들어가게 만들었다.

 

그리고 아래는 이미지 드래그를 막기위해 찾아봤던 내용들이다.

 

https://velog.io/@soyoungggg/CSS%EB%93%9C%EB%9E%98%EA%B7%B8drag%EB%A7%89%EA%B8%B0

 

[CSS]드래그(drag)막기!

이미지 등 drag 막기 css전체 드래그 막기(복사안됨?)일부 영역 드래그를 허용 -> bacy에 드래그 방지 코드를 넣어놓고, 원하는 영역에 클래스 추가 텍스트만 드래그를 허용하고 싶은 경우이미지 드

velog.io

https://worldlibs.tistory.com/9

 

텍스트 드래그, 이미지 드래그 방지

HTML 태그 속성에 추가 - 이미지 드래그 ondragstart="return false" - 텍스트 드래그 onselectstart="return false"

worldlibs.tistory.com

 

나와 어떻게 상황이 다른지는 모르겠지만 위의 방법은 다 안먹혀서

이 외에도, 이미지 드래그를 막기 위해 이것저것 검색하다가 한글 정보가 아닌 영어 정보에서 찾아보기로 했다.

 

 

https://stackoverflow.com/questions/49898749/how-can-i-prevent-drag-and-drop-images-in-a-react-app

 

How can I prevent drag and drop images in a react app?

We got how to prevent drag drop image with jquery with $('img').on('dragstart', function(event) { event.preventDefault(); }); but I want to achieve the same in a react app, and without jquery. How ...

stackoverflow.com

 

그러던 중, 위 링크에서 아래 댓글에서 pointer-events: none;를 발견!

 

 

한줄로 쉽게 해결됬다.

 

 

 

항해 키워드 :  MVP개발을 하는 3주 동안 어떤 기술들을 다뤄봤는지 정리해보세요.

3주동안 사용해본 기술들

프레임워크

- React

전역 상태 관리 라이브러리

- Redux Toolkit

스타일링 라이브러리

- Styled Components

서버 상태 관리 라이브러리

- React Query

아이콘 라이브러리

- React Icons

아이템 드래그&드롭 라이브러리

- React Easy Sort

폼 라이브러리

- React Hook Form

데이터 패칭 라이브러리

- Axios

가상 api 서버 라이브러리

- Json-Server

전역 상태 관리 라이브러리

- Recoil

구글 소셜 로그인 라이브러리

- react-oauth/google

이번주는 디자인이 어느정도 나와서 프론트가 이것저것 바빠진 한 주였다.

빠르게 정리하고 작업을 이어서 해야겠다.

 

이번주는 큰 트러블 슈팅은 없고 트러블만 있고 아직 해결 못한 문제가 많아서 그냥 이번주에 어떤 것을 했는지만 적기로 했다.

API 요청 Redux 미들웨어 -> React Query 로 변경

우리는 React Query를 써보자는 생각으로 기본적으로는 Redux Toolkit을 사용하다가 나중에 React Query로 전환하려고 했는데 작업을 하다보니 상태관리에 대한 어려움을 겪었다.

 

-> 비슷하게 생긴 다른 데이터를 보관해야 하는데, 막 보관하면 너무 지저분해질 것 같아서 어떻게 보관하고 어떻게 꺼내 쓸지 매번 고민해야 했다.

 

그래서 React Query로 나중에 코드를 많이 짜놓은 상태로 변경하는거보다 지금 당장 적용하고 그냥 아싸리 Query로 작업하는게 낫겠다는 판단하에 새벽 3~4시간을 투자하여 코드를 교체하는데 성공했다. (아직 일부는 미교체)

일단 현재 느낀 React Query의 장점은 크게 아래 두가지이다.

- 생성, 수정, 삭제시 데이터를 자동으로 다시 불러오는 기능

- 조회할 때 데이터의 보관

 

사용해보고 나서 느낀 점은, '너무 편하다'라는 것이었다.

리덕스 툴킷에 데이터를 어떻게 보관해야 할지, 어떻게 관리해야 할지 고민을 했었는데, 리액트 쿼리는 그걸 대신 해결해준다.

다만 회사에서 React Query를 안쓰는 경우도 있을 수 있기 때문에 Redux Toolkit을 좀 더 해보는게 좋지 않을까 싶긴 한데, 항해 6주동안 빠르게 코드를 구현하기 위해서는 그냥 지금 교체하는게 맞다고 생각한다.

 

커스텀 훅 만들어보기

자주 쓰는 코드들을 훅으로 만들어보려고 했는데, 사실 이런 식으로 작성하는게 맞는지 모르겠는데 일단 마구 만들어보고 있다.

 

API 코드 분리

API 코드들을 따로 파일을 만들어서 보관해두고 있다.

이걸 리액트 쿼리에서 불러와서 사용할 예정인데, 이렇게 하는게 맞는지는 모르겟다.

어떻게 정리해야 할지 아직 고민중이다.

 

액세스 토큰 만료시 리프레시 토큰으로 액세스 토큰 재발급

인터넷에서 액세스 토큰 만료시 혹은 리프레시 토큰까지 만료시에 처리를 하는 코드를 적당히 긁어다가 인터셉터에 붙이고 코드를 약간 수정했는데, 요청이 여러개 들어왔을때 인터셉터에서 한번만 처리할 방법이 없는지 찾아봐야 한다.

이거는 머리아파서 일단 대충 짜고 스킵한 문제다.

 

고민중인 사항

리덕스 툴킷으로 작업하던걸 리코일로 교체해야 하나 고민중에 있다.

리코일을 원래부터 고려하고 있었는데, 그냥 기본에 충실하자는 생각으로 리덕스 툴킷을 선정했는데.

로직을 짤 때마다 매번 번거로움을 느끼고 있어서 작업할 때 바로바로 로직을 생각 할 수 있는 리코일로 변경한다면 훨씬 작업 속도가 빨라질 것 같아서 고려중!

 

아래는 뭔가 각 상태관리 라이브러리에 잘 정리되어 있는거 같아서 링크를 올려뒀다.

https://ridicorp.com/story/how-to-use-redux-in-ridi/

 

리덕스 잘 쓰고 계시나요? - 리디주식회사 RIDI Corporation

리덕스에는 정해진 규칙이 없습니다. 개발자들 모두 자신만의 방식으로 사용 하고 있어요. 하지만 제대로 사용하지 않으면 굉장히 불편할 수 있고, 유지 보수에 있어서 오히려 독이 될 수도 있

ridicorp.com

 

앞으로는 1주마다 WIL을 길게 적어보려고 한다.

 

이번주를 정리해보도록 하겠다.

 

이번주는 여러가지 바빴던 한 주인 것 같다.

디자인이 나오기 전에 이것저것 기능들을 구현하고, 기획 회의를 매일 꾸준히 진행했다.

이번 주에 시간이 남으면 리액트 공부도 조금 하려고 했는데, 별로 진행 못한게 아쉽다.

기획 회의, 프로젝트 세팅, 배포 세팅 같은 작업들만 하는데도 시간을 많이 잡아 먹어서 실질적으로 작업한 것도 별로 없다.

이번주에 내가 작업한 것들은 크게 세가지가 있다.

소셜 로그인 / 링크 타입 글쓰기 / 상단바, 검색 화면 스타일 작업.

오늘은 프로젝트 소개를 하고 각 작업에 대해 말해보려고 한다.

 

우선 우리 프로젝트에 대한 소개를 해보려고 한다.

 

1.  프로젝트 개요

가끔 우리가 급할 때 링크나 메모 같은 내용들을 카톡에 '내게 쓰기'를 활용하여 정보를 보관한 적이 있을 것이다.

우리가 

우리의 아이디어는 디자이너님의 '링크 보관' 아이디어에서 시작되었다.

기획 회의에서 우리는 브레인 스토밍 처럼 아이디어를 마구 내어 보고 거의 한 7~8개 정도의 아이디어가 나왔는데,

그 중에서 가장 평가가 좋았던 아이디어가 두가지 였다.

 

디자이너님의 '링크 보관소'와 우리 부팀장님의 '롤링 페이퍼'가 평가가 좋았다.

여기서 나는 롤링 페이퍼도 꽤 재밌고 좋을거 같다고 생각 했지만, '링크 보관소'의 아이디어를 잘 활용하면 좋게 사용 할 수 있을 것 같다고 생각했다.

그래서 링크만이 아니라 메모, 이미지 같은 것들도 빠르게 보관하고 우리가 다시 재사용 할 수 있으면 어떨까라는 아이디어를 덧붙였다.

그렇게 어찌저찌 다수결로 '링크 보관소' 아이디어가 채택되었고 여기서 단순 '링크 보관소'가 아닌 '빠르게 조회 가능한 메모, 링크 보관소' 같은 느낌으로 확정되었다. 나중에 상황을 보고 빨리 구현이 된다면 기능이 추가될 수도 있을 것 같다.

 

우리의 프로젝트명은 '모음'으로 결정되었다. 여러 정보 조각들의 모음이라는 뜻

주소도 클라우드 느낌으로 사용한다고 생각해서 moum.cloud를 구매하였다. (3000원이라 개이득)

프로젝트 시작하고 한 2일정도는 기획회의만 진행했고, 화요일까지는 거의 백엔드 api가 나오기 전까지 프론트 기획 회의, 프로젝트 세팅 등을 진행했다.

 

2. 트러블 슈팅

사실 나는 이번주에 맡은게 '소셜로그인, 링크 타입 글쓰기' 단 두개 밖에 없어서 별로 할게 없었다.

그래서 트러블 슈팅이라고 할것도 없긴 했는데, 일단 고민이 되었던 하나가 있긴 하다.

링크 타입 글쓰기는 내가 하는 작업보다는 백엔드 측에서 해야 할 작업이 많아서, 코드만 짜놓고 기다리면 되는 거였는데

'소셜 로그인' 하나에서 정말 많은 고민이 있었다.

우리는 소셜 로그인이 일단 구글 로그인 하나만 먼저 하기로 했다.

그러던 어느날 매니저님에게 [정확한 OAuth 를 구현하기 위해서는 'react-google-login'모듈을 쓰면 안되고 모든 로그인 처리를 백엔드가 맡아야 한다]라는 얘기를 주워 들었는데 그거 때문에 이것저것 많이 알아보았다.

우선 인터넷에 '리액트 구글 로그인 구현'이라는 키워드로 검색하면 죄다 'react-google-login' 모듈을 사용하여 구현하는데, 이 모듈은 사용해 보니까 구글에서 OAuth 로그인 방식이 바뀌어서 더 이상은 사용할 수 없는 모듈이라고 한다.

 

그래서 나는 '@react-oauth/google'이라는 모듈을 사용했다.

해당 모듈에 관해서는 아래 두 링크에서 확인할 수 있다.

 

https://react-oauth.vercel.app/

 

@react-oauth/google

Google OAuth2 using the new Google Identity Services SDK for React @react-oauth/google

react-oauth.vercel.app

 

https://github.com/MomenSherif/react-oauth

 

GitHub - MomenSherif/react-oauth: Google OAuth2 using the new Google Identity Services SDK for React 🚀

Google OAuth2 using the new Google Identity Services SDK for React 🚀 - GitHub - MomenSherif/react-oauth: Google OAuth2 using the new Google Identity Services SDK for React 🚀

github.com

 

 

사실 처음에 이 모듈을 알게되고 문서를 찾기 전에 사용했을 때에는, 인터넷에서 어디서 주운 코드를 갖다가 적용했는데

Credential이라는 값이 나와서 그거를 백엔드에 넘겼는데 그 값에 대해 알아보니 구글의 어떤 주소로 Credential 값을 갖다주면 그냥 내 개인 정보를 프론트에서도 확인할 수 있어서 찜찜했다.

 

그래서 이것저것 검색해보다가, 매니저님이 말씀했던게 생각났는데 그걸 어떻게 백엔드에 설명할 자신이 없어서 그냥 OAuth에 관해 이것저것 블로그 글들을 읽어보았다.

그래서 더 많은 고민에 빠지게 되었다.

인터넷에서는 죄다 리액트에서 구글 OAuth 구현을 하는데 'react-google-login' 모듈을 썻는데, 그럼 이 사람들은 전부 다 잘못 쓰고 있는 건가? 라는 생각도 들고, 특히나 그림 설명들이 나를 더 헷갈리게 만들었다.

 

이걸로 한 2일 넘게 계속해서 검색해보고, 고민해봤던 것 같다. 토요일에는 멘토님에게도 관련하여 질문을 했지만 어느쪽으로 해도 상관 없다 라는 답변을 받아 '왜?'라는 생각을 계속 했다.

그런데 그 답변과 같이 결과적인 나의 결론으로는, '상관 없다'라고 결론을 내리게 되었다.

프론트에서 OAuth 요청을 해도, 백엔드에서 요청을 해도 사용자 정보를 받을 수 있다면 어디서 처리하든 상관이 없지 않을까라는 생각이 문득 들었다.

그리고 지금 우리는 보안 일을 하는 것도 아니기도 한데 보안을 그렇게까지 신경써야 하나 생각도 들고,,,,

내가 듣기로는 백엔드로 일하는 친구는 작성한 코드를 보안 업체에 맡겨서 검증을 받기도 한다고 들었다. (그렇다면 지금 당장은 구현 하는데만 집중하면 되지 않을까?)

 

물론 나름대로 신경을 써서 코드를 작성하면 좋겠지만, 이런 사소한 걸로 몇일이나 고민하며 시간을 괜히 날린 것 같아 뭔가 조금 안타깝다.

특히 내가 백엔드를 자세히 알지 못하기 때문에 서로 소통하면서 자꾸 바꿔나가는 것도 힘이 든다,,,

그냥 내 코드나 열심히 봐서 코드 최적화 하고 더 많은 기능을 큰 버그 없이 완벽에 가깝게 구현하는게 좋지 않을까라는 생각이 든다.

 

 

우리는 위에 올린 링크에서 위 이미지와 같은 방법으로 구현했다.

프론트에서는 구글에 요청하여 인가코드를 발급받고, 이걸 백엔드로 AXIOS를 통해 넘겨서 백엔드에서 그 인가코드와 clientId, secretKey를 통해 토큰와 사용자 정보를 발급받고 그걸로 새 토큰을 만들어 프론트에 지급하는 구조이다.

 

다른 조에서 한걸 보면 그냥 백엔드에서 준 링크 달고 a태그로 접속만 하면 끝나는 방식으로 구현하기도 했던데, 그 방법이 정답이 아닐까 고민도 해봤는데 솔직히 별 의미 없는 고민이었던 것 같다. 취업하기 전까지는 그냥 그런 두가지 방법이 있구나... 정도만 알아두고 회사에서 그냥 만들라는 대로 만들면 되겠다고 생각했다.

 

3. 스타일 작업

목요일쯤에 대략적인 와이어프레임 디자인이 나왔는데, 역시 디자인 실력이 훌륭하신 디자이너님이라 단점이 없는 와이어 프레임이었다.

디자이너님이 너무 바쁘셔서 그냥 엄청 대충 만들어 주실수도 있겠다고 생각했는데 그래도 약속하신 일정대로 맞춰서 훌륭한 디자인으로 뽑아오니 그래도 꽤 만족스러운 것 같다.

프론트 세명이서 페이지를 나눠서 스타일 작업을 진행했고, 기획 회의에서 몇개 페이지는 갈아 엎어지기로 해서 일단 보류했다.

그리고 디자이너님이 반응형에도 흥미가 있으셨는지 반응형으로 만들어 보자는 얘기도 나왔다.

뭔가 기획이 이것저것 많아져서 남은 기간 안에 훌륭하게 만들어 낼 수 있을지 걱정 반 기대 반인데 내가 시간을 갈아서 완성해내면 되지 않을까 싶다.

 

4. 다음 주 목표

우선, 일요일인 오늘은 리액트 강의를 조금 들을 것 같다.

우선 다음주에는 이번주 목표였던 로그인, CRUD에서 로그인을 좀 더 가다듬고 (현재 리프레시 토큰에 관한 코드 처리가 미완 상태임)

나는 파일 드래그&드롭과 태그 드래그&드롭에 대해서 2~3일정도 자료 조사, 코드 분석을 할 생각이다.

그 이후에는 다음주에 구현되는 API에 대한 기능을 구현하면서 드래그&드롭을 붙여보지 않을까 싶다.

드래그&드롭 기능은 한번도 해본 적 없고 우리가 기획한 거에서는 그걸 자유자재로 활용해야 하는데 그게 가능할지 좀 미지수이다.

+ Recent posts