Docker 를 이용한 CRUD 리뷰(React,express, phpMyadmin)

React를 통해서 CRUD를 구현했다. (디자인은 신경쓰지않고 기능에만 집중했다...)

클라이언트를 구성하는건 어렵지 않았다. 다만 이렇게하고싶다 라는 생각때문에 조금씩 바뀐다.. 

내가 작성한 코드를 처음으로 리뷰해본다.

 

GitHub - JangIkIk/React-TodoList

[프로젝트 구조]

React-TodoList
├─ .gitignore
├─ README.md
├─ backend
│  ├─ .env
│  ├─ express.ts
│  ├─ package-lock.json
│  ├─ package.json
│  └─ tsconfig.json
└─ frontend
   ├─ .env
   ├─ package-lock.json
   ├─ package.json
   ├─ public
   │  └─ index.html
   ├─ src
   │  ├─ App.tsx
   │  ├─ CreateList.tsx
   │  ├─ DeleteList.tsx
   │  ├─ List.tsx
   │  ├─ UpdateList.tsx
   │  ├─ index.css
   │  └─ index.tsx
   └─ tsconfig.json

 

[App.tsx] GET

 

첫화면

기본 UI는 신경쓰지않았다. 말그대로 CRUD만 가능하면 되기때문에...

App.tsx

App.tsx에서  작성하는곳과 리스트 읽는곳을 분류해놓았다. 이번의 CRUD에는 mysql이 목적 이었기때문에 클라이언트는 빠르게 대충 짜야겠다 생각해서 redux를 사용하지 않았고, 살짝 Props drilling을 의도 했다. 그결과 다시한번 상태관리의 중요성을 느꼇다..

 

[CreateList.tsx] POST

CreateList.tsx

제목, 내용은 useState를 활용했고, 사용자가 입력을 하고 작성하기 버튼을 누르면 post_List 함수를 통해 서버측으로 요청을 보냈다.

부모컴포넌트 에서는 Props로 setList를 내려받았는데 이부분은 요청을 보낸후에 UI에 바로 업로드 되지않아서 부모의 useState인 data에 업로드 해주기 위해서다. 이후에는 제목,내용 input창을 다시 초기화 해주고있다.  나는 이러한 부분에서 많은 의문을 가졌다.

POST를 보내고 App.tsx에서 다시 GET요청이 이루어지도록 하여 서버 데이터와의 일관성을 유지해야할까 ?

나는 서버와 통신을 많이하는것을 좋아하지않는다. 학습프로젝트중에 많은 요청으로인해 서버가 닫히는 현상을 봤다. 물론 무료이기때문에 일정 요청을 넘어가서 닫히는 거였지만, 그만큼 불필요한요청 으로인해 서버에 부하가 많이 갔다는 말이다... (프론트인데 서버쪽에 관심이 많다.) 당연히 UI에서 보이는 내용과 틀리다면 통신을 해야겠지만 해당상황은 그런경우가 아니라 불필요한 GET요청은 하지않는것이 좋다고 생각한다.

 

 

[List.tsx] 리스트 Props로 받아 렌더링하기

Props를 받아 렌더링

List.tsx

해당 컴포넌트는 특별한 기능은 없다. 부모컴포넌트 에서 Props를 받아 데이터를 버튼과 함께 렌더링해주고 있고, UpdateList 와 DeleteList 컴포넌트에서 버튼을 클릭했을시 modify에 상태에 따라 버튼변경을 해주고, title, content 는 UpdatList의 수정내용을 받기위해서 사용하고 있다. List_DataSave함수 같은 경우에는 수정을 누르면 각 useState에 정보를 담고 modify에는 list의 id값을 담아
id값에 따라 수정 - 삭제  / 저장 - 취소 버튼으로 다시 바꿔주는 역할을 한다.  수정버튼은 정보를 수정할수 있는 input창을 활성화고, 삭제 버튼은 리스트를 삭제하는 요청을하도록, 저장버튼은 patch요청을 하도록, 취소버튼은 수정을 취소하도록 말이다

수정 버튼을 눌렀을시

[UpdateList.tsx] PATCH

UpdateList.tsx

부모컴포넌트인 List.tsx에서 Props로 받는게 많다. 좋지못한 방법인것은 알고있다. 좀만더 생각하고 했더라면 Props를 두개로 줄일수 있을것 같다. 부모의 setState와 나머지는 객체로 묶어버리던지, 아니면 컴포넌트 구조를 변경한다든지,  redux를 사용해도 좋을것같다. 어차피 목적은 mysql이니 다음 프로젝트에서는 이런식으로 작성하지는 않을거다. update_List 함수 에서는 요청이후에 부모의 useState를 업데이트하는 작업을 하고있는데 편하게 list 를 받아서 업데이트 하면된다. 그러면 Props는 늘어나지만 map을 돌지 않아도 되고 조건문이 필요없이 간단하게 UI를 업데트 할수 있다. 하지만 굳이 부모의 state함수만 받은이유는  왜자꾸 상황이 생각나는지 모르겠지만, 상황을 대입해봣다. 부모컴포넌트에서도 state함수만 존재하고, 상태관리를 사용하기 어려운 상황이라면? 이라는 생각을해서 다른방법을 생각해서 저렇게 작성했다. 프로젝트로 학습을 주로하면서도 많은 상황들을 마주했기때문에 생긴 습관인것 같다.

 

40분 이상 -> 1시간 이상 으로 변경

[DeleteList.tsx] DELETE

Delete.tsx

DeleteList컴포넌트도 크게 다를건 없었다. List컴포넌트에서 List의 Id를 받고, Id를 토대로 쿼리스트링으로 요청을 보낸다.

이후에는 get요청으로 list의 데이터를 가지고있는 App.tsx의 list를 filter함수를 사용해서 삭제된것을 제외한 나머지 list를 다시 UI에 업데이트를 해주고 있다.

 

아직도  공부할게 너무많다...