하고싶은대로##

현백 클스마스. 구경함

낫 밷

신기해요

노란꽃

열매는 언제 열릴까

React.js로 개발을 하다 절대 경로 설정을 추가하게 되었다. TypeScript의 경우 tsconfig.json 파일을, JavaScript의 경우 jsconfig.json 파일만 추가하면 되었기 때문에 그리 어렵지 않게 설정할 수 있었다.

하지만 문제는 절대 경로를 추가하니 eslint에서 문법이 이상하다고 계속 경고를 울렸다.

이 이슈도 좀 유명한 이슈였는지 검색하니 여러 가지 방법이 나왔고, 여러 방법을 시도하던 중 eslint에서 'import/no-unresolved' 옵션을 아래와 같이 설정해주면 된다고 하여 이 이슈도 해결할 수 있었다.

"rules": {
   "import/no-unresolved": [
      2, 
      { "caseSensitive": false }
   ],
   // 또는
    "import/no-unresolved": "off",
}

나 같은 경우 다른 설정은 작동하지 않아 "off"로 해결할 수 있었는데, 이 문제를 해결하는 글들을 읽어보며 "import/no-unresolved"가 정확히 어떤 옵션인지는 설명해주지 않아 나의 호기심을 자극했다.

다행히 GitHub에 이에 관련된 글이 있어, 이 부분을 알 수 있게 되었다. 아래 링크를 첨부하겠다.

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unresolved.md

원글을 읽는 것이 가장 좋겠지만, 시간이 없거나 영어를 잘 못 읽는 분들을 위해 간단히 정리하자면

경로의 파일이 unresolved하는 일이 없도록 하는 옵션인 것 같다. 그래서 이름부터 import/no-unresolved다. 정확히는 import로 가져온 파일 혹은 모듈이 unresolved가 되지 않도록(no)하는 옵션이다.

친절한 이 옵션은 import 뿐만 아니라 require, define 등의 CommonJS 혹은 AMD도 지원을 해준다.

심지어 CommonJS 혹은 AMD를 { commonjs: true/false, amd: true/false } 옵션을 통하여 감지할지 말지를 정해줄 수도 있다!

그리고 한 가지 옵션을 더 설명하자면 "caseSensitive"라는 옵션이 있는데, 파일 경로가 틀린 것을 감지하는 옵션이다.

당연히 기본적으로는 켜져있어서 true이고, 끄고 싶다면 false로 바꾸어주면 된다.

절대 경로의 경우에는 flie system의 실제 경로와 맞지 않기 때문에 lint에서 빨간 밑줄을 띄우게 되고, 이 옵션을 끄게되면 이제 더이상 실제 경로와 틀리다는 경고성 밑줄이 뜨게 되지 않는 것이다.

그리고 또 여러 가지 옵션이 더 있는데, 자세한 사항은 위의 GitHub 링크 들어가서 읽어보면 좋을 것 같다.

다시 한번 더 링크

https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-unresolved.md

의문의 시작

- 개발을 하던 도중, 이 글의 제목과 같은 의문이 생겼다.

- 이 의문이 무엇인지에 대하 간단히 설명하자면 useEffect, useCallback, useMemo, useLayoutoff 같은 hook은 인자로 callback 함수와 deps를 받는다. 이 때 deps에 넣은 값이 변경되면 callback을 다시 실행한다.

- hook의 사용법이나 어떻게 동작하는지 알고 싶다면 관련된 다른 글을 보거나, 아래의 공식 문서를 읽는 것이 도움이 될 것이다.

https://ko.reactjs.org/docs/hooks-reference.html

- 다시 본론으로 돌아가, 이런 의문이 생긴 이유는 hook의 deps에 object를 넣는 일이 생겼다. object를 넣었을때는 어떤 경우에 콜백 함수가 실행될까라는 의문이 들었다. object 내부의 프로퍼티가 바뀌었을때도 감지해서 콜백 함수가 실행될까? 혹은 key, value가 같은 object로 바뀌었을때는 콜백함수가 실행될까라는 의문이 들었다.

- 결론적으로 설명하면, objectA !== objectB가 성립되면 콜백 함수가 실행되었다. 즉 내부의 프로퍼티 변경을 감지하는 것이 아닌 단순히 객체의 주소 값만을 비교하고 달라지면 콜백 함수를 실행하는 것이였다.

- 따라서 당연한 이야기겠지만, 테스트를 해 보았을때 objectState의 프로퍼티를 변경하거나, 프로퍼티를 변경한 후 그 객체를 다시 setState 해줘도 콜백함수는 실행되지 않았다.

동작 원리

- 물론 여기까지만 봐도 짐작으로 deps의 변화를 어떻게 감지하는지 유추가 되지만, 정확히 어떻게 돌아가는지 확인하고 싶어서 찾아보기 시작했다. 처음에는 TypeScript에 정의된 deps의 타입을 찾아보았다. deps의 타입은 dependencyList라고 나오고 배열 안에 값이 들어가는 것만 확인할 수 있었다.

- 그 다음으로 찾아본 것은 React의 GitHub 코드를 찾아보았지만 너무 방대한 나머지 처음에는 찾다 포기를 하였다.

- 이에 관련된 글이 있을까 싶어 찾아보다가 믿음직하고 설명도 잘 되어 있는 글을 찾았다. 바로 netlify의 기술 블로그?였다.

https://www.netlify.com/blog/2019/03/11/deep-dive-how-do-react-hooks-really-work/

- 또한 이 글을 읽고 다시 React 공식 GitHub를 찾아보니 deps의 동작 부분을 확인하고 이해할 수 있었다.

- 결론적으로 얻은 결론은 단순히 새로운 deps 배열과 기존 deps 배열을 for문으로 돌면서 값을 하나하나 비교해서 값이 하나라도 다르다면 콜백 함수를 실행시켜주는 식이였다.

- 그 비교는 단순히 a===b를 통한 비교였고, 따라서 오브젝트의 프로퍼티가 달라지면 그 부분은 확인할 수 없었다.

- 물론 React에서는 불변성을 지키기 위해 오브젝트의 프로퍼티를 바꿀 때는 새로운 오브젝트를 생성하기 때문에 대부분의 경우 이 부분이 문제가 되지는 않을 것이다.

- React 공식 GitHub에서 이러한 동작을 여러 부분에서 확인할 수 있지만, 가장 쉽게 이해할 수 있는 부분은 아마 이 부분인 것 같다.

https://github.com/facebook/react/blob/149b420f63903bcfb99455337a376c75384f86af/packages/react-devtools-shared/src/backend/renderer.js#L1378

<읽기 전 주의> 이 글은 외국 블로그를 퍼온 문익점 글입니다. 읽은 블로그가 틀린 내용을 담고 있다면 이 내용도 틀릴 수 있습니다!

- 출처

https://hackernoon.com/why-import-react-from-react-in-a-functional-component-657aed821f7a

글쓰면서 공식 문서도 참고했으니 틀릴 가능성은 낮을 것 같다... 물론 영어를 잘못 읽었거나 내용을 잘못 이해했다면 틀렸을 가능성도 있으니 출처도 한 번씩 들어가 읽는 걸 추천한다.

궁금해진 이유

- 토이프로젝트를 하기 위해 lint 설정을 처음부터 다시 할 일이 있었는데, lint 설정을 마치니  'React' must be in scope when using JSX 라는 오류가 떴다.

- 이 오류의 원인을 찾아보니 컴포넌트 파일(.jsx) 안에 import React from 'react' 가 빠져있어서 발생하는 오류라고 했다.

- 오류를 보니, 저 줄을 왜 함수형 컴포넌트에는 항상 넣을까라는 궁금증이 들었다. 심지어 이 줄이 없어도 문제 없이 돌아가기는 한다.

- 그래서 이유를 찾아봤고, 이에 대해 정리된 블로그가 있어 번역 및 정리해보았다.

이슈의 원인

- 원인은 바로 BABEL과 JSX이다.

- JSX 엘리먼트는 단지 React.createElement()를 호출하는 편리한 문법에 불과하다.

(공식문서 참조 : https://ko.reactjs.org/docs/react-api.html#creating-react-elements)

- 따라서 BABEL로 JSX인 함수형 컴포넌트를 트랜스파일링하면 React.createElement를 이용한 코드로 변경된다. 그렇기 때문에 React.createElement를 호출하기 위하여 React가 필요한 것이다.

그런데 안써도 된다?

- 하지만 React 17부터는 안써도 된다. 왜냐면 새로운 방법의 JSX 변환을 사용하기 때문이다.

관련 내용 블로그 : https://dev.to/titungdup/you-no-longer-need-to-import-react-from-react-3pbj

공식 문서 : https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

- 따라서 쓰기 귀찮으신 분은 lint 설정을 변경하여 에러를 무시하도록 한 후 React 17 혹은 그 이후의 버젼을 사용하면 된다.

마지막으로 다시 한 번 출처

https://hackernoon.com/why-import-react-from-react-in-a-functional-component-657aed821f7a

https://ko.reactjs.org/docs/react-api.html#creating-react-elements

https://dev.to/titungdup/you-no-longer-need-to-import-react-from-react-3pbj

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

입사할 때 추천 + 선물 받은 책인데, 아직까지 못 읽고 있었다. ㅠㅠ

사실 책 표지가 너무 옛날 책 느낌이라 별로 끌리지 않아 미루고 미루고 있었다..

제목도 뭔가 외국 도서인데 한 2003년에 출시되었는데 번역된 느낌이라서 끌리지 않았는데.. 놀랍게도 한국인 저자에 2018년도 초판 발행이었다.

지금부터라도 천천히 읽으려고 펴봤는데, 내용이 정말 좋아서 정리하려고 한다.

뭔가 부캠에서 마스터(멘토)분들이 많이 해주신 말씀이 있는데, 그 때도 와닿는 내용들이었는데, 지금 보니까 더 강하고 새롭게 와닿아서 이 책 내용들을 읽으며 본 내용 및 내 생각들을 정리해보려한다.

2021/7/20

회고하자.

- 부캠에서 많이 듣고 하던 것들이었는데, 막상 일을 시작하고는 거의 하지 못했다.

- 회고를 하며 내가 하는 일들을 더 개선할 수 있는 방법들을 생각하고 실천해서 다음에 할 땐 실수를 덜 하고, 더 효율적으로 효과적으로 작업을 해야겠다.

즐기자.

- 취업 전에는 취미로 개발을 할 정도로 즐겼는데, 이상하게 취업을 하고 나서는 퇴근하고 개발 공부를 예전만큼 하지는 않는 것 같다.

- 입사 후 3개월까지도 열심히 했는데 뭔가 코로나의 여파인지, 아니면 이제 무의식적으로 일이라고 여겨서인지, 예전만큼 즐기지 못하는 것 같다.

- 일이라고 생각하지말고 예전처럼 즐겨야겠다. (근데 출근할 때는 좀 즐거운데), 이상하게 집에서 할 때는 스트레스를 받는 기분이다. 

- 집에서 개발을 하면 뭔가 일과 삶이 섞이고 무너지는 기분이라서 그런 것 같기도 하다.

- 부캠할 때, 개발은 장거리 마라톤이라고, 그리고 일과 일이 아닌 것을 분리해야한다고, 그래서 재택하더라도 출근/퇴근하는 것처럼 밖을 한바퀴 돌고 들어오라고 하셨는데, 이제 그 말의 의미를 알 것 같다. 

- 취미는 취미로 내버려두고, 전업으로 하고 싶지 않다는 사람들의 말을 이제는 조금은 이해할 수 있을 것 같다.

- 그래도 즐겁게 개발을 지속가능하게, 오래오래할 수 있는 방법을 찾아야 할 것 같다.

발전하자

- A라는 일을 하기 위한 B라는 일을 하고, B라는 일을 개선하기 위한 C라는 일을 하자

- 이 말의 의미를 부캠할 때는 크게 못 느꼈는데, 요즘은 많이 느끼는 것 같다.

- 더 잘하기 위한 방법을 더 잘하기 위한 방법을 더 잘해보자 ㅎㅎ

- 블로그도 이제 좀 다시 써봐야겠다.

2021/7/22

어려운 일을 해라

- 이 말은 어려운 개발을 해라라는 의미보다, 사람들과 소통하는 등의 업무를 하라는 뜻이다. 코파일럿이 나온 지금 더욱더 중요한 말인 것 같은데, 주어진 스펙을 개발하는 개발자가 아니라 요구사항을 분석하고, 요구를 이해하고 오히려 제안하는 등 컴퓨터가 하기 힘든 일을 잘하는게 중요한 것 같다.

- 이말은 간단히 말하면 답이 있는 문제, 측량이 가능한 그런 문제가 아닌, 답이 없는 문제, 측정이 어렵고 당장 눈에는 안 보이지만 어려운 것들을 하라는 말이다.

- 조금은 논점에서 벗어나지만, 이 부분을 읽으면서 예전에 대학생 때 프로젝트하면서 요구하면 '다 해주는 개발자'로 불렸던게 기억난다. 요구사항을 들고오면 다 구현해주었다. 물론 실력이 모자랐기에 아주 깔끔하고 완벽하게 개발해주지는 못했지만...그 때 기억나는게, 돌아가는 예시 사이트를 들고오면 그대로 해주겠다고 했었는데...참 패기로웠던 것 같다.

- 물론 또 다시 생각해보면, 요구사항을 다 들어주지는 않았다. 요구 사항을 들고오고, 예시 사이트를 들고오면, 어떤 부분이 적용되길 바라는지, 왜 이 부분을 넣고 싶은지, 이런 저런 이야기를 해주면서 요구사항을 디벨롭하며 필요 없는 부분은 쳐내고, 필요한 부분은 더 발전시켰던게 생각나서, 나름 잘 살았던 것 같다. 정말로 논점에서 벗어난 이야기인 것 같지만..

계속 의식하면서 일해라

- 이 부분은 더 읽어봐야 알겠지만, 간단하게 말하면 양치질 30년한다고 양치 전문가가 되지 않듯이 의식하면서 일을 해야한다!

2021/10/17

사실 이 책을 다 읽은지는 꽤 되었다. 근데 블로그 관리를 하지 않아서...ㅠ

책 내용이 괜찮아서 나중에 생각날때 다시 읽겠지만 기억나는 요점은 간단히 정리하자면

애자일하게, 결과를 짧게 짧게 낼 수 있도록 하고, 그에 대한 회고를 하며 단점을 보완해서 나아지자! 라는게 이 책의 핵심인 것 같다.

글이 용두사미가 된 것 같은데, 나중에 시간이 나면 더 정리해보아야겠다.