오늘 한 일

  • 으으 예정보다 늦어지는 것 같은데 아무튼 지난 주부터 붙잡고 있던 페이지를 아직 차마 놓아주지 못하고 마무리 작업에 돌입했다. 물론 지금 단계에서야 마무리라고 해도 새로운 기획이 나오면 재시작이지만.
  • 이 페이지를 처음 작업하기 시작했을 때, type 속성이 file인 input을 만들 때 일단 그 못생긴 브라우저 기본 버튼을 숨겨놓고 다른 element를 클릭하면 파일 창이 나오게 했다. 거기서 조금 더 욕심을 냈던 게 라이브러리 없이 drag&drop 기능을 넣는 거였는데, 잘 안 됐었다. 원하는 위치로 파일을 드래그하기만 하면 콘솔창이 온통 새빨개지기 일쑤였다. 그땐 뭐가 문젠지 몰랐었다. 사실 지금도 모른다.
  • 아무튼 그때 알 수 없는 원인으로 실패해버리고 만 그 작업을 오늘 다시 시도해보았다. 지난번과 같은 레퍼런스를 참고하면 또 같은 일이 일어날 것이었으므로 아예 검색부터 새로 하기로 했다. 그리고 참고한 MDN 덕분에 드디어 성공했다.
  • 생각해 보면 이 작업을 처음 시도했을 때는 input을 클릭해서 파일을 넣어서 aws s3로 보내는 기능조차 완성되어 있지 않은 상태였다. 만약 drag&drop이 성공했다 하더라도 input을 클릭해서 파일을 첨부하는 것과 input에 drag&drop 해서 첨부하는 것, 이 두 갈래길을 처음부터 만들어놓고 파일을 가공해야 했을 것이다. 하지만 지금은 이미 클릭으로 파일을 첨부하면 어떻게 처리할지를 모두 정하고, 단순히 파일을 첨부하는 방식만 한 가지 더 추가하는 것이므로 어쨌든 지금이 훨씬 더 나은 방법인 것 같다.

오늘 배운 것

  • MDN의 File drag and drop 링크.
 

File drag and drop - Web APIs | MDN

HTML Drag and Drop interfaces enable web applications to drag and drop files on a web page. This document describes how an application can accept one or more files that are dragged from the underlying platform's file manager and dropped on a web page.

developer.mozilla.org

  • 여기서 나는 dataTransfer를 사용하는 과정에서, 분명히 파일을 첨부했는데도 dataTransfer.files의 length가 0이 나오는 문제를 겪었다. 그건 아래 링크를 참고하고 해결했다. 갓스택오버플로우
 

e.dataTransfer.files.length showing up as 0

I am doing a pretty standard drag and drop feature in HTML5. However, for some reason e.target.dataTransfer showing up as undefined. I am new to javascript. Any help will be appreciated. This is ...

stackoverflow.com

오늘 한 일

  • 아무리 프론트만 해와서 백엔드 서버가 돌아가는 시스템(까지 갈 것도 없다)이나 DB에 관해서는 문외한이라 하더라도 이 정도까지 기본 소양이 부족할 수 있는 걸까 하는 생각에 자괴감이 들었다.
  • 처음에는 비록 리팩토링이 아주 많이 필요할지라도, 시간이 좀 걸려서라도, 어쨌든 결과적으로는 생각한 대로 코드가 잘 짜여져 나간다고 느꼈다. 하지만 한 가지 간과하고 있었던 건, API가 아직 짜여지는 중이라는 것이었다. 그러니까 한 마디로 백엔드 서버와 통신할 수 있는 매개체가 없는 것이다. 뭔가 그 비슷한 역할을 하는 것이 있다 하더라도 그것은 계속해서 변화를 거듭할 것이었고, 절대적일 수는 없었다(사실 이건 어떤 상황에서든?).
  • 프로젝트를 할 때는 다같이 무에서 시작하니 유를 창조해내기 위해 기획부터 시작했고, 기획이 어느 정도 마무리 지어져야 또 다같이 개발이라는 다음 단계를 밟아나가는 식이었다. 하지만 여기는 회사인걸, 모두 다같이 어떻게 무에서 시작할까. 심지어 내가 신입인데! 이미 돌아가고 있는 프로세스를 파악해서 거기에 맞게 단계를 맞춰서 빨리 따라붙든 해야 하는 건데.
  • API가 아직 만들어지고 있다, 라는 말을 처음 들었을 때 이미 상황 파악이 끝났어야 하는 거였고, 그걸 잊어버리거나 간과해서는 안됐다. 이미 DB에 저장되어 있는 데이터의 구조를 파악하기 용이하게끔 DB에 접근할 수 있게 해주셨던 건 말 그대로 '파악'에 중점을 둔 거였고, 내가 DB로 뭔가를 할 필요가 있어서는 아니었다. 원래는 프론트단에서도 DB를 직접 다루는 방식이었지만, 지금은 그렇게 하지 않는 쪽으로 서버가 재개발되고 있었다. 그러니 더더욱 DB에는 손댈 필요가 없다. 기존 코드를 분석하면서 그 흐름을 따라가다 보니 나도 모르게 DB를 만지고 있었던 것 같다. 뭐.. 돌이켜 생각해보니 그렇다.
  • 백엔드와의 첫 협업 프로젝트 때 이런 것들을 포함한 중요하거나 사소한 다양한 부분에서 각종 마찰, 잡음이 있었고 서로를 이해하느라 많은 대화가 필요했었다. 그 많은 대화의 시간들을 통해 우물을 벗어났다고 생각했는데, 고개를 들어보니 그저 더 큰 우물 안이다.

오늘 한 일

  • 사용자가 파일을 첨부하면 해당 파일을 aws s3 버킷에 업로드하는 기능을 붙였다.
  • 현재의 프로덕션 페이지에서는 파일을 첨부하면 즉시 s3에 들어가는데, 첨부한 파일이 사용자가 실제로 제출하기를 원치 않는 것이었다 할지라도 무조건 업로드 된다. 물론 오늘 구현한 기능도 첨부할 파일 목록에서 사용자가 삭제할 수 있는 것까지는 포함하지 않지만, 이것도 언젠가는 추가되어야 하지 않을까 추측해본다.
  • 아무튼 이번에는 사용자가 파일을 첨부하면 파일 데이터를 리덕스에 저장해놨다가, 제출 버튼을 누르면 리덕스에 저장된 데이터를 이용해 그때서야 s3로 넘어가게 했다.

오늘 배운 것

  • 오늘 하루종일 열심히 이용한 SDK란 무엇인가에 관한 링크
 

SDK란?

소프트웨어 개발 키트(Software Development Kit, SDK)는 (일반적으로) 하드웨어 플랫폼, 운영 체제(Operatting System, OS) 또는 프로그래밍 언어 제작사가 제공하는 일련의 툴입니다.

www.redhat.com

  • AWS SDK for JavaScript 링크. 여기서 Uploading a file to an Amazon S3 bucket 항목을 참고했다.
 

Creating and using Amazon S3 buckets - AWS SDK for JavaScript

To create a directory for the object, use the format directoryY_NAME/OBJECT_NAME.

docs.aws.amazon.com

오늘 한 일

  • 어제 기껏 useRef 어쩌고 하며 TIL을 써놓은 게 무색하게, 오늘은 useRef를 적용한 모든 코드를 이벤트 핸들링으로 변경했다. 각 항목에 대한 입력을 마칠 때마다 그 값을 state에 저장하고 싶었기 때문이다. 어차피 서버에 넘길 때 또 가공해야 할 테니 객체에 key-value로 저장하는 게 나을 것 같았다. 이번에는 지금껏 자주 쓰던 onClick, onChange가 아닌, onBlur를 써 봤다. onBlur는 focus를 가졌다가 잃었을 때 작동하는 이벤트 핸들러다. (focus가 있었는데 없었습니다!?)
  • 이벤트 핸들링 얘기가 나와서 말인데, 오전 내내 특정 div에 외부 파일을 드래그하면 div의 모양새(?)가 바뀌게 하는 작업에 매달려 있었다. 그때는 onDragOver를 썼었다. 근데 이게 DB에 있는 항목들을 배열로 받아 input에 넣어 나열하는 상황 때문인지, 파일이 드래그 오버되는 그 div에만 변화를 주는 게 쉽지 않았다. 어쩌면 그냥 내 머리가 안 돌아간 걸 수도 있고.

오늘 배운 것

  • 지금 TIL 작성하면서 찾은 링크인데 진작 이게 있었어야 했다... onDragOver를 찾아 헤맨 과거의 나를 위해 첨부.
 

이벤트 참조 | MDN

DOM 이벤트는 발생한 흥미로운 것을 코드에 알리기 위해 전달됩니다. 각 이벤트는 Event 인터페이스를 기반으로한 객체에 의해 표현되며 발생한 것에 대한 부가적인 정보를 얻는데 사용되는 추가

developer.mozilla.org

오늘 한 일

  • 아직 API도 붙이지 않은(그냥 내가 알아서 원래 있는 API 적당히 갖다 붙여놓고 시험 중인) 페이지만 계속 만지작거렸다. 오늘 안에 끝나지 않을까 싶어서 아침 스크럼 때 그렇게 말했는데 웬걸, 하루 웬종일 시간 다 잡아먹고 결국은 오늘을 넘기게 되었다. 언제나 그랬듯이...
  • 게시판과 같은 종류의 페이지를 만드는 건 여러 프로젝트를 거치며 쉽게 할 수 있다고 생각했는데, 지금껏 해 온 것과는 조금 다른 형태를 다루게 되니 마냥 새롭기만 하다. 회사 일이다 보니 조금 더 신중히 작업하게 되는 것도 같다.
  • DB에 저장된 항목들이 input(text, file)이나 select로 알아서 나열되어야 한다. 당연하게도, DB에 저장된 그 항목들은 언제든지 개수가 늘어날 수도, 줄어들 수도, 내용이 바뀔 수도 있다. 그러다 보니 input과 select가 어떤 순서로 몇 개가 나열될지는 알 수 없다. 그런 상황에서 useRef로 해당 태그의 값들을 가져오고 싶은데, 일일이 선언하자니 말도 안되는 짓인 것 같았다. 만약 input 태그가 극단적으로 많아져서 100개라면!? 1억개라면!? (생활코딩?ㅋㅋㅋ)

오늘 배운 것

  • 그래서 찾아온, useRef의 초깃값을 애초에 배열로 줘버리고 배열로 관리하기 링크.
 

useRef() 여러개 관리 하기

웬만한 컴포넌트에서 거의 다들 useState 혹은 useRef 를 많이 쓸 것이다. useRef로 각각의 input 타입들에 접근해 값을 뽑아내려고 했는데 그 개수가 조금 많았다. const userRef = useRef(); const phoneRef = u..

devilfront.tistory.com

오늘 한 일

  • 본의 아니게 TIL도 주5일제가 되어가고 있다. 주말에 노는 거 너무 티나는데..!?
  • Open door 회의가 있었다. 선이해 후기획, 이런 건 둘째치고 일단 다같이 붙어서 와이어프레임부터 그려보자, 하고 시작한 시간이었다. 피그마는 분명히 튜토리얼 공부를 했었는데 한동안 안 쓰다 보니 새까맣게 잊어버렸고, 단축키 같은 건 버려두고 가장 원시적인 방식으로 '막' 그려버렸다. 다른 분들이 기획과 관련해 열띤 토론을 진행하시는 동안 성미 급한 나는 일단 뭐라도 만들어보려는 생각에 이것저것 끄적여봤는데 칭찬을 해주셔서 매우 민망했다... 어쨌든 결과적으로 진전이 있었던 것 같아 마음이 편하다. 뭔가 되어가는 게 눈에 보여야 속이 시원한 한국인.

오늘 한 일

  • 오우.. 회사에서 하루종일 맥북만 붙잡고 있다가 집에 돌아와서 윈도우를 쓰자니 키보드 단축키부터 헷갈리기 시작한다. 이것이 맥북의 힘인가! 역시 맥북을 사야 하나!
  • 오늘은 어제까지 대강 뷰를 잡아둔 페이지에 실질적으로 DB에 들어 있는 데이터들을 연동하는 작업을 시작했다. DB에 들어가는 데이터에 따라 화면에 나타나는 내용이 달라지는 방식인데, 어제까지 더미 데이터를 씌워놓은 뷰에 갑작스레(?) DB를 얹으려니 처음에 조금 헤맸다. 프로젝트 할 때는 사전에 약속해둔 API 명세를 참고해서 그대로 잘 찍혀 나오는지만 확인해가면서 처리했었는데, 이번에는 API고 뭐고 없다. 그냥 일단 하는 거다.
  • 그러다 보니 어디서부터 시작해야 하는지 조금 막막해져서 한동안 삽질을 계속하다가 어느 순간 정신을 차린 나를 발견할 수 있었다. 오오 이것도 회사의 은총인가요...!
  • 근데 그러다가도 별 희한한 데서 시간을 무지 끌었다. select 태그에서 별도의 option을 선택하지 않아도 처음부터 특정 값을 보여주는, 그러나 사용자가 다른 값을 선택한다면 그걸로 바뀔 수도 있는, 그런 모양새를 만들고 싶었다. option 태그에 selected 속성을 주자니 리액트에서 경고 문구를 띄우며 option에 selected를 주는 대신 select에 value나 defaultValue를 주라고 했다. 그래서 평소 하던 대로 'css select default value' 등으로 구글링했더니, 하나같이 select에 초깃값을 지정해주면서도 사용자의 선택을 허용하고 싶다면 defaultValue 속성을 적용하라는 것이었다. 여기저기서 같은 해결책을 제시하기에 철석같이 믿고 그렇게 했는데 전혀 적용이 안됐다. 한참의 삽질 끝에 설마설마 하며 검색한 결과, select 태그에는 defaultValue 속성이 없다^^ 이 사람들아...

오늘 배운 것

  • 그래서 적는 MDN의 select 태그 정보 링크. 바보같은 나 자신, 진작 검색했어야 했다.
 

요소는 옵션 메뉴를 제공하는 컨트롤을 나타냅니다.

developer.mozilla.org

오늘 한 일

  • 어제 적었듯, 지금 하고 있는 일은 이미 있는 회사의 웹페이지를 클론하는 작업(겸 연습)이다. 비록 무에서 유를 창조하는 류의 개발은 아니지만 어쨌든 회사 일이기에 개인 혹은 팀 프로젝트를 하거나 혼자서 뭔가를 만들어 보는 때와는 그래도 마음가짐이 달라지는 것 같다. 물론, 프로젝트는 대충 해도 된단 건 절대 아니다. 아무튼 코드 한 줄 한 줄 작성하면서 내가 할 수 있는 범위 내에서의 가장 효율적인 방법을 찾게 된다. 예전에는 마음 가는 대로 일단 손가락부터 움직이고 봤다면, 지금은 손에도 뇌가 달려 있는 느낌ㅋㅋㅋ이랄까.. 고민하느라 속도가 더뎌지기도 하지만 능력이 허락하는 한 고민을 거듭하게 되는 건 좋은 일이라고 생각한다. 지금 당장은 부족한 점이 많더라도 고민의 끝에는 발전의 여지가 있다는 뜻이 아닐까. 그게 언제일지는 아무도 모르지만^^
  • 지금껏 나름대로 여러 번의 팀 프로젝트에 참여하면서 기획 단계에서나 API를 구상할 때나, 백엔드 담당이었던 분들과 충분히 소통했다고 생각하고 있었다. 하지만 오늘 API 관련해서 쿼리스트링에 대한 질문을 받았을 때에서야 내가 얼마나 서버와의 통신에 무지했는지를 깨달았다ㅠㅠ 프론트와 백의 경계를 나누는 것 자체가 애매하다손 쳐도, 프론트라고 해서 프론트만 해도 되는 게 아닌 것을.. 죽을 때까지 공부만 해도 모자라겠다.

 

오늘 배운 것

  • 라우팅되는 여러 페이지에서 공통적으로 사용되는 컴포넌트가 있다면 라우팅에서 제외시켜버리면 된다. 예를 들어, 헤더가 여러 페이지에 걸쳐 계속 나타난다면 헤더는 라우팅 범위에서 빼 버리고 나머지 컴포넌트들만 페이지별로 다르게 보이도록 하는 것이다. 어쩌면 당연한 이 작업을, 나는 지금껏 한 번도 시도해본 적이 없었다. 위에서 말한 것처럼, 부족한 내가 회사 덕분에 발전한다..
 

특정 컴포넌트 특정 페이지에서 제거하기

header나 navbar와 같이 모든 페이지에 있어야 하는 컴포넌트가 특정 페이지 (로그인, 회원가입)에는 보여지지 않아야 할 때도 있습니다.props를 이용해 isVisible값과 같은 변수를 이용해 처리할 수 도

velog.io

  • 아이콘을 사용해야 하는 경우 react-icons를 자주 쓰곤 하는데, 이번에도 필요한 형태의 svg 파일을 찾다찾다 결국 마음에 드는 걸 찾지 못하고 돌고 돌아서 react-icons으로 회귀했다. 이걸 쓰지 않으려고 했던 이유 중 하나는 커스터마이징이 잘 안 된다(고 생각했던, 특히 색상 같은 부분)는 거였는데, 사용하려는 아이콘의 원 출처로 링크를 타고 넘어가면 커스터마이징에 관한 문서가 있다. 이것도 참 당연한 수순인데.. 회사만이 너의 눈을 뜨게 하리라. 오늘 찾은 링크를 예시로 들어 붙인다.
 

Ionicons: The premium icon pack for Ionic Framework

Ionicons is an open-sourced and MIT licensed icon pack.

ionic.io

 

내일 할 일

  • 금요일이다! 신나게 코딩하자!

+ Recent posts