1. 데이터 만지기

const arr = [{id:1, name: 'younji', country: "korea"},{id:2, name:'ji', country:"usa"}, {id:3, name:"sera", country:"korea"}]

를 country를 키로 갖게 하기

1. 맨처음 내가 만진 것
const obj = {}
const re = arr.reduce((acc,el)=> obj[el.country] = {...el} ,{})

2. 다시 만진것
const re = arr.reduce((acc,el)=> {acc[el.country] = el;
  return acc} ,{})

회고: 왜 이걸 말 못했지..? 집에서 하니까 이렇게 잘 해결할 수 있는것 왜 면접때는 어버버 forEach, map만 생각했을까 그만큼 내가 reduce에 대해 이해를 못하고 있었던 것 같다. 면접에서 그렇게 괴로울 수가 없었는데 집에서 푸니까 몇 분만에 만져지는거 보고 바보 같다고 생각했음. 어쩌면 생각만하고 실제로 구현하면서 뜯어보는 시간을 갖지 않으면서 이해도가 낮았던 것이 아닌가.. 그만큼 공부가 부족했다.

리듀서 함수는 네 개의 인자를 가진다. 그리고 map같은 경우 원본배열과 같은 길이를 가진 새로운 배열을 반환하지만 reduce는 내가 원하는 대로 길이/구조를 변경 할 수 있다.

1.누산기 (acc) 2.현재 값 (cur) 3.현재 인덱스 (idx) 4.원본 배열 (src)

현재 값들을 돌면서 누산기(만들어질 부분)에 현재의 값들을 더해준다. 이를 1차원적으로 생각하면 1+2+3+4같은걸 해줄 수 있지만, 데이터를 더해줄 수 있는 것이다. 그래서 초기 데이터 구조를 빈객체로 {} 시작해서, 해당 객체에 지역을 키로가지고 배열의 내용물을 값으로 가진 새로운 객체를 만들 수 있다. 초반엔 이 개념이 이해가 안됐었던 것 같다. 그래서 obj을 따로 뺐는데, 딱 집어서 뭐라 말 할 수 없지만, 거슬렸다. 왜 initial에 빈 객체를 넣어줬는데 빈객체를 따로 또 빼줘서 짰지? 라고 생각이 들었다. 그러다 mdn 다시 읽어보고 그럼 이렇게 될 거같은데 하니까 되더라.

2. 리액트의 클로져 활용

리액트 훅은 클로저를 이용한다. 클로저란 함수와 함수가 선언된 렉시컬 환경의 조합으로 1. 내부함수가 외부함수의 변수를 참조하고 있고, 2. 외부함수보다 내부함수의 생명주기가 더 길때 외부함수의 변수값에 접근 할 수 있는 것을 클로저라고 한다.

그럼 어떤게 외부함수고 어떤게 외부함수보다 긴 생명주기를 가진 내부 함수일까? 물론 리액트 내부는 더 복잡하겠지만, 클로저를 이용한다고 했는데 리액트 훅에서 어떻게 사용될까? 얼마나 내가 이해하고 있는가가 궁금해 졌다.

const [value, setValue] = setState("value")
일때 구조분해로 value와 setValue를 빼내주는 거고, setValue함수를 통해 value 상태가 변경되는 것이니
const useState = (() => {
  let state;
  const setState = newState => state = newState;
  return (newState) => {
    setState(newState);
    return [state, setState];
  }
})();
이런 모양이지 않을까?

외부함수의 생명주기가 내부함수보다 짧으려면, 외부함수는 즉시 실행되어야 되는 함수일 것 같다. 그래서 바로 반환 될 수 있도록?

이렇게 하면 클로저로 저장이 되는 것을 확인 할 수 있다. 근데 여기서 이상한 점(?)이 있다.

setValue함수를 통해 state의 값을 변경가능 하지만, value는 const 로 선언되었기 때문에 값을 재할당이 불가능하다. 리액트는 setState함수가 호출되면 내부적으로 리렌더링를 통해 state의 값이 변환되지만, 나는 변환된 값을 새로운 변수에 재할당하지 않고 변환된 값을 확인할 수가 없었다. let으로 쓰면 값이 변경되나 하고 let으로 바꿔봤는데, 똑같이 값이 변경되지 않았다.

왜 그럴까 setState 함수가 호출되더라도 value 변수의 값이 변경되지 않는 이유는 useState 함수가 항상 초기값으로 설정된 state 값을 반환하기 때문이다. 그래서 이것저것 해보다가 결국 그 환경을 기억할 수 있도록 또 클로저로 담을 수 밖에 없었다.

리액트처럼 const [value, setValue] = useState("")에서 value에 계속 변경된 상태를 업데이트 해줄 수가 없었다. 계속 다른 환경을 클로져해서 그 상태를 기억하게 해야됐다. 이 부분은 리액트에서 렌더링관련 무언가가 처리해주는 듯 하다.

좀 더 발전된 형태로 만들면 이런 구조인것 같다. 참고) 클로저를 활용한 상태관리

const useState = (() => {
  let state;
  const getState = () => state;
  const setState = newState => state = newState;
  return (newState) => {
    setState(newState);
    return [getState, setState];
  }
})();

const [state, setState] = useState('before');
console.log(state()); // 'before'
setState('after');
console.log(state()); // 'after'

3. 리액트 왜 써요?

리액트를 왜 쓰냐고 하면 난 무조건 생산성이라고 말을 했다. js와 비교하면 잘쓴다면 js가 더 가볍고, 성능이 더 빠를 수 있다. 실제로 넷플릭스에서 js로 마이그레이션 한 뒤 번들크기가 200kb 줄고, 로딩시간이 더 줄었다고 한다. 참고) 리액트 뭐가 더 빨라요 하지만 React는 중복되는 UI 코드들을 컴포넌트화를 시킬 수 있고 이로 인해 코드의 재사용성이 증가한다. 이는 곧 개발기간 단축과 유지 보수의 용이하다는 것이다.

여기서 질문, UI 컴포넌트화를 말했는데 그러면 페이스북은 어떤 복잡한 UI때문에 리액트를 개발하게 되었을까? 이때 나는 페이스북이 어떻게 생겼는지 기억이 잘 안났다. 너무나 흐릿한 기억속에 있던 페이스북.. 한번 생각을 해보면, 피드가 있고 그리고 메시지창도 있고, 친구들 리스트에 활성유저는 초록불로 온라인임을 알 수 있다. 즉 하나하나 상자속? 하나의 ui 컴포넌트속에 너무나 많은 기능들을 담고 있다. 그래서 로직의 분리가 필요하다고 느낀것일까?

피드만해도 상당한 양의 데이터들을 가져오고 있다. 그런데 친구들 리스트에 있는 활성유저를 온라인임을 체크하는 것은 어떻게 구현이 되고 있을까..? 알기 전에는 몰랐던 질문들을 받았고, 집에서 궁금해서 찾아봤더니 실시간 프레젠테이션 기술인 웹소켓(WebSockets)을 사용하여 구현했다고 한다.

사용자가 로그인하고 페이스북 서비스를 사용하는 동안 웹소켓이 연결되고 사용자의 온라인 상태 정보를 주기적으로 업데이트하고 서버로부터 실시간 업데이트를 받는다고 한다.

상태 정보를 주기적으로... 주기적으로 어떻게 확인하지? 계속 모니터링 하는 것을 어떻게 구현할까.. 그래서 이거때문에 리액트의 필요성이 생겼나 싶기도, 왜냐면 컴포넌트 나누기 쉽고 로직 분리가 되니까. 분리된 데이터 로직에서 계속 요청을 보내고 받고를 실시간으로 할 수 있게 구현되지 않았을까? 만약 이 기능 로직이 분리되지 않고 컴포넌트로 분리되지 않았다면 페이지 자체 부담이 컸을텐데 컴포넌트와 상태로직 분리로 인스턴스화 해서 해당 값에만 상태 영향이 가게 하지 않았나 싶다. 여기에 가상돔을 활용하니 바뀌는 부분만 업데이트 되겠지?

웹소캣은 다뤄보지 않아서 어떻게 연결되는지 모르겠다. 일단 지금 하고 있는 프로젝트 끝나고 상태에 따라 온라인 상태 구현 해보고 싶은 욕심이 있다.

4. SCSS란

스쳐 배우고 실제로 써본 적이 없다. SCSS가 무엇이고, 왜 안쓰는지에 대해 질문을 받았는데 일단 무엇인지부터 설명을 할 수 없었다..

SCSS는 Sassy CSS의 약자로, CSS의 확장된 문법을 제공하는 스타일 시트 언어입니다. SCSS는 CSS의 기능을 확장하여 변수, 중첩 규칙, 믹스인(Mixin), 상속 등의 기능을 제공합니다. 이를 통해 코드의 재사용성을 높이고, 스타일 시트의 유지보수를 용이하게 만들어줍니다.

SCSS는 CSS 전처리기(Preprocessor)로 분류되며, 개발자들이 효율적인 CSS 작성을 돕기 위해 사용됩니다. SCSS 파일은 컴파일러를 통해 일반적인 CSS 파일로 변환되어 웹 페이지에서 사용됩니다. 대부분의 웹 개발 프로젝트에서 SCSS를 사용하면 코드 작성과 유지보수가 더욱 편리해집니다.

요즘에는 SCSS 대신에 CSS-in-JS 라이브러리나 CSS 모듈 등의 접근 방식이 더 많이 사용되고 있습니다. CSS-in-JS는 JavaScript 코드 안에 스타일을 작성하여 컴포넌트와 스타일을 결합하는 방식이며, CSS 모듈은 CSS 클래스 이름을 고유하게 만들어 스타일 충돌을 방지하는 방식입니다.

CSS-in-JS와 CSS 모듈은 JavaScript와 스타일을 함께 작성하기 때문에, 스타일을 동적으로 처리하거나 컴포넌트와의 연결을 더욱 강화할 수 있습니다. 또한, CSS-in-JS와 CSS 모듈은 런타임에서 스타일을 동적으로 생성하거나 모듈화하므로, 브라우저에서 필요한 스타일만 로드하여 최적화된 성능을 제공할 수 있습니다.

그러나 SCSS는 여전히 많은 프로젝트에서 사용되고 있으며, 기존의 CSS 작성 방식에 익숙한 개발자들에게는 여전히 유용한 도구입니다. CSS-in-JS와 CSS 모듈은 SCSS에 비해 새로운 접근 방식이기 때문에, 프로젝트의 요구사항과 개발 팀의 선호도에 따라 선택되는 경우가 많습니다.

라고 한다. 그리고 이걸 다른 친구에게도 물어봤는데 오히려 초기 프로젝트에서는 변동성이 많아서 SCSS을 스타일 컴포넌트보다 선호하기도 한다고 한다. 컴포넌트로 빼면 초기 프로젝트는 자주 바뀌는데 오히려 구조 잡기가 힘들다고 한다. 이 부분은 조금 더 공부가 필요한 듯 싶다.

아무 생각 없이 편해서 스타일 컴포넌트 썼는데 어쩌면 왜 쓰는지도 모르고 썼던게 아닌가 라고 생각이 들었다.

5. API 응답 모양 생각해보기

만약 유저가 ui 모양을 바꾸고 싶다면 어떻게 서버에 어떻게 요청을 보내고 응답값을 받을 수 있을까, 데이터 모양이 어떨까?

그때나는 {[{컴포넌트 아이디, 위치번호},{컴포넌트 아이디, 위치번호},{컴포넌트 아이디, 위치번호}]}이런식으로 생각했는데, 피드백으로 배열에 담기면 안되냐고 물었을때 에? 그럼 어떻게 위치를 담지 했다. 생각해보니 배열자체가 순서를 가지고 있는데 위치를 굳이 컴포넌트 아이디랑 묶어서 저장할 이유가 없었다..ㅋ

왜 배열의 특성을 생각을 못했지..

6. 경우의 수

ㅋㅋㅋㅋ 이건 진짜 할 말없다.. 초등학교때 배우는걸 못풀고~ 알고리즘에서 몇 번 나왔던거 같은데 그때 그냥 공식 찾아보고 알고리즘으로 구현해낸 나 자신이 얼마나 밉던지 왜 이걸 이해할 생각을 안했지? 항상 원리 원리 이유 이유 이러면서 이런것도 이해하고자 한 노력이 없었던 사람 같아서 진짜 창피했다. 약간 사고 정지 상태? 눈앞에 글자가 보이고 글씨를 쓰긴하는데 이게 머리로 쓰는게 아니고 손이 움직이고 있는 상태였다. 사과라고 쓰지만 사과가 무엇인지 인지를 못하고 있는 상태였다.

7. 정렬 알고리즘

정렬 알고리즘 얼마나 많은데!버블정렬, 선택정렬, 삽입정렬, 합병정렬, 퀵정렬 등 얼마나 많게요 결국에 여기서 말한 알고리즘 말고 삽입정렬 비슷하게 말했다. 이건 푼것도 아니다 거의 떠먹여 주셨다. 다시 공부해야겠다. 분명 이해했다고 느끼고 넘어간것들인데 어떻게 이렇게 기초적인것도 대답을 못했을까 이해하고 역시 해보고 체감해야 내 지식이 되는듯하다. 이때 배웠을때 너무나 당연?하다고 생각하고 이해가 돼서(착각이었다) 넘어갔는데

후기

역시나.. 기초는 중요합니다. 생각해보면 기회를 정말 많이 주셨다. 그냥 잘랐어도 됐는데 한시간 반동안 면접 봐주셨으니.. 뭔가 조금만 더 말해봐., 할 수 있어! 이거 못말하겠어? 그럼 이건 어때? 이건 괜찮지? 이런 느낌이었는데 그에 대한 보답을 못한 태도와 대답들이라 면목이 없다. 일단 내가 만든 예상 면접질문에서 나온게 전혀 없었기 때문에 눈앞이 하얘진 상태로 면접을 봤다.

모르는데 어떻게든 설명을 하려고 하니 그 부분에서 정말 힘들고 이것도 대답못하는 내 자신이 밉고.. 마지막에 기가 빨려서 제대로 인사도 못하고 나왔던 부분이 아쉬웠다. 사실 가장 수고스러운 분은 면접관님인데 면접관님에 대한 존중이 멘탈붕괴상태로 흐려졌었던 것같다. 마지막까지 어떻게든 정신 유지하고 잘 봐주시고 포인트 집어주셔서 정말 감사하다고 인사를 드렸어야 하는데 사무실 나와서 좀 정신이 들고 다른건 다 몰라도 마지막 말과 태도 때문에 -100이라고 느꼈음. 마지막까지 정신을 유지하자. 결과는 눈물임 ㅎ

그러고 탈락소식 듣고 뭔가 이번엔 이유를 들을 수 있을것같아서 물어봤는데, 이유는 내가 생각했던 부분이 맞았고 추가로 이런거 해보는거 좋을거 같다 등의 피드백을 얻을 수 있었다. 너무 정성스럽게 써주셔서.. 깜짝 놀랐다.

면접을 보면 는다는데 조금씩 나아지는거 같기도하고? 아직도 시선처리나 정리되지 않은 가벼워 보이는 행동들이 나오지만

예전엔 면접 떨어진적이 거의 없었는데 지금은 100이면 100 다 떨어진다 ㅎ 근데 떨어질만하다. 혼자서는 교정이 어려운거 같아서 나중에 면접 스터디를 해야되나 생각중이다.

보관함은 post api 넣어줘야 만질 수 있을것 같아서 아직 안만졌다. 어차피 이건 리스트로 쭉 나오기만하면되니까 별로 안걸릴듯하다.

지금은 mock으로 일단 구현만 해놔서 다음주에 api 제대로 만지고 최적화 좀 하고 .. 하 기쁨의 눈물 한방울..

만질수록 비동기 처리가 걱정된다. ㅋㅋ

유저 최적화 하는 서비스들 보면 그 뒤에 얼마나 많은 코드들이 있을까.. 유저 최적화가 되지 않은 서비스인데도 api 처리가 이렇게 복잡한데ㅠ, 유저 최적화하려면 유저 정보모아서 계속 필터 걸어주고 다시 fetch해주고 유저가 클릭하거나 검색하거나 등등 이런 액션 있을때마다 어떻게 효율적으로 최적화가 이루어지지??

예전에 테크면접에서 비동기 처리가 왜 중요하냐고 물어보셨을때, 화면에 흰화면만 보이면 유저경험에 좋지 않다 이런식으로 답변했었는데, 그때 추가적으로 설명해주신 부분이 복잡한 데이터들을 전달할 수 있어졌고, 데이터도 많아지면서 비동기 역할이 커져서 그렇다고 말씀 주셨다.

그때는 내 대답과 추가 답변에 대한 미묘한 차이가 있던 추가 설명이 와 닿지 않았는데, 직접 이런 많은 데이터들을 만져보니 그 말이 이제 몸으로 와닿는다.

왜 갑자기 php 시절이 다시 뜨는지, 물론 상위호환 버전이지만, 갑자기 client side에서 다시 sever side로 다시 추세가 기우는지 조금이나마 알 수 있었다.

아마 다음주에 본격적으로 api만지면 더 깊게 이해하겠지

여기까지~! 완성된 내 뮤직앱 ㅠ https://drive.google.com/file/d/1KQ1VgB-72Qv1NnzIE2ExqtQ-tmMF_uRh/view?usp=sharing

노래리스트 텍스트잘리는 부분이 안맞네.. 내일 고쳐야지.. 오늘은 여기까지~

같은 컴포넌트 활용하기

인트로 페이지에 이렇게 한줄로 앨범들이 나오는걸 그대로

이 아티스트 페이지에 가져오려했다. 근데 프로퍼티가 다르다..

const NomalSlid = ({ isLogin, title, substring, width, genre, func }) => {
  const { list, isLoading } = useGetApi({ func: func, api: genre, isLogin });

  if (isLoading) {
    return <div>Loading...</div>; // 로딩 중일 때 표시할 내용
  }

  return (
    <>
      <STitle style={{ margin: "5px" }}>{title}</STitle>
      <div
        style={{
          margin: "0 -20px",
        }}
      >
        <SContainerX style={{ margin: "0 -4px" }}>
          {list &&
            list.map((el) => (
              <OneRowGrid
                width={width}
                key={el.album.id}
                src={el.album.images[1].url}
              >
                <SText marginTop={1}>
                  {el.name.length > substring
                    ? el.name.substring(0, substring) + " ..."
                    : el.name}
                </SText>

                <SText marginTop={0} color={theme.subFontColor}>
                  {el.artists[0].name > substring
                    ? el.artists[0].name.substring(0, substring) + " ..."
                    : el.artists[0].name}
                </SText>
              </OneRowGrid>
            ))}
        </SContainerX>
      </div>
    </>
  );
};

export default NomalSlid;

이렇게 받은 데이터를 map으로 펴줘서 el.name, el.album 이렇게 프로퍼티를 빼주는데, 아티스트 페이지에서 fetch되는 api가 주는 응답값 데이터 구조가 달라서 이게 안맞다. 그렇다고 해서 똑같은 레이아웃인데 따로 만들어주는게 맞나..? 해서 요소들을 || 로 한다해도 그러면 케이스를 수동으로 늘리는거 같고, 중요한건 작동이 안됐다.

단계를 한 번 더 나눠주면 될거 같은데 한 단계 위에서 데이터 처리해서 내려주고, 디자인은 계속 재활용 할 수 있도록

근데 문제는 이걸 어떻게 단계를 나눠주냐고,. map으로 펼쳐주기전에 데이터 정리해주고 안에 컴포넌트에서 정리된 데이터 내려주면 될거같은데 생각을 좀 더 해봐야겠다. 붙잡고있다가 다른것들 진도가 안나가서 결국엔 그냥 하나 더 만들어버렸다. 아~~ 될 거 같은데!!

긴 구글링이 필요한 시점.. 일단 구현하고 정리해볼게요~~

그렇게 쓰려고 노력하던 도중,,

그렇게 공유하는거 합칠라고 노력하던 도중.. 여기 저기 문제가 튀어나오게 되는데.. 모든 디자인 요소가 데이터랑 묶여서, 데이터 처리해주는 부분은 커스텀 훅으로 처리했는데.. 그러면서 뭔가 과정이 길어졌나?

디자인 컴포넌트 안에서 이런식으로 좀 조작을 했는데

 {el.name.length > substring
                        ? el.name.substring(0, substring + " ...")
                        : el.name}

어떤건 적용됐다가 어떤건 안됐다가한다. 아예 안되는것도 아니고 되는것도 아니여.. ㅋㅋㅋ 연산이 들어가는 부분만 처리가 안된다. 예를 들면 substring(0,16 + "...")일때 연산이 필요한 17글자이상일때 안됐다. 근데 보니까 내가 잘못썼네,,ㅎㅎ 계속 만지면서 오타가 생겼나보다. el.artists[0].name.substring(0, substring) + " ..." 이렇게 넣어주니까 갑자기 동작 잘됩니다.

오타 조심하자... 렌더링 중 연산관련 문제인줄 알았는데 이럴수가.

그렇게 우여곡절 속에서

아티스트/앨범 퍼블리싱 완성 ㅋ 욕심은 아티스트 페이지에 리스트 4개 넣어주고 4개 넘어가면 옆 열로 넘어가게 하고싶은데, 지금도 api가 엄청 복잡해서 일단 여기까지만 구현하는걸로. 리스트 넣어주려면 또 다른 api받아서 재생까지 되게 해야함 ㅠ 아티스트에서 앨범만 보여주고 앨범으로 링크 꽂아서 앨범 페이지에서 노래 재생하도록 해야겠다.

지금 하트 누르면 보관함에 post보내서 저장해줘야되는데 이부분은 아직 구현이 아직 안되어있다.

앞으로의 진행상황들

진짜 api지옥이다ㅠ., mock으로만 하고 있는데도 너무 복잡하다. 여기에 페이지 네이션까지 심지어 한 페이지에 한 페이지네이션이아니고 컴포넌트마다 페이지네이션 들어가야돼서 지금 눈물 한방울 흘리고 있음..

새삼 스포티파이나 애플 뮤직이 간단한 ui로 나를 얼마나 속였는지 깨닮음 이렇게 복잡하다니.. ㅋㅋㅋㅋ 뒤에서 이렇게 많은 작업들이 이루어지고 있다니~

상태관리 라이브러리에 api 넣어주면서 클릭할때마다 fetch하게 해야된다. api가 페이지를 넘나들어서.. 그리고 노래는 풋터로 넘겨줘야 돼서 이것도 저장해야되고 로그인은 약간 고민이다. 이것도 리액트 쿼리랑 라이브러리 연결해서 3600초마다 새로운 토큰 받도록 짜줘야되는데 어제 하루종일 이거하다가 머리 쥐났다.

어? 되나 하면 컴포넌트에서만 사용가능한 훅이라하고 뭐만 하면 이렇게 사용하면 안된다고 그렇게 알림을 주더라고 ..^^ 아직도 완성 못함ㅎ

어차피 다음주에 리액트 쿼리랑 쥬스탄드 넣으면서 api관련한건 다 갈아엎을거 같아서 소극적으로 퍼블리싱 할 정도만 짜는중

이제 보관함, 지금듣기, 노래페이지 남았다. 그리고 페이지 연결? 보관함은 리스트 형식이라 얼마 안걸린거 같고, 지금듣기도 있던 컴포넌트 활용하면 금방일거 같다. 문제는 노래페이지인데 처음해봐서 노래 상태? 스탑/재생/얼마나 재생되었는지? 이런거 를 어떻게 구현해야 할지 .. 가 살짝 걱정된다.

일단 목표 이번주까지 퍼블리싱 완료 - 진행상황 80% 다음주까지 api 연결 - 리액트쿼리, 쥬스탄드 연결 + jest 다시 배우기 다다음주에 ci/cd 구현

이렇게 9월안으로 마무리하는게 목표다.

느낀점

큰 프로젝트라고 생각을 안해봤는데, 역시나.. 해보면 다르다. 크다. 함께도 좋지만 혼자 꽤 큰? 프로젝트 해보는 경험도 좋은것 같다.

스스로 고민할 수 있는 시간이 많이 주어지고 아직 퍼블리싱 단계지만 하면서 과정 좀 보태서 플렉스박스는 Ms.PHd라고 했다라고 할 정도로 이해도가 많이 높아졌다. 예전엔 css가 약해서 레이아웃 구현이 어려웠는데 이제 웬만한건 flex 여기 이렇게 들어가고 밑에 이렇게 들어가고 묶고 하면 이렇게 나오겠네하고 하면 진짜 레이아웃이 그렇게 나옴.(신기)

디자인 시스템, 헤드리스 컴포넌트에 고민을 많이 해볼 수 있었고 (아직 갈길 너무 멀지만) 그런 고민할 수 있는 시간이 주어진다는게 값지다고 느꼈음. 프로젝트 끝나면 관련 책이나 블로그 같은거 좀 읽으면서 탐구하고 싶다.

다음주에 비동기작업 만질때는 또 어떤 고난을 나에게 주려나.. ㅋㅋ 괴롭지만 기대도 됨. Fr

에러처리

api 받는데 당연히 이미지 데이터가 있다고 생각했나보다. 몇개 어떻게 받지 하고 봤을때도 다 이미지가 있었어서 왜 없다고 하지??? 내가 잘못 접근했나 몇번이나 본지 모른다. 그러다 아!! 유명하지 않은 아티스트는 이미지가 없구나.. 즉 이미지가 있거나 없거나.. 그중 없는거 때문에 에러가 떴었다. el.images[1].url로 있으면 랜더링 해줘 했는데 이것도 오류가 났다. 보니 애초에 images[1] 프로퍼티가 없어서 그 안의 데이터인 url까지 접근하면 에러가 났다. 그래서 el.images[1] 이렇게 바꿔주니 해결

filter?

필터라 해야되나.. 애플 뮤직보면 앨범, 트랙, 가수가 섹션별로 나뉘지 않고 합쳐져서 나온다. 그리고 인기기준으로 나뉘는데 이걸 나도 구현하고 싶어서 앨범이면 네모난 이미지, 아티스트면 동그란 이미지로 했는데 spotify는 인기 프로퍼티가 없었다. 그래서 할거면 내가 임의로 ramdom하게 섞어줘야하는데 이건 정말 퍼블리싱을 위한 거 같아서 차라리 아티스트랑 앨범 섹션을 나눠버렸다.

그리고 문제 발생

이미지 크기가 이상하다.

이미지가 왜이러지..? 갑자기 나누자 마자 지 맘대로 동그라미 크기가 달라진다. 앨범은 안그러는데 아티스트가 문제다. 대략적인 짐작은 이미지 만져주는 과정이 길어져서 그런거 같다. 위에서 나눠주고 이거는 이런거, 저거는 저런거 이렇게 가야 되는데, 먼저 받고 이미지 렌더링 해야되는데 그와중에 덩어리내리고 덩어리가 이거야 저거야? 이렇게 처리하는 방식으로 해서 렌더링 타이밍이랑 안맞는거 같다. 컴포넌트 따로 만들고 상위 컴포넌트에서 제어하면 해결될것 같은 느낌?

근데 이거 전에도 이거랑 비슷한 문제가 발생했다. 와이드 리스트 슬라이드에서 5로 나누어 떨어지는 인덱스+1만 밑줄이 가게 했는데 이 밑줄이 그어진 요소도 있고 안그어진 요소도 있고 그렇다. 이것도 렌더링중에 계산해야되면서 타이밍이 안맞는거 같다.는 느낌

이거 두개 해결과제임. 아티스트 동그란 이미지는 금방해결 될거 같은데 (이건 컴포넌트만 나눠줘서 상위에서 제어하면 될거같다. 원래는 하나의 컴포넌트에서 덩어리 내려주고 덩어리가 이거야 저거야로 밑에서 제어했음)

문제는 밑줄이다.. 이건 컴포넌트를 나눠줄수도 없고 하 밖에 div에 bottom만 밑줄치면 줄이 한 열로 나누어져서 - - - 이렇게 나와야되는데 밑줄이 쭉 이어져서 이것도 안된다. 무조건 5행 채워지는 마지막 요소에 줄을 넣어야되는데 계속 뭔가 타이밍이 안맞아서 됐다 안됐다한다. 이거 어떻게 하지?

디자인 시스템

그전까지는 디자인 시스템 중요성에 대해 별 생각 없었는데, 레이아웃이 복잡하고, 겹치거나 비슷한 요소가 많아지니까 왜 그렇게 개발자들이 디자인 시스템 디자인 시스템 하는지 이해할 것 같다. 구현 때문에 먼저 테스트하느라 작성하다가도 겹치는 코드보면 아... 왜 내가 똑같은 코드 또 쓰고 있지.... 이 생각밖에 안든다.

초반엔 이게 되나?하면서 테스트 목적이 더 크다보니 그 생각하면서도 정리 안했는데, 지금은 바로 겹칠거 같은거 정리하면서 하니까 편하다 바로바로 똑같은 디자인이면 가져와서 기능만 다르게 해주면 되니까. 그리고 제일 좋은건 섞어서 쓸 수 있는거 ㅎㅎㅎㅎ 밖에 레이아웃이랑 안에 요소들이랑 다 따로 만들어놨더니 레이아웃+요소로 넣어서 다른 레이아웃으로 여러개 만들 수 있다. 아직은 익숙치 않아서? 디자인 컴포넌트 나누는 기준이 들쑥날쑥한데 연습하면 괜찮아지겠지

걱정

하.. 검색 페이지 심란하다. 최대한 담백하게 하려고 했는데도 심란하다. 검색전엔 카테고리 랜더링 해야되고 카테고리 누르면 관련 트랙들 받아된다. 그리고 단어 검색후엔 앨범/아티스트 받아서 랜더링 해야되고 이후 앨범/아티스트 누르면 앨범/아티스트 받고 이후 노래 누르면 노래 받아야되고, 그중 좋아요 누르면 플레이리스트에 담겨야됨, 대체 api 통신 몇개야 나 울어 ㅠ 비동기 진짜 최적화 너무 필요해.. 테스트로 mock으로만 하고있는데도 버벅버벅 난리도 아닙니다..

대체 애플뮤직 검색하기도 전에 관련 검색어 찍어서 렌더링을 어떻게 그렇게 빨리하는거지? 사람 마음을 읽나? 일단 이번주 안으로 전 페이지 퍼블리싱 끝내고 (아직 5페이지 남음ㅎ ㅠ) 다음주에 api 달려야겠다. 이때부터가 진짜 불지옥시작임니다..

이때부터는 쥬스탄드랑 리액트 쿼리 본격적으로 배워서 적용해야됨, 로그인까지는 상태관리 라이브러리 안써도 될거 같다고 생각했는데 노래 넘겨주는게 빅프라브럼~

없으면 프랍 진짜 복잡하게 왔다갔다 할거 같다. api만 4-5개 타는데 컴포넌트는 몇개나 타게요? 그 와중에 최상위 밑에 있는 헤더 (부모부모부모부모,..의 형제)에 노래 이미지나 제목 등 데이터 요소 전달하려면 상상만으로도 갑자기 머리아플라 했으나 없어도 될거같기도하고 될거 같은데, 디자인 시스템으로 나눈거 생각하니까 생각보다 프롭 많이 안탈거 같은데,

일단 담주에 생각해 볼게요~~ 그전엔 퍼블리싱이랑 리팩토링 좀 해놓을게요.. 커스텀 훅으로 뺄것도 좀 정리 하고.. 미루다가 계속 안하고 있었음 ㅎ ㅠ 이번주안으로 할 수 있는거 다 끝내놔야지(라고 다짐해 본다.)

열정~ 열정~ 열정~ @.@

padding 맞추기

원하던데로 처음엔 여백이 있음, 가로슬라이드할때 여백사라짐, 마지막 요소엔 여백있음 을 구현했다. 이미 구현해놓고 어떻게 하지 이러고 있었음..ㅋㅋㅋ..ㅠ div 두번 감싸주니까 원하던데로 되더라. 근데 맨처음에 기본 스타일 적용 reset하고 시작했어야하는데 그냥 시작해서, div 자체에 마진이 먹는거 같다 2px정도?

스타일 적용전엔 밑에 노래하단바 사진이랑 콘텐츠의 사진들의 여백이 똑같이 적용됐는데 div로 감싸니까 살짝 어긋났다. 뭐 이건 다시 리셋해주던지..(지금 생각난 김에 해봤는데 안되네..?ㅋㅋㅋㅋ ㅠㅠ) 좀 찾아봐야겠다.

<SContainer ref={containerRef}> //스크롤 생기는요소
      <div style={{ margin: "30px 0 120px 0" }}>
        <STitle style={{ marginBottom: "30px", fontSize: "30px" }}>
          Look! what's going on👀
        </STitle>
        <div
          style={{
            margin: "0 -20px",
          }}
        >
          <SContainerX
            style={{ padding: "0 20px", display: "flex", overflow: "auto" }}
          >
            {list &&
              list.map((el) => (
                <TwoColGrid
                  width="335"
                  height="200"
                  releaseDate={el.album.release_date}
                  key={el.album.id}
                  onClick={() => onRecommandDetail(access_token, el.href)}
                  src={el.album.images[1].url}
                >
                  <SText marginTop={1} fontSize="24px" fontWeight={600}>
                    {el.name.length > 23
                      ? el.name.substring(0, 23) + " ..."
                      : el.name}
                  </SText>
                  <SText marginTop={0} color={theme.subFontColor}>
                    {el.artists[0].name > 40
                      ? el.artists[0].name.substring(0, 40) + " ..."
                      : el.artists[0].name}
                  </SText>
                </TwoColGrid>
              ))}
          </SContainerX>
        </div>
     </SContainer>

이런식으로 플렉스 컨테이너 밖 컨테이너에 원래 들어가있던 마진값을 빼줘서 전체 width로 보이게 하고 그 다음에 플렉스 컨테이너에 padding을 넣어줬다. 이렇게 하면 처음엔 왼쪽에 여백이 있다가 가로로 슬라이드를 넘기면 전체 화면안에서 슬라이드된다. 그리고 마지막 요소에는 오른쪽에 여백이 적용된다.

여기서 싫은 상황 발생.. 지금 이 똑같은 레이아웃이 계속 반복돼서 컴포넌트로 빼줘서 정리하려고 한다. 하면서 정리했어야되는데 구현에 빠져서 막하다가 정리할거 넘쳐남..ㅠㅠ

헤더 상태

스크롤에 따라 헤더가 보였다가 안보였다가 하고 싶었다. 맨처음엔 스크롤은 감지하는데 offsetY가 계속 0으로 찍혀서 상태값 변화가 없었다.

여기서 약간 헤맸는데, 내가 맨처음 레이아웃 잡을때 헤더 고정이어서 안에 요소에 스크롤주고 페이지에 스크롤을 안주게 막아놔서 .. 스크롤은 감지하는데 offsetY는 계속 0인 것이었다.. 그래서 스크롤이 생기는 요소에 ref를 걸어주고 감지하니 잡혔다.

그리고 이거를 app에서 모든 페이지마다 감지시켜주기 싫어서 layout에 무식하게 내려버렸더니

또 바뀌는거 감지를 못하길래 내려받는지 보니까 undefined가 떠서 이거때문에 한참 헤매다가 찾아보니까 안된다해서 app에서 내려줬다.. (outlet은 자식요소가 동적으로 들어가니까 알아서 들어가지 않을까? 하는 그런 희망으로..한번 내려봤다..)

그렇게 앱에서 내리고서는 이렇게 잘 반영되더라.

그래도 문제가 있다.. 요소에서 업데이트가 되서 그런가 왜이렇게 상태 업데이트가 느리지..? 한 두세박자 뒤에 업데이트가 된다. 그리고 스크롤이 부드럽고 자연스럽지 않고 무슨 윈도우 98처럼 끊긴다. 하.. 약간 기획이랑 바뀌면서 헤더가 쓸모없긴해서 아예 없애버릴까..도 고민중

세로한번 가로한번 이중 그리드

여기서 약간 눈물 흘릴뻔했는데

보면 세로로 한번 펼쳐주고 5개행이 넘치면 옆에 열로 이동해야된다. 이렇게 1 6 11 2 7 12 3 8 13 4 9 14 5 10 15 하기 전에는 그리드 방향만 뒤집어주면 될거같아서 할 수 있을 거 같았는데, 방향 뒤집는게 안되나?

시도하다가 분명 그리드 요소가 저렇게 생겼었는데 안에 이미지가 1 6 11에만 들어가는 문제가 발생했다. 이때는 배열 map을 내가 한단계 위에서 펼쳐줘서 이 문제가 발생했는데, 단계에 맞게 map을 깔아줬더니 이번엔 옆으로만 123456789 이렇게 펼쳐졌다.

뭔가 될거같은데 계속 안되는 상황이라 구글 뒤져보는데 다 뒤져봐도 내가 원하는데로 순서 떨어지는게 없다.

결국에는

<SContainerX
            style={{
              display: "flex",
              overflow: "auto",
              padding: "5px 20px",
              flexDirection: "row", // 행으로 나열되도록 설정
              flexWrap: "wrap", // 넘치면 다음 열로 넘어가도록 설정
            }}
          >
            <Grid
              templateColumns={`repeat(${Math.ceil(list?.length / 5)}, 1fr)`}
            >
              {list &&
                list.map((el, i) => (
                  <GridItem
                    borderTop={`1px solid rgba(176, 168, 185, ${opacity.heavy})`}
                    borderBottom={
                      (i + 1) % 5 === 0 &&
                      `1px solid rgba(176, 168, 185, ${opacity.heavy})`
                    }
                    width="calc(100vw - 50px);"
                    key={el.album.id}
                    marginRight={3}
                  >

이렇게 강제로? 열로 수학으로 맞춰줬다.. 그래서 순서는 이렇게 됨.. ㅠ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 순위 관련된 부분이 아니라서 이렇게 그냥 아쉽게.. 맞춰줬다..

인간의 욕심

진짜 가볍게 시작한건데 지금 엄청 복잡해졌다.. 원래 이런 추천페이지 하나로 끝내려고 위에 헤더 고정으로 박아놓은거였는데.. 만들다보니 이것도 있어야될거같고 저것도 있어야 될거같고 해서.. 그래도 그런거 치고 목표한거 까진 목표일대로 만들었다.. 이제 한거 좀 정리좀 하고 ㅠㅠ.. 그거 재활용하면 다른 페이지 퍼블리싱은 이것보단 좀 덜 걸릴것 같다.

일단 퍼블리싱에서 더 만지고 싶은 부분은 +헤더 자연스러운 상태변경/스크롤의 부자연 스러움 +노래리스트?섹션은 스크롤 넘김이 덩어리로 떨어져야될거같다. 스크롤그대로 가는게 아니고 이부분 좀 만져야 될거 같고 이정도?

마무리

현재까지 만진 상황 최적화가 안되어있어서 뚱땅거리는느낌 ㅋㅋㅋ 컴퓨터가 힘들어해 ㅠ

한페이지에 다른 api호출이 4-5개 정도 동시에 call되고 그 응답을 기반으로 또 call을 해줘야된다. 여튼 비동기가 좀 복잡하게 돌아가기 때문에 사용자가 누를때마다 로딩을 기다리는건 경험에 안좋을 것이라고 판단이 된다. 이에 프레 패치/페이지 네이션/캐시로 유저 경험을 개선시켜야 겠다.

이건 일단 여담이고 지금 직면한 CSS 목표와 문제점들에 대해 알아보자

intro

css 이렇게 복잡하게 갈 생각은 없었는데 레퍼가 애플뮤직이라 나도모르게 복잡하게 구현을 하게 된다.. 애플 뮤직 정말 대단하다.. 사소해서 넘어갔던 부분들.. 막상 구현하려니 와씨 이거 어떻게 했지? 이런거 진짜 많음ㅋㅋ

1. 스크롤 범위 & 스크롤 바 높이 차이

찾아보니, 이건 앱에서는 자유롭게 스크롤바 관련 api를 지원한다. 그래서 화면 높이랑 스크롤 높이가 안맞을 수 있다. 하지만 웹에서는 내장되어 지원하는 기능이 아니기 때문에 기본기능을 틀어서 스크롤관련 라이브러리로 어떻게 어떻게 구현해야된다. 여기에 쓰이는 시간대비 ux/ui의 개선 정도가 큰가.라고 한다면 굉장히 마이너하기 때문에 이 부분은 일단은 스킵하기로했다. 1차 구현후 고도화할때 그때 다시 생각해봐야겠다.

2. 가로 슬라이드

애플 뮤직에서 보면 슬라이드 넘길때 맨처음엔 여백이 들어가있는데 넘기면서 자연스럽게 전체 넓이로 전환된다. 처음에 나도 넓이에 패딩줘서 전체적으로 통일감을 줬다가, 이 부분을 보고 확장된 ui가 더 화면이 꽉차보이고 구성이 좋아보여서 이렇게 바꾸려고 하는데.. 여기서 문제 발생.ㅋ

포인트 1. 처음엔 왼쪽에 기본 여백이 적용된다. 포인트 2. 가로슬라이드를 할때 여백이 사라진다. 포인트 3. 마지막 요소는 오른쪽에 기본 여백이 적용된다.

이렇게 전환되는 게 상당히 어렵다. 이것저것 시도해보는데 문제가 하나씩 있다.

1) flex컨테이너 넓이를 화면보다 크게함 => 왼쪽 여백이 안사라지고 안쪽 슬라이드를 넘어서 전체 페이지에 스크롤이 생기면서 페이지 자체를 스크롤이 된다거나.. 왼쪽 여백까진 ㅇㅋ하겠는데, 페이지자체 가로 스크롤 생기는게 커서 이건 스킵

2) flex컨테이너 넓이를 화면 너비로 고정시키고 flex아이템 1번째랑 마지막 인덱스에만 왼쪽 여백, 오른쪽 여백을 해볼까? => 적용이 안됨. 근데 패딩은 먹어서 아마 컨테이너 한번 더 씌우면 될거같은데.. 일단 체크

3) 전체 컨테이너에 margin 너비를 20px로 줘서 레이아웃을 맞췄는데, 나는 가로슬라이드는 꽉차게 하고 싶음으로 => 요소에 너비 마진을 -20px로 해줬다.

그 결과물

여기서 일단 이부분은 여기까지 마무리하는걸로.. 나머지는 고도화때로.. 넘어가자 ..

현재까지 구현된사항

• 인증 후 토큰 받아오기
• 받은 토큰으로 다른 api 호출하기
• 받은 응답값으로 데이터 뿌려주기
• 추가 해야될거: 뿌려준 데이터중 선택된 데이터에서 다른 api 호출에 필요한 요소 뽑아 새로운 api call
• 생각해 봐야할거 : 1) 데이터 파이프라인, 2) api 콜 모양이 다 비슷함, 순수함수로 api함수 모양을 만져서 재사용성 높게 리팩토링
• 다양한 모바일 기기 interaction
• 넘치는 텍스트 줄바꿈x 후 ... 표기
• 플렉스/그리드 컴포넌트화
• 가로 스크롤
• 세로 스크롤
• 생각해 봐야할거: 1) api 함수와 + 그리드/플렉스 아이템 컴포넌트만 조합을 했더니 밑에 text같은 부분이 지저분하게 떨어지고 전체적으로 코드가 중복이 너무 많이된다. 그리드/플렉스 아이템 + 텍스트로 한번더 묶어주자. 그러면 폴도구조를 어떻게 짜야하지?.. ui 폴더 하나로 퉁쳤는데 ui에서도 단계가 생겨버리니.. 구조 단계를 좀 만들어야겠다. 하나요소/ 하나요소+다른 조합요소/ 로직+디자인 요소 약간 이런느낌으로 점점 커지게 만들면 좋을것 같다.

하소연 타임

와.. 정말 fetch.. ㅋㅋㅋ 그짓말 안보태고 응답 데이터 구조가 진짜 복잡해서 그거 보느라 눈 빠지는줄알았다. 그리고 spotify가 제공해주는 api가 상당히 많아서 정보의 홍수에 빠짐. 그리고 데이터 하나 받는데도 뭐가 그렇게 filter요소가 많은지.. 이미 화면 넘어가서 스크롤 생기면 말다했지 객체 안에 객체 안에 객체 안에 배열 배열안에 객체들과 그 객체안에 또 객체 ㅋㅋㅋㅋㅋ 그래서 뭐 필요한거 가져올라면 map안에 어디집고 어디 집어서 또 맵으로 가져와서 집어주고 ~ 😇.. 재밌다!

추가로 느낀점

css만지면서 앱 배워보고 싶다는 생각? 제공되는 내장 api가 많은거 같다. 웹은 뭔가 투박한데 앱은 전환이나 변이가 자연스럽다. 앱은 되는데 웹은 왜 안뒈? 라이브러리로 어떻게 막 만지면 좀 자연스러워 지려나..

깊게 언어 파는거보다는 다양한 라이브러리/프레임워크 써보는게 나을 것 같다고 조언을 들었다..ㅎ

그래서 리팩토링은 잠쉬 스탑하고 프로젝트를 진행하는데, 간단하게 뮤직 플레이어 만들어볼까..? 하다 만들게 됐다.(전혀 간단하지 않다.) 처음엔 그냥 음악검색 -> 듣기 -> 플레이리스트 저장 정도로 시작해서 라이브러리도 안끼려했는데, 웹이 너무 비어보여서.. ㅎㅎㅎㅎ

이렇게 한 5~6페이지 정도 나오게 기획해봤는데, 은근 packed.. 은근 컴포넌트 단계가 나뉘고 많이 들어가서 zustand설치... 그리고, 뭐만 하면 fetch라 좋다고 소문을 들은 react-query 설치..

인증 구현

일단 spotify open API 를 프론트로만 구현하기에 처음부터 난관에 부딪히게 되는데, 바로 인증이다. 스포티파이 open api docs를 보면 토큰없이 원하는 api만 fetch 할 수 없다. 스포티파이 개발페이지 로그인하고 앱만들어서 거기 있는 클라이언트 ID와 시크릿키로 인증하고 토큰 받아서 그 토큰을 다른 요청마다 헤더에 계속 보내줘야된다.

나는 백엔드 없이 혼자 구현하기 때문에 ..ㅋ env에 시크릿키랑 클라이언트 아이디 넣어주고 로그인 해봤다.

아마 open api라 해서 시도해보려했다가 인증부분에서 백엔드 코드로 작성된 docs뿐이라 스킵한 프론트 분들이 있을것 같아서 코드 함께 첨부해봅니다.

export const onLogin = async () => {
  const authParam = {
    method: "POST",
    headers: {
      "Content-Type": "application/x-www-form-urlencoded",
    },
    body:
      "grant_type=client_credentials&client_id=" +
      import.meta.env.VITE_SPOTIFY_CLIENT_ID +
      "&client_secret=" +
      import.meta.env.VITE_SPOTIFY_CLIENT_SECRET,
  };
  const res = await fetch("https://accounts.spotify.com/api/token", authParam);
  const response = await res.json();
  return response;
};

이렇게 유효한 토큰을 받게 되면 로컬스토리지에 저장하던지, 상태관리 라이브러리에 저장하던지 등등 저장해서 이렇게 api 요청때마다 함께 보내주면 됩니다.

export const onRecommand = async (accessToken) => {
  const categoryParams = {
    method: "GET",
    headers: {
      "Content-Type": "application/json",
      Authorization: "Bearer " + accessToken,
    },
  };
  const RecommandID = await fetch(
    "https://api.spotify.com/v1/browse/categories?country=KR&locale=sv_SE&limit=10&offset=5",
    categoryParams
  );
  const RecommandIDRes = await RecommandID.json();
  return RecommandIDRes.categories.items;
};

여기까진 데이터 잘 받아와지는지 체크정도고 이제 진짜 문제는, 어떻게 효율적으로 이 비동기들을 실행할까 이다.

직면한 문제들

1) 데이터 파이프라인 문제점은 토큰 유효시간은 1시간으로 계속 유효한 토큰을 재발급해줘야한다. 즉 데이터 파이프라인을 고려해봐야한다.

사실 이런 복잡한? 비동기작업을 다루기는 처음인데.,(예: 뭐 클릭하면 fetch된 데이터에서 받은 url과 데이터로 또 fetch해서 다른 데이터 받아야됨) 잘 호출되다가 1시간뒤 유효기간 지난 토큰으로 요청가면 에러가 나겠지요?! ^^

일단 구현 집중적으로 별 생각 다해봤는데 최상위폴더에서 interval로 받는 즉시 3550초 지나면 다시 요청해서 내려줄까? 근데 자동으로 발급해주는거면 이제 필요없어지는 때에도 (캐시된 데이터만 사용한다던가 등) 비용이 드는건데 맞는건가..? 싶기도하고. 뭔가 타이밍을 수기로 3600초 중 50초의 나의 임의의 시간을 남기고 요청하는게 좀 웃기기도 하고, 타이밍 안맞으면 숫자 계속 바꿔가면서 수기로 타이밍 맞출건지? 등 여러 생각이 들었다.

시도할때 에러나면 그때 시도해서 다시 받을까도 생각했지만 이러면 또 로딩이 너무 지연된다. 액션이 있을때마다 새로 받자니 낭비고 흠.. 그렇게 여러 고민을 하다가

react-query를 쓰기로 했다. staleTime으로 시간 지정해서 그때동안 신선한 상태로 만들어주고 정해진 시간이 넘었고, 액션이 있을때 그 시간이 지나면 다시 페칭을 해주니, 유저의 액션과 페칭이 따로 돌거 같다. 이걸로 될거같다.는 1차 생각. (아직 검증은 안됨 이제 해봐야지..)

사실 이전까지는 비동기 작업을 많이 안다뤄봐서 이게 어떤 이점?이 있는지 체감이 잘 안됐는데, docs 읽으면서 해보니까 여태 왜 안썼지??? 라는 생각 뿐이다. 뭐가 이렇게 되는게 많아? 로고도 귀여움 ㅋ

예전에 리덕스 사가의 늪에 헤매던거에 비하면.. 러닝커브가 높진 않다(?), 그리고 물론 리액트 라우터로 loader로 프레패치 가능하긴하지만 로더에는 캐시 기능이 없다. 여튼 둘이 환상의 짝궁(참고링크)이라고 한다. 이 부분은 좀 더 배워봐야되겠다. 오늘 docs 읽기 시작해서..

2) css 관련 초반엔 y2k 감성으로 좀 각지고 테두리 있고 약간은 촌스럽게? 이런거

만들고 싶었는데, 감성이 그게 아닌가보다. y2k하려면 기본적으로 색깔 파레트가 화려한데 그게 안되더라.. 여튼 마음은 y2k 레퍼는 애플뮤직을 보며 혼란스럽게 작업중에 문제가 있었다.

일단 애플 뮤직 처럼 이렇게 플레이바 뒤로 뒤에 컨텐츠가 blur되고, 스크롤은 플레이바 밑으로 안넘어가는걸 볼 수 있다. 즉 스크롤되는 범위와, 스크롤 바의 높이가 다르다. 이거 대체 어떻게 한거지..?

헤더랑, 풋터 고정하고 내용물만 스크롤이 생기게 하는것도 잡는데 너무 오래걸렸다. 그렇게 이것저것 해보면서 겨우 잡은 이후에 풋터 위로만 스크롤이 돌아서 풋터 포지션 fixed로 바꾸니 뒤에 내용물 비치는데 대신 스크롤이 풋터까지 내려왔다. 별거 아니긴 한데.. 스크롤 자체가 어차피 투명도 조절되어있어서 안보이긴 하는데.. 뭔가 애플뮤직처럼 스무스하게 자연스럽게 스크롤이 딱봐도 플레이바 위에서 돌았으면 좋겠다.

그렇게.. 해결방안을 찾는 ing....

추가로 된다면 애플뮤직처럼 컨텐츠가 없어도 어느정도까지 스크롤떰브줄어들면서 스크롤이 당겨졌으면 좋겠다. 앱이라 가능한건가..? 웹에서는 못본거 같기도하고 무한스크롤 비슷한걸로 어떻게 될거같은데.

제일 크게 느낀 점 : 남의 코드 보는게 쉽지 않구나

코드 컨벤션을 어느정도는 맞췄다고 생각했는데, 막상 다른 팀원 코드를 읽으려니 상당히 어렵다.

읽기전에 무의식속에 이렇게 짰겠지란 생각이 있었나보다. 막상 읽어보면 완전 다른 로직이라서 그 사람의 생각을 바닥부터 읽는 느낌이다. 그 사람의 생각을 바닥부터 이해하는건 일상적인 문장에서도 어려운데, 코드는 어떨까…^^.. 하루종일 코드만 보다보면 하루가 끝난다.

일단 중복되는 것들만 정리해서 코드줄만 좀 줄었어도 그래도 조금은 읽기 편하지 않았을까란 생각하기도하고, 똑같은 페이지인데 두개로 나뉘었다거나, 똑같은 컴포넌트인데 하드코딩 되어있다거나 그리고 그 하드코딩 된 코드가 네스팅하다거나 해서 읽기가 아~주 힘들다. ㅠㅠ..

일단 정리먼저 하고있다.. 똑같은것들 컴포넌트로 빼주고 다른부분은 프롭으로 제어하는 정도로, 근데 컴포넌트로 빼다 보니까 로직 똑같은것도 많아서 일단 컴포넌트 정리해주고 로직 분리해주면 더 좋을 것 같다. 그러고나서 좀 목적에 따라 함수나 이런것도 정리를 해줘야될것같다 사이드이펙트가 많아서 갑자기 좀 수정하면 다른거 안되고 그런다. ㅋㅋㅋㅋ ^^.. 미치겠다 ㅎ 일단 욕심부리지 말고 큰거부터 쪼개면서 수정/개선해봐야겠다

이래서 캠프때 코치님이 코드컨벤션만 2달 맞추고, 누가 무엇을 짠지 모르게 다 똑같이 맞춘다는 것이었구나…. 이번에 그 중요성을 알게됐다.

앞으로의 방향

한번에 문제점을 파악하는건 어려울 것 같고(프로젝트 할 땐 나눠서 진행하니 기능이 많은지 몰랐는데, 막상 혼자 진행하려니 기능이 많네..) 단계별로 이슈 생성하고 해결하면서 차근차근 진행해야겠다.

현재 접한 문제

서버가 살아있는 줄 알았는데, 서버가 중단되었다. 몽고DB 권한도 없어서 로컬에서도 테스트가 어렵다. 몽고DB 내걸로 가져올 수 있는 방안을 찾아봐야 할 것 같은데.. 그러면 node랑 몽고DB를 알아야할 것 같다.. . 일단 프론트 딴의 이슈들 먼저 처리한다음에 api 연결되는 부분은 고민을 해봐야 겠다.

1. 의존성 트리문제

아니 이게 뭔데요.. 갑자기? 이후, 해결방법에 대해 안내해주는데 순서대로 진행했는데 해결이 안됐다. 마지막 방법으로 yarn으로 실행하라는 게 있었는데 근본적인 원인파악 없이 yarn 설치로 해결해서 땜빵으로 해결하는게 싫었고 yarn 설치 귀찮아서.. 다른데서 좋다고 설치하라 할때도 그렇게 크게 와닿지 않고 귀찮아서 안했는데 이거때문에 설치하기 싫었다.(이상한 자존심)

이때부터 뭐가 문제야... 하면서 삽질이 시작됐는데,.. 생각해보니 웹팩, 바벨 수동으로 설치하면서 글로벌로 node_module을 깔았나보다. 그래서 글로벌에 있는 웹팩과 프로젝트 내의 웹팩 버전 충돌이 일어난 것 같다. 아니나 다를까 글로벌로 설치된 웹팩버전이 문제되는 버전과 일치하였고, 글로벌에서 node_module 삭제 이후 잘 실행되더라. 휴~~

2. 라이브러리 호환성

아 결국엔 비슷한 결의 문제가 또 일어났다.

처음엔 오류이유를 모르겠어서 sage에 물어봤는데,

내게 버전이 낮은게 아니라서 이건 아니라고 생각이 들었고, 찾아보니 노드 버전 문제 였다.

나는 유튜브나 최신 강의 보면서 비교적 최신 노드 18이 깔려있는데, 이거 전에도 노드 18이랑 호환이 안돼서 문제 되는 적이 있긴했는데 귀찮아서 다른 라이브러리들을 호환되는 걸로 버전 올리면서 해결이 됐었다. 하지만 이번엔 셋팅된 코드로 실험을 할꺼라.. 결국엔 노드 버전 낮췄다.

그러다가 노드 관련해서 개발환경 맞춰야되고 이런 경우가 프로젝트때 있었던 걸로 기억해서 그냥 최신거 삭제하고 다시 까는게 아니고 n플러그인을 설치했다.

자세한 내용은 https://onlydev.tistory.com/114 참고~!

이렇게 뭐 좀 해볼라하는데 셋팅에서 이러면 갑자기 화남 ㅋㅋㅋㅋㅋㅋ 여튼 오늘의 삽질은 그래도 긴 삽질은 아니고 30분정도 걸린거 같다. 휴 이번엔 시간 별로 안잡아먹어서 다행.. 이전에 공부 시작하고 초반에 이런 에러 접할때 셋팅만 두 세시간 했던 경험이 있다. 이런 경험이 다 피와 살이 되는구나..

사실 나는 프론트 엔드를 시작하게 된 이유는 명확했다.(라고 생각했다.)

1) 여러 기술스택이 나와서 계속 무언가를 배울 수 있다. 2) 내가 노력한 결과를 누군가가 알아봐 줄 수 있다. 3) 지식을 공유하고 새로운 가치를 창출 할 수 있다.

로 생각했었는데, 이 답이 충분하지 않다는 것을 알았다.

이건 왜 프론트엔드일까요 가 아닌, 왜 개발자로 전직을 하셨나요?에 더 적합한 답인것 같다.

그렇다면 백엔드니 데브옵스니 등등 많은 분야가 있는데 그중 왜 나는 프론트 엔드의 길을 걷게 되었을까?

1. 유저와의 접점

가장 재밌다고 느낀부분은 유저의 측면에서 기술적으로 어떤 경험을 제공할 수 있을까를 고민할 수 있었던 부분인것 같다.

예를들면, 화면 로딩이 느릴때 그 시간에 따라 유저의 이탈율이 높을까? 답은 당연하게도 yes다.

구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 3초 이상일때 32%, 5초 이상일때 90%, 등 로딩 시간에 따라 이탈율이 급격하게 증가한다. 특히 이 반응은 핀테크 쪽에서 더 예민하게 나타나는 것으로 알고 있다.

성능 개선

그렇다면 1) 성능을 개선하여 로딩시간을 줄이던가, 핀터레스트는 로딩 시간을 40%로 줄이면서 검색 유입률과 가입자수를 15% 늘렸고, COOK은 평균 페이지 로드 시간을 850밀리초로 줄여 세션당 페이지 조회 수를 10% 늘렸고, 이탈률은 7% 감소시켰다.

성능 개선이 어렵다면

2) 불가하다면 어떻게 이탈을 막을 것인가로 나눠볼 수 있을 것이다.

그러면 또 2)에 파생되어 2-1) 사이트가 에러난것처럼, 멈춰진 것으로 느껴짐에서 오는 이탈인지 -> 로딩이 되고 있음을 표시 2-2) 로딩이 되는지는 알지만 언제 로딩될지 모르겠고, 기다림이 힘듬에서 나오는 이탈인지 2-2-0) 심리적인 부분으로 기다림이 짧게 느껴지는 속임수 사용(데이터이외 데이터를 넣을 뼈대인 정적 요소부터 렌더링) 2-2-1) 기다림이라고 안느껴지도록 게임 등 배치

그래서,

이렇게 프론트는 더 나은 사용자 경험을 어떻게 개선할 수 있을 것인가 대한 고민에 관련된 여러 가상의 해결법들을 실제로 실현시켜줄 엔지니어라고 할 수 있을 것 같다. 이로 인해 가입률/전환율을 높이고 이탈률은 낮추어 더 많은 수익 창출에 영향을 미칠 수 있다.

*유저가 있어야 프로덕트가 존재할 수 있다. * 많은 경쟁 프로덕트들 사이에서 어떻게 우리의 프로덕트/브랜드를 유저에게 각인 시킬 수 있을까, 편의성을 제공해 줄 수 있을까를 기술적으로 고민할 수 있는 분야였기 때문에, 다른 분야보다는 프론트를 더 흥미롭다고 느낀 것 같다.

그리고 번외로,

유저에게 접하는 위치이기 때문에, 항상 변동의 가능성이 있기 때문에 확장성, 또는 유지보수가 강조가 되는 것 같다. 검증->보수/확장->검증->보수/확장->..이랄까?

2. 기술중심과 인간중심의 역할의 브릿지

기술 중심의 분야와 인간 중심의 분야의 브릿지로 일명 통역가라고 생각한다. 하나의 목표로 함께 나아가지만 각각의 역할마다 주어지는 롤과 상황 그리고 각 분야에 대한 이해도가 다르며 이로인해 갈등이 빚어지기도 한다.

예를들면 모두 회사의 더 큰 성공을 바라며 마케팅 부서는 데이터를 봤을때 이건 무조건 성공이다!라고 생각하며 몇 십억 예산을 받으려 할때, 재무 부서는 이게 성공가능하다고 생각되어지는 근거가 무엇인지, 타당한지 검증하며 예산 편성에 no를 외칠 수도 있다.

칼이 있으면 방패가 있듯이, 누군가는 공격적으로 전략을 짤때 누군가는 방어적으로 그 전략의 뒷정리를 해준다. 닭과 달걀처럼 부서들은 모두 유기적으로 연결되고 부서특성상 상하위가 있는 것 처럼 보이나 실은 모두 하나의 목표를 향해 달려가는 같은 레벨의 팀일뿐이다.라고 믿는 편이다.

그래서 이런 이해관계가 다르며 빚어지는 갈등을 중재하는 역할을 꽤나 자처하는 편이다.

bm일때

예전에 BM으로 일을하며 중간다리 역할을 많이 했다. 예를 들면, 다른부서에서 이벤트 관련하여 푸시가 내려오는 상황이었는데 이는 디자인팀에 업무가 가야되는 상황이었다. 그때 이미 스케줄이 밀려있던 상황으로 푸시된 오더를 실행할 수가 없었다. 이에 푸시가 현시점에서 합당한지, 어떤부분에서 어느정도로 합당한지 이로인한 기회비용은 무엇인지에 대한 검증 후, 그렇다면 이중 어느부분까지는 실행가능한지 그리고 해당 부분이 실행되면 다른 어떤부분을 잘라야하는지 정리하였다. 이후 정리와 함께 디자인팀에 왜, 무엇을 어떻게에 대해 설명하면서 디자인팀도 납득하며 기꺼이 오케이를 외치며 스케줄을 간신히 맞춘 경험이 있다.

파이널 프로젝트에서

또, 팀프로젝트 진행시 팀원끼리 생각하는 것도 다르고, 프로덕트에 대한 이해도 다르면서 소통이 어려웠던 적이 있다. 하지만 그 말을 카테고리마다 쪼갤 수 있도록, 왜? 무엇을? 어떻게를 각각에게 물어보면 실제로 그들이 어떤 주장을 하는지, 어떤 근거로, 그리고 왜 그 말을 하는지에 대해 좀 더 명확하게 다가갈 수 있다. 그렇게 이해한 바를 토대로 다른이에게 조금 더 풀어서, 범용적인 설명으로 다가가면 그렇게 큰 갈등이 빚어지진 않는것 같다.

한번은 프론트랑 백이랑 소통이 어려웠던 적이 있었는데, 프론트에서 말이 왔다갔다해서 백에서는 그거 기반으로 설계가 바뀌어야되니까 정확하게 말하기를 원했다. 프론트끼리 말이 다른부분을 위와 같이 무엇을, 어떻게, 왜를 정리해보니, 한분은 mvp 이후 추가 확장부분에 대해 이야기하고 있었고, 한분은 현재 mvp 기준으로 이야기를 하고 있었다. 이에 백엔드에 정리해서 초반은 이렇게, 이후 이렇게 될거같다고 전달 하면서 서로간의 오해없이 잘 마무리 되었다.

그래서,

이렇게 서로 이해관계에 따라, 또는 사람마다 이해도에 따라 소통이 어려울때 사이에서 소통을 도와 결과적으로 성과가 잘 나오니 보람도 있더라. 이런 성향이 기술관점인 분야 (백엔드라던지..)와 사람관점인 분야(기획/ux디자인이라던지 ..)사이에서 브릿지 역할을 해주는 프론트 엔드에 더 잘 맞는다고 생각이 들었다.

그리고 나머지는

위에 말했던 것 처럼, 지속적으로 공부를 할 수 있는 환경이라던가, 내 노력을 누군가는 알아봐 줄 수 있는것(반대로 노력을 안하는것 또한 알 수 있다.) 등등 자기 성장과 관련된 이야기들이다.

아직 공부한지 아주 오랜시간이 되진않았지만, 잘 시작한것 같다. 일단 아직은 재밌고 & 재밌고 & 재밌고~

CRACO는 CRA보다 빌드 속도가 더 빨랐는데, 이유는 CRACO가 Webpack과 Babel 설정을 더욱 최적화하여 불필요한 작업을 줄이고, 더욱 최적화된 빌드 결과물을 생성하기 때문이었다.

그럼 웹팩과 바벨만 사용하여 프로젝트를 빌드하면 더 빠를까? 란 생각이 문득 들었는데 보장되진 않는다. 설정을 잘못하거나 최적화하지 않으면 빌드 속도가 느려질 수 있기 때문이다.(모든것은 나의 설정대로~)

뭔가 오기 생기게 한다. 내가 설정한게 더 빨랐으면 좋겠다. 호호.. 어쨋든 웹팩과 바벨에 대한 이해도도 높일겸 웹팩+바벨로 리액트 개발환경 셋팅하기!를 시작해본다.

목표

• 웹팩과 바벨에 대한 이해도를 높인다.
• 프로젝트 커스텀 셋팅에 대한 이해도를 높인다.

순서

1. 프로젝트 생성

 npm init 

먼저 프로젝트를 시작하기 전, 프로젝트 패키지를 초기화하여 생성해주자. 해당 명령어를 입력하면 package.json 파일이 생성된다.

2. babel

 npm install --save-dev @babel/core @babel/cli @babel/preset-env @babel/preset-react

바벨 관련 패키치들을 설치한다.

react는 브라우저가 읽지 못하고 또 최신 문법이 적용된 Java Script도 브라우저마다 지원되는게 다르기 때문에 babel을 이용하여 최신코드 -> 구형코드로 트랜스파일링 해야한다.

• @babel/core : Babel 도구로서 최신 코드를 구형 코드로 옮기는 방법을 알고 있는 도구 내부적으로 core-js 패키지를 활용하는데 core-js는 결국 다수의 폴리필들이 내장된 거대한 패키지다. core-js를 가져오기하면 모든 브라우저에서 작동하는 세상의 모든 JavaScript 기능을 사용할 수 있지만,

  예시로, 나는 지원되지 않는 코드중 프로미스만 쓰는데, 이 지원되지 않는 프로미스가 작동하도록 하기 위해 애 사용하지 않는 수많은 기능이 추가된다. 따라서 core-js/features/promise처럼 필요한 부분만 가져올 수 있게 할 수 있지만, *이는 우리가 수동으로 제어해줘야 한다...... * 그런데 preset-env를 쓰면?!

• @babel/preset-env : 어떤 기능이 어떻게 컴파일링 되는지를 제어하는 사전 설정, @babel/core가 JavaScript 코드를 컴파일할 때, 지정한 환경에서 실행 가능한 코드로 변환하기 위해 필요한 변환을 결정하고 적용하는데, @babel/preset-env는 지정한 환경과 호환되는 최소한의 변환만 적용하므로, 개발자는 수동으로 모든 변환을 설정할 필요가 없음

• ** @babel/cli** : Babel을 cli에서 사용할 수 있도록 하는 도구

• ** @babel/preset-react** : React 애플리케이션을 변환하기 위한 Babel 프리셋. 이 프리셋은 JSX 구문을 JavaScript로 변환하고, React 클래스 및 함수 구성 요소를 생성자 함수 및 createElement 호출로 변환

Babel (공식 문서): https://babeljs.io/docs/en/ babel/preset-env 문서: https://babeljs.io/docs/en/babel-preset-env core-js Docs: https://github.com/zloirock/core-js

3. webpack

npm install --save-dev webpack webpack-cli webpack-dev-server

웹팩과 웹팩 cli, 웹팩 dev server를 설치한다. webpack-cli는 cli에서 웹팩을 사용하기 위한 패키지, webpack-dev-server는 코드를 수정하면 자동으로 메모리상에 재빌드를 해주기 때문에 빠르고 편리한 개발을 도와주는 패키지이다.

npm install --save-dev html-webpack-plugin css-loader style-loader file-loader babel-loader

웹팩 설정에 필요한 로더, 플러그인 패키지들을 설치한다.

• html-webpack-plugin: HTML 파일을 생성하기 위한 플러그. 웹팩에서 빌드된 번들 파일을 자동으로 HTML 파일에 포함시켜주고, HTML 파일을 생성해준다.
  • css-loader: CSS 파일을 해석하고, @import 나 url()과 같은 다른 리소스를 처리하여 CSS 파일을 변환. 이를 통해 JavaScript에서 CSS 파일을 로드할 수 있다.
  • style-loader: 자바스크립트로 변환된 CSS를 동적으로 DOM에 추가하여 스타일을 적용. 이를 통해 CSS를 로드하고 적용할 수 있다.
  • file-loader: 파일을 모듈로 처리하고, 해석 및 빌드할 수 있도록 도와준다. 이를 통해 이미지 파일이나 폰트 파일과 같은 리소스를 로드하고 사용할 수 있다.
  • babel-loader: Webpack에 통합되어 Webpack과 Babel 도구를 연결

babel-loader 문서: https://github.com/babel/babel-loader

4. React

npm install react react-dom

마지막으로 react와 react-dom을 설치하면! 설치할건 다 끝났다. 생각보다 리액트를 동작시키기 위한 패키지가 별로 없다.

• react : JSX를 사용할때 임포트가 필요했음. 17+ 버전부터 생략가능(JSX를 사용할 때, 그것은 호출되는 createElement메소드 가까움)

  1) JSX를 사용하지 않을때
  return React.createElement('div',{},React.createElement('h2',{},"let's go")
  React.createElement(Expense,{items:expenses})
  )
  

2) JSX를 사용할때 return(

const root = ReactDOM.createRoot(document.getElementById("root")); root.render();

## 5. 파일 생성
### 1) webpack.config.js

const path = require('path'); const webpack = require('webpack'); const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = { entry: path.join(dirname, 'src', 'index.jsx'), // index.js가 엔트리면 js로, tsx면 tsx로 맞춰줘야 한다. mode: 'development', //개발모드 만약 프로덕션이면 production으로 output: {//빌드후 아웃풋이 dist폴더에 넣어진다. path: path.resolve(dirname, 'dist'), }, module: { rules: [ { test: /.?(js|jsx)$/, exclude: /node_modules/, use: { loader: 'babel-loader', options: { presets: ['@babel/preset-env', '@babel/preset-react'], //type-script쓴다면 '@babel/preset-typescript'도 설치해서 넣어주고 }, }, resolve: { extensions: ['', '.js', '.jsx'], //확장자도 '.tsx'넣어준다. }, }, { test: /.css$/i, use: ['style-loader', 'css-loader'], }, { test: /.(png|jp(e*)g|svg|gif)$/, use: ['file-loader'], }, ], }, plugins: [ new HtmlWebpackPlugin({ template: path.join(__dirname, 'public', 'index.html'), //HTML 파일을 생성해주는 플러그. template 옵션을 통해 기존에 작성된 HTML 파일을 가져와서 빌드 결과물에 자동으로 삽입 }), new webpack.HotModuleReplacementPlugin(), //코드 수정 시 자동으로 모듈을 교체하여 브라우저의 새로고침 없이도 수정된 결과를 실시간으로 확인할 수 있도록 도와줌 ], devServer: { hot: true, //핫 모듈 리플레이스먼트(Hot Module Replacement)의 기능을 활성화 : 수정된 모듈만 다시 로드하여 빌드 시간을 단축 //참고 : [webpack-dev-server] "hot: true" automatically applies HMR plugin, you don't have to add it manually to your webpack configuration.로 해당 부분 설정안해도 알아서 최적화 해주는 듯 하다. host: 'localhost', port: 3000, },

};

### 2) package.json

//"start": "webpack-dev-server --mode development" 추가

"scripts": { "test": "echo "Error: no test specified" && exit 1", "start": "webpack-dev-server --mode development" },

### 3).babelrc

{ "presets": ["@babel/env", "@babel/preset-react"] }

## 6. 파일구조 및 기본 파일소스
### 1) 파일구조
![](https://velog.velcdn.com/images/savazy_gg/post/5d59f956-6e8f-4aec-9eeb-cc4a67b11d28/image.png)
 _두개 다 열려있어서 헷깔릴까봐 집어주자면, index와 app은 src하위 폴더 component가 아닌 src안에 있다. _

### 2) index.jsx

import React from "react"; import ReactDOM from "react-dom/client"; import App from "./App";

const root = ReactDOM.createRoot(document.getElementById("root")); root.render();

### 3) App.jsx

import React from "react";

const App = () => { return (

export default App;

~

이렇게 설정하고 npm run start하면 개발서버로 잘 보인다~!

느낀점

워낙 프로젝트 셋팅들이 잘 구성되어 있다보니, 생각해보면 babel과 webpack 들은 스쳐지나 들어만 본 것 같다. 사실 최적화와 관련된 부분이 빌드로 번들러가 중요한 역할을 하는데도 말이다. 바벨도 폴리필 등을 지원해주면서 내 코드가 읽히는게 아니고 내 코드 -> 변환 코드가 읽히는건데 말이다. 생각해보면 둘 다 굉장히 코어 역할을 하는데 호로록~ 지나가버린듯 했다. 이번기회에 어떤 역할을 할 수 있는지 알 수 있어서 좋았고, 조금 더 공부해서 최적화까지 커스텀해보고 싶다.

점점 시간이 지날수록 설정 파일들을 만져야 될때가 많아지고 있다. 써보고 싶은 라이브러리, 써보고 싶은 스택 등 섞이고 운영체제 별로도 설정에서 오류가 들쑥날쑥 할 때가 생기는데 그때마다 설정 방법 뒤져가면서 맞춰주고 있다. 그때마다 이번 경험을 토대로 하나씩 하나씩 맞춰보면서 설정에 대한 이해도를 높일 수 있을 것 같다.

처음은 어렵지만, 지나보면 아무것도 아닐때가 올때까지..🍋

친구가 "당장 내라"라고 해서 7월 초부터 꾸준히 하루에 5개정도 지원했다. 근데 잘한 결정인듯하다. 정말 난황이다 난황 하하하

서류합격 승률 : 마른하늘에 날벼락 칠 확률

이렇게 어려울줄 몰랐다.. 문과 취업이 더 힘든줄 알았는데 문과가 더 쉬운듯,.? 한 70개 정도 냈는데 포폴 합격받은곳은 4곳? 근데 이게 참 이상한게 어쩔때는 하루에 두 군데 합격 통보받거나, 처음 지원한 회사에서 합격통보 받는다던지 그래서 정말 좋은 포폴이 아닌 이상 운도 많이 따라주는 듯하다.

첫번째 과제

첫번째 과제를 겪고 정신이 힘들었는데, 이유는 내가 한번도 써보지 않은 스택 또는 익숙하지 않은 스택으로 기술스택이 이미 정해져있어서 과제하는데 눈물 한방울 흘리면서 했다 ㅋ..ㅋㅋㅋ 그리고 바이트만 쓰다가 웹팩 쓰는데 진짜.. 몰랐던거 웹팩은 env파일 동적으로 못가져옴. 와 이거때문에 에러나는데 이유를 몰라서 4-5시간 동안 똑같은 작업함. 해결되고 나서 에러 난 이유가 너무 황당해서 벙쪄 있던 기억이 ..ㅎ..ㅎㅎ

그래도 어찌저찌 이틀정도 걸려서 완성함. 개인적으로 좀 힘든? 과제들이 재미있는듯하다. 동기부여도 많이되고 아직도 배울게 많구나 하는 깨닮음? 침대에 누워있다가도 일어서서 책상에 앉을 힘을 주는듯?

리덕스는 제대로 배워보고 싶었는데 스스로 명분이 안주어져서 기회가 없었는데 이번기회에 다시 배워보고 싶게 동기부여를 과제나 면접때 주셔서 배워보고 싶다고 느꼈다. 이것만으로도 득이지!

여튼 그렇게 운이 좋게 과제까지 합격이 되어서 첫 면접을 보게 되었는데... 가기전에 면접후기 뒤져보는데 기술면접을 별로 안본다고 하길래 약간은 긴장을 풀고 입성했으나 이게 무슨일..? 1시간중 55분은 기술면접 본거 같다 ㅋㅋㅋㅋㅋㅋㅋㅋ 대답 못한것도 몇 개있고, 횡설수설 말한거 많고.. 첫면접이라 너무 정신없이 본거 같아서 아쉬움이 많이 남았다. 그래도 마지막에 칭찬 받았음. 공부기간 짧은데 cs지식이 꽤 있어서 놀랐다고 하하! (하지만 결과는 눈물 한방울..)

근데 테크 면접 원래 이렇게 재밌는거였나..?

면접보는데 추가 보완 설명해주시고 공부하면 좋은것들도 잘 지도해주셔서 재밌게 봤다. 면접보는 중에 깨달은 것들도 많고 집가면서, 집와서 계속 생각하다보니 전에 이해하기 못했던게 갑자기 이해가고!! 테크 면접 재밌는듯?

사실 떨어져도 할 말이 없게 봐서 미련은 없다 그냥 아쉬울뿐.. 더 잘 볼 수 있었는데 하는?

소스코드 은근히 자세히 보시는듯..?

기능구현 호로록 보고 잘 안보실줄알았는데 마지막 질문때 비전공자고, 공부기간이 짧은데 어떤 부분이 긍정적으로 검토가 이루어졌는지 물어봤는데, 로직을 많이 생각한 것 같다 등등 코드관련해서 말씀해 주셨다. (개인적으로 이렇게 누군가 내가 노력한걸? 알아봐줄 수 있다는게 개발자가 되고 싶었던 1번째 이유였다. 그래서 그런지 그런말 듣는데 기분이 너무너무 행복했다.)

근데 아무리 생각해도 내 코드가 아닌걸 보신거 같아서, 처음 과제 관련 질문에서 내가 쓰지 않은 변수명을 말씀주셔서 놀라서 중간에 말끊고(죄송합니다.. 너무 놀라서요 ㅎㅎ..)

"네? 제가요..?"

라고 놀라서 물었는데 맞다고 하셔서 일단 기억이 안난다고하고 죄송하다하고 말씀드렸다. 이때 속으로 별 생각 다했다..

"바뀐게 좋은건가 나쁜건가?" "와 나 원래 떨어졌어야되는데 바뀌어서 붙었나?" 등

왜냐면 과제에서 input필드에 date타입이 있었는데 변수명이 useCalender면 이거 관련한 커스텀훅일텐데 나는 캘린더 따로 뺄 생각을 해본적이 없어서,, input자체를 redux랑 연결시켜서 커스텀훅으로 빼려고 했다가 별로인거 같아서 useRef쓰려다가 생각보다 수정할게 많아서 그냥 제출했는데, useCalender라고 변수명 말씀주셔서 확신했다 내거 진짜 아니라고..

근데 뒤에서 ui관련해서 컴포넌트 뺀거 질문 주시기도 하고 타입스크립 관련해서도 부족한점 말씀 주신부분이 나도 똑같이 짜거나 보완할점이라고 느꼈던 부분이라 사람들 코드짜는거 다 비슷비슷하구나.. 하고 느꼈고, 생각보다 자세히 보시는구나라고 속으로 생각했다. 그런 세세한거 까지 피드백해주시는지는 몰랐어서.. 사실 이거 다 부가적인 일인데 이렇게 지원자 하나하나 코드 봐주시고 피드백주신다는게 너무 감사했다.

내건 아닌것 같지만 그렇지만..

여튼 내 코드가 아닌것 같긴한데 하나하나 다 봐주시고 피드백주시는데 아니라고 우기는 모습은 또 별로인것 같아서, 첫 질문은 공부기간이 짧아서 커스텀훅이랑 함수랑 컴포넌트랑 아직 잘 구분이 안가서 제가 쓰고도 모를때가 많다.

이러면서 횡설수설하면서 기억 안나는척하고 ui관련해서는 그냥 왜 그렇게 짰는지 (또) 횡설수설하면서 답변 드린것 같다. 여기서 좀 꼬인거 같다 얜 지가 짠 코드도 몰라? 이런 생각이 들 수 밖에 없으실 것 같아서 갑자기 정신이 혼미해지면서 굳이 안해도 될 말들을 일명.. 컴포넌트/훅 잘 모른다. 이해가 안간다. 이런말들 굳이 안해도 될거같은데 주저리주저리 늘어놓은 나 자신..

냉수먹고 정신 차리자.

다음에 이런 일이 발생한다면? 왜 내게 아니라고 생각하는지 말씀드리고 아이디나 크로스 체크할만한거로 체크할 것 같다. 기억하네? -> 코드 이해하고 짰구나 로 생각이 연결될 것 같아서 .. 모른다고 그냥 어영부영 넘기는것 보다.. 내게 아니라고 생각한 이유/로직 구현 방식 설명하고 크로스 체크를 했어야하는게 맞는것 같다.

후기

여튼 첫면접이라 그라데이션 당황으로 지나고보니까 진짜 이상하게 면접본듯 ㅋㅋㅋ

굳이? 이런 생각이나 말들 습관되면 안좋은듯.. 면접때 당황하면 진짜 자동완성이에요. 당황해서 음.. 어 .. 이런 어쩌고 저쩌고(대충 좋은기능)이 있는데 안써야 되는 이유가..? 혼자 질문하고 답하고 난리남. 당황하면 말 많고(근데 무슨말인지 모름 횡설수설 ㅋㅋㅋ) 눈동자 흔들리고 리액션이 큰 편인데 나 보면서 웃긴 사람? 산만하다고 느끼셨을듯..ㅠ

그래도 잘 들어주시고 격려해주셔서 속으로 감사 100번함.

하 이렇게 기회를.. 놓쳤습니다. 비전공자는 웁니다.. 비전공자는 물 들어올때 노를 저어야하는데 ... 물이 썰물이라..

아쉽긴하지만 어쩌겠어 이미 지나간일, 여튼 이걸 토대로 더 공부하고 싶은 부분은

• 리덕스/리덕스 사가
• 리액트 웹팩이랑 바벨만으로 프로젝트 셋팅해보기 (완료)
• CI/CD
• 타입스크립트 제네릭타입 적극 활용해보기
• async/await문법, axios말고 promise로 비동기 코드 짜보기
• 그리고 개인적으로 진행하고 있는 프로젝트도 있어서..

이미 이것만으로도 한바구니..후..

react 복습하면서 react native 공부하려고 했는데.. 욕심이 되어버렸다 ..^^*

처음 접해보는 프로그래밍 언어라, 어떻게든 익숙해지려고 클론코딩을 왕창 한다던가 등의 양치기로 공부를 많이 했었다. 그러다보니 어떻게 기능은 동작하는 페이지를 만들지만, 어떤 부분이 어떻기 때문에 코드가 효율성이 떨어지고, 구조를 어떻게 잡으면 더 좋고, 하는 등의 좀 더 깊은 개념을 요구하는 부분이 부족하다고 느꼈다.

프로젝트에서 페이지를 만들면서도 기능은 잘 동작하지만, 마음속으로는 이게 최선인가? 하는 의심이 한구석에 있었다. 최적화 부분은 아직 건들지도 못한 분야기도 하고,

복습 그리고 복습

양적으로는 어떻게 채운것 같지만 지식의 질은 떨어지는것 같아서 현재는 코어자바스크립를 읽으며 유데미에서 자바스크립 강의를 복습하고 있다.

왜 리액트를 더 공부하지 않고 다시 자바스크립트?라고 묻는다면, 리액트 진짜 편한데, 그리고 생태계가 너무 잘되어있어서 라이브러리도 많아서 좋은데, 반대로 그게 싫었다. (응?) 자꾸 편한거 찾게 되니까 뭔가 아직은 나에게 독같은 느낌이랄까 ..?

언제 위기감을 느꼈냐면, 프로젝트 기능 명세서 쓰면서 약간 좀 빈느낌이라 친구한테 아 기능이 좀 빈약한거 같다니까 친구가 너 그럼 라이브러리 쓴거 지우고 니손으로 기능만들어봐. 하는데 헉!! 했다.

그래서 갑자기 이런 느낌? 내가 게임 뉴비라 스탯이 낮은데 현질해서 장비빨로 어떻게 고수 흉내내는 느낌?을 받았다. 그래서 와 이러면 안될것 같다는 생각이 너무 크게 와 닿았다. (이렇게 큰 애들은 찐실력 별로인거 알죠? 원래 야생에서 빡세게 굴러야 찐으로 실력이 오르는데)

그러면서 자바스크립트가 일단 좀 더 자리잡아야되겠다라고 언제 느꼈냐면 어쨋든 리액트는 자바스크립트 기반 라이브러리인데 프로젝트때 404 페이지를 예전에 자바스크립트로 만들어 놓은게 있어서 그거 리액트로 바꿔보기도 하고 재미로 하던거 리액트 -> 자바스크립트로 바꾸려고 하는데 생각보다 바꾸기가 너무 어려웠다... 이때 약간 어..? 이거 좀 아닌거 같은데 라고 느낀 것 같다.

여튼 그러한 이유로.. 기본인 자바스크립트부터 복습하자!로 이어지게 되었다. 원래 넥스트 배워보려했는데 좀 시기상조인거 같아서 배우던거 스탑하고 자바스크립트로..

코어 자바스크립트 읽기

오늘 코어자바스크립를 읽기 시작했다. 여기서 기쁜 포인트가 나타나는데, 사실 코어자바스크립트 처음 접했을때는 정말로 무슨 말인지 몰랐다. 1페이지부터,

메모리가 주솟값이 할당되니, 이게 가변형이니 불변형이니 다 처음 접해보는 용어라 아직은 읽을때가 아닌것 같다하고 덮었던 기억이 있다.

그리고 다시 오늘 책을 펴보니 무슨말인지 이해가 되더라! 살짝 어렵긴하지만, 지식적으로 계속 갈망하고 알고싶었던 부분을 긁어주는 느낌이라 갑자기 책읽는게 재밌었다. 확실히 일단 막 접하고 익숙해진 후 깊게 파기 시작하니 이해가 좀 더 잘가는것 같다.

읽으면서 내가 잘못 알고 있던 부분도 있어서 그런 잘못 알고있던 부분에 대해 정정할 수 있는 기회를 얻은 것 같아 기쁘다. (잘못된 지식을 바로잡을 수 있는 기회가 있다는것은 언제나 소중한것 같다.)

예를들면, obj2.a에 111을 할당했음에도 obj1의 a키도 111 value를 가지는데 이는 객체는 주솟값을 할당하며 일어나는 현상이라고 알고 있었다. 그렇다면 변수는? 변수는 직접할당되는 것으로 알고 있었는데, 변수 또한 주솟값을 할당한다. 다만 변수와 객체의 주솟값 할당 뎁스가 달라서 다른 현상이 일어날뿐.

유데미에서 자바스크립트 복습하기

https://www.udemy.com/course/javascript-zw/ 유데미에서 복습하는 자바스크립트도 굉장히 개념을 깊게 다뤄줘서 다시 배우는 느낌이다. (개인적으로 자바스크립트를 좀 더 깊게 공부하고 싶은, 이미 어느정도 자바스크립트를 아는 사람들에게 정말 완전 추천한다. 명강의..)

강의 초반부터 엔진이나 순수함수와 약간의 리팩토링 개념에 대해 다뤄주어서 놀랐다. 강의 듣고 노션에 적고, 그리고 혼자 인형 앉혀놓고 인형에게 강의해주고 있다. 이렇게 배우면 재밌음 ㅋㅋㅋ (너네들 자바스크립트가 어떤 언어인지 알아?! dynamic interpreted, weakly type 언어야~ 이게 뭔지 알아?? 어떻게 동작하는지 알아?! 엔진이 말이야~ 자 이거에 대해 말해볼사람? 이러고 혼자 질문하고 혼자 답하고 놈 ㅎ)

데이터구조 & 알고리즘

이번주부터는 데이터 구조 & 알고리즘도 같이 들을 예정이다. 사실 코드를 짜면서 계속 알고리즘은 기본으로 따라와줘야하는 기본소양이라는 생각이 계속 들었다. 알고리즘의 재귀나 이진 검색트리 등 뭐 이런 어려운 개념들이 기본소양이라기 보다는 문제에 접근하는 방식을 알고리즘을 통해 차근차근 배워나갈 수 있는 것 같아서 계속 기본적으로 갖춰져야 될 것 같은데 하는 생각이 들었다.

코드를 짜면 어디에 분기점을 두고 어떤 파라미터를 받는 함수를 짜고 안에서 어떤 값을 반환하거나 전역변수에 영향을 주고 이런 논리적으로 접근하고 구조를 짜는게,, 그리고 이런 함수들이 기능단위, 기능 묶은 단위, 페이지 단위 등 점점 커지면 서로 독립성과 연결성을 보며 로직을 짜는게..

알고리즘은 코드를 분류할 수 있게 해주는 기준을 잡을 수 있게 도와주고 최소단위로 그런 문제를 해결하는 방식을 배울 수 있는 것 같아서 계속 알고리즘 배워야지.. 배워야지.. 했던것 같다. 그리고 그런 문제 접근 방식도 그렇지만, 알고리즘을 알면 좀 더 성능을 개선한다던가? 하는 방향에 도움이 될 것 같아서? 그래서 계속 데이터 구조랑 알고리즘에 대해 갈망하는 그런게 있었다.

앞으로는,

트랙을 진행하면서는 언어에 익숙해지기도 너무 바빴을때라 부족한걸 알면서도 넘어간 것들이 많다. 이제 트랙이 마무리되었으니 내가 부족하다고 생각하는 부분에 조금 더 집중하고 프로젝트때 짠 코드를 리팩토링하며 질적으로 향상하는 시간을 가지고 싶다.

그래도 고맙게도 일어서는 법을 알았으니, 걷는 법, 뛰는 법, 수영하는 법 등을 익힐 수 있는 자세가 된 것 같아 기쁘다.

데이터 전달의 타이밍

문제는 메인페이지에서 발생했다.

로그인 -> 토큰이 로컬스토리지에 저장 -> 메인페이지에서 로컬스토리지에 저장된 토큰 디코딩하여 하위 컴포넌트에 디코딩된 토큰값이 필요한 경우 props로 전달 (문제발생)

useEffect에 토큰값을 받아서 상태를 변환해주는 함수가 있었고, dependency는 빈배열로 넣었다. 이때의 생각은 모두 이미 로컬스토리지에 토큰이 저장되어 있는 상태라서 랜더링 될 때 한번만 체크해서 토큰값을 가져오는게 맞다고 생각했다.

이렇게! useEffect(() => 관련함수, [])

그랬더니 props가 잘 내려오는데 이상하게 useEffect안에서 토큰이 안내려오는 것이었다..! 그래서 자꾸 디코딩된 토큰이 객체라서 키값으로 value를 빼와야되는 상황이었는데 자꾸 값이 없어서 해당 값을 못빼내 api에 파라미터로 안들어가는 등의 관련된 오류가 떴다.

그래서 다른 컴포넌트를 일단 다 주석처리하고 token prop받는 하나의 컴포넌트만 살려서 확인을 해봤다. 진짜 안받아지나, console로 전역에는 받아지는지, useEffect 안에서도 받아지는지, 찍어보니 진짜로 useEffect안에서 토큰이 빈 값으로 {} 이렇게 출력이 됐다. 그런데 이상한건 전역에서는 토큰이 받아지는것이었다.

그래서 우리는 아니 컴포넌트 전역에서 토큰이 받아지는데 대체 왜 useEffect 안에서 토큰을 못받을까? 에 대해 열띤 토론을 하게 되었다.

그러고 하나하나 console로 전역컴포넌트 실행, useEffect실행을 쳐가며 실행순서를 보니, 위에서부터 코드 실행되어

1. 전역에 있는 코드 실행
2. 컴포넌트 렌더링
3. useEffect 실행
4. 전역에 있는 코드 실행
5. 나머지 전역에 있는 코드 실행.

즉, props를 받기 전에 useEffect가 실행되며 props을 못받는 것이었다. 우리가 전역에서 props를 받는데 왜 useEffect에서는 안받아지지?라고 생각한 것도 반은 틀린거였다. 전역에서도 처음 코드돌때는 props를 못받고, 두번째 코드돌때 받는 거였으니..

useEffect(() => 관련함수, [token])으로 deps를 token props으로 넣어주니, useEffect안에서도 token값이 잘 받아지는 것을 확인했다. 프론트 3명이서 1시간 동안 함께 고민했는데 결과가 너무 허무해서, 서로 아... 했다.

+6/14 내 페이지에서도 해당 문제로 편지쓰기 버튼을 두번 눌러야 되는 버그가 생겼다. 필수값을 다 입력하고 버튼을 눌러도 다음 동작으로 넘어가지 않고, 한번 더 눌러야 다음 동작인 post를 보내게 되었다.

그리고 그 이후에 내가 잘못눌렀나하고 테스트 해보면 한번만 눌러도 post로 넘어가서 여태 내가 잘못누른지 알았는데, 알고보니 버그였다. 에러가 뜨질 않아서 어느 부분에서 버그가 나온지 정확하게 알 수 없었는데,

console로 어느부분에서 동작이 연결되지 않는지 찾아보니 false -> true로 바뀌어야되는데 클릭을 한다던가, 동작 트리거가 없는이상 자동으로 바뀌지 않는 것이었다.. 그래서 onSuccessSendingStatus가 true가 되면 onHandleOpen()이 실행되어야되는데 핸들오픈이 실행되지 않아서 서버에 post가 되지 않았다.

그래서

useEffect(() => {
    onHandleOpen();
  }, [onSuccessSendingStatus]);

이렇게 함수를 감싸주고 dependency에 값이 변하는 부분을 넣어주니 문제 해결!

버그보고 그러면 true로 바뀌기 전까지 강제로 버튼을 안눌리게 만져줘야하나 고민하고 구조 뜯어 고칠 생각에 아찔했지만, useEffect로 다행히 간단하게 해결..

비동기 몇 개 끼고 컨텍스트관련된 오류나면, 디버깅 시작하기도 전에 일단 머리부여 잡게 된다.

그러고 기도 "아 하나님(무교입니다.) 저에게 왜 이런 시련을..."

명세를 작성할 때보다 코드를 짤때 기능에 대해 더 깊게 생각해보니 명세땐 해서 ~하면 되겠네 했던게 코드에서는 엥??!? 할때가 많다.

특히 전역으로 이루어지는 상태값 영향을 받는 동작들이 많거나, 다른 페이지에 영향을 받거나 등 true, false로 두개로 나누어지는 상태값이어도 true이면서 뭐 일때 ~ 이런식으로 조건이 구체화되어지면 갑자기 수많은 질문들이 생각나기 시작한다. true이고 일때 a 컴포넌트 ui반영 그러면 true인데 ~이고 ~아닐때랑, ~~일때는? 이런식으로 조건들이 다양해진다. 한페이지 작업할때는 사실 그 부분을 잘 못느끼고 페이지안 컴포넌트끼리 연결만 생각하고 내 페이지를 짰었는데, 메인페이지를 도와주다보니 왔다갔다하며 맞춰야 할게 생각보다 많았다.

특히 메인페이지에서 상태값에 따라 컴포넌트가 바뀌고, url도 만져줘야돼서 이때 스크럼 2시간 했다.(내가 말 제일 많았음)

로컬 스토리지와 전역 스토어

사실 이전까지 이 둘의 차이를 크게 느끼진 못했다. 1차 프로젝트때는 자바스크립트를 썼고, 로컬 스토리지로 로그인 유무를 가져왔어서.. 그때는 페이지별로 나뉘니까 코드가 중복된다는 느낌이 없었는데

이번에 리액트로하면서 페이지가 컴포넌트로 나뉘면서 로컬 스토리지로 로그인 유무를 가져오는걸로 코드를 짜니 약간.. 이게 맞나....? 생각이 계속 들었다.

메인페이지에서 로그인 상태에 영향을 받는 컴포넌트가 5개인가? 그래서 메인페이지(상위 컴포넌트)에서 로그인 유무를 체크해서 props로 하위 컴포넌트에 내려줬는데, 헤더에서 문제가 생겼다.

헤더는 메인 페이지 뿐아니고 다른 페이지들과도 이어져서 다른 페이지에서 헤더를 가져오니 로그인 체크가 깨졌다. 로컬스토리지 체크가 또 들어가야되는데 헤더가 내 페이지뿐만아니고 다른 페이지에도 있기 때문에 이게 맞나? 라는 생각이 들은거 같다.

그래서 그럼 메인 페이지로 받아서 프롭을 받는거에서 헤더 빼고 받고 헤더에서 따로 처리할까도 생각했지만 헤더에 로그아웃이 있기 때문에 .. 물론 로그아웃 로컬스토리지 삭제해서 그거 체크해서 반영되긴 하는데.. 아 뭔가 한번에 흐르는 느낌이 아니고 동작하다 말고 다시 체크하고 체크하고 동작하고 이런 느낌이라 계속 이게 맞나? 이런 느낌이 들었다.

여튼 로컬 스토리지 체크관련 코드가 없는 이상 페이지가 다르면 깨지니.. 그래서 app에서 내릴까 하다가 ..

근데 생각해보니 우리 리코일 쓰기로 했는데 왜.. 이렇게 복잡하게 생각하고 있지?

하고 바로 로그인 페이지 하신 분한테 제발 스토어에 저장하면 안되냐고 ㅠㅠ

스토어에 저장하면 필요한데는 내려받음되고, 내려받은 상태값도 상태값 변경되면 바로 반영되니 얼마나 편해ㅠ,, 그림으로 막 그려가면서 왜 로컬스토리지아니고 스토어인지 1시간동안 연설한거 같다..; 불편함을 체감하니까 너무 필요하더라고..

코치님은 전역스토어가 꼭 필요한가를 생각해보라 하셨다. 개인적으로 context api든 상태관리 라이브러리든 전역적으로 영향을 주는 값이 있다면, 둘 중 하나 쓰는것도 나쁘지 않은거 같다.

사실 내 페이지에서 prop이 5단계 왔다갔다 한적 있는데 다른 페이지로 영향을 미치는 상태값이 아니기 때문에 내 페이지 안에서만 처리했다. (물론 속으로 아 리코일쓰는데 그냥 밖에 뺄까? 하고 고민은 했다 ㅋ) 코치님은 내가 속으로 한 고민처럼 코드를 쓰다보면 편하니까 그냥 다 스토어에 넣는 상황을 걱정하셨던것 같다.

개인적으로 페이지 안에서 이루어지는건 최대한 페이지 안에서만 관리하고, 다른 페이지에 영향을 미치는 로그인 유무같은건 전역스토어로 관리하는게 확실히 편하고 깔끔한거 같다. 다만 앱이 무거워지는거 대비 효율이 큰가도 고려해줘야하는 부분인거 같은데, 솔직히 말하면 우리 상품에서는 안써도 무방하다. 페이지도 9페이지 정도 나오고, 전역으로 쓰이는 값이 로그인 유무밖에 없어서 app에서 내려서 props로 처리해도 무방하고, contextAPI로 충분히 처리가능하다. 또는 로컬스토리지 값 가져와서 페이지 또는 컴포넌트 별로 체크해줘도 무리가 없다.

다만 다들 스토어를 써보고 싶어해서 이번기회에 리덕스보다 가볍고, 러닝커브가 적은 리코일로 스토어를 써봤다. 이렇게 쓰기로 했는데 안쓰면 억울하자나??!

어쨌든, 그렇게 스토어 쓰기로 하니 너무 편하고 바로 해결 ^^! 하하핫! -> 메인페이지에서 스토어에서 내려받고 (컴포넌트 안에서 하나하나 받기 귀찮아서..) 헤더에서는 따로 스토어받고, 로그아웃시 로컬스토리지 토큰 삭제, 스토어 상태값 변경하였다.

URL 관리

메인페이지에서 링크를 타고 온 사람들은 main/난수값(고유한 값)을 가진다. 해당 난수는 링크를 보낸 사람의 페이지에 접근할 수 있게 한다. 여기서 로그인한 사람은 main/아이디 로 바꾸자고 해서 갑자기 머리 아팠는데

그럼 공유된 링크로 들어와서(난수값) 로그인하면(아이디값) 그러고 만약에 로그아웃하면? (또 난수값?) 이런식으로 내 생각엔 굳이 이렇게 어렵게 처리해야되나 라는 생각이 계속 들었다. 이것도 1시간 연설하면서 main/난수 또는 main으로 가자고 했는데 이건 진짜 내가 상황가정 잘해서 깔끔하게 잘 말해야되는데 나도 상황이 너무 복잡해서 살짝 멘탈이 나간 상태라 다들 내가 무슨말을 원하는지 잘 이해를 못했다. 사실 나도 말하면서도 내가 뭔얘기하는지 잘 모르겠고,

나름 나도 이해하고 이해를 도우려고 그림그리면서 설명했는데 이 날은 아.. 다음에 오프라인때 다시 얘기하죠 하고 마무리됐다 ㅋㅋ

그러고 오프라인때 얘기를 나누면서 서로 무슨 상황인지 이해하게 되면서 일단 오늘자까진 도메인/main/난수값으로 고정 가기로 했다. 난수값이 내 페이지에서 서버에 편지 보낼때 필요하긴해서

근데 얘기 나온걸로 보면 아마 후에 난수값을 따로 저장하고 main으로만 가게 될것 같다. 아마도?

1차때랑 비교하면

정말 빠른속도로 페이지가 만들어지고 있다; 이미 백은 api 다 완성하고 배포해서 각자 공부하고 있다. 프론트도 진짜 빨리 되고 있고..

일단 나도 내 페이지는 이미 다 끝난 상태라 메인페이지 도와주고 있었는데, 이번에 서버 배포된걸로 api 테스트 해보니 잘 가져서 이번주는 내 페이지에 기능을 더하려고 한다.

리치 텍스트 라이브러리 (Quill) 을 넣으려고 하는데 사진 넣는게 은근 까다롭다. 그리고 우리가 셋팅한 설정에서 좀 바뀌어야되는게 있어서 그거 알아보고 있다. 여튼 테스트 해봤을때 글씨까지는 잘 받아지고 가지는데 이미지가 좀 문제가 있다. 그리고 나는 quill이 주는 기본 스타일말고 스타일을 사이드바안에서 커스텀할거라서 그게 좀 오래 걸릴것 같다.

여튼.. 열정! 열정! 열정~!

나는 지금 이해가 하나도 안되고 무슨 말인지도 모르겠는데 사람들은 질문하고 답변받으면 추가 질문하는 모습을 보면서 많이 힘든 시간도 있었던 것 같기도하다. 그럴때마다 일주일 전의 나, 한달 전의 나와 지금의 나로 비교하며 마인드 컨트롤 한 것 같다. 그렇게 그냥.. 하면 분명 2주전에 못풀었던 문제인데 지금은 풀 수 있고 그렇더라

절대적 평가가 아닌 상대 평가로 갈리는 경쟁시장에서 내가 우위를 차지할 수 있는가 하면, 아직은 눈물이 나지만 ㅠㅠ 대신 상대평가의 지표가 여러가지라는 것에 위안삼자!

이제야 출발선에 선 것뿐 너무나 많은 시간동안 나아가야함에 있어서 무너지지 않고 착실히 임해야하는 태도가 중요한것 같다. 나보다 잘하는 사람들도 같은 고민을 하고 앞으로 나아갔던 사람들이라 지금 잘하는 것이라고 자기위안하고있다. 요즘 코드잇에서 질문에 답글 다는 재미로 살고있는데 그런 고민들이 가끔 올라온다. 전 코딩에 재능이 없는걸까요 하는 그런 글들,, 나도 똑같이 했던 고민이고 사실 고민의 해답은 절대적인 재능인이 아닌이상 절대적인 시간에 달려있는 것 같다.

새로운 언어를 배우려면 평균 1만시간인가? 필요하다고하는데 물론 프로그래밍 언어는 이미 인간들이 세워둔 언어문법 체계 위에서, 컴퓨터와의 소통을 목적으로 세워져서 조금은 적게 걸릴 것 같다고(0101 이런거 말고..) 생각하지만,

(진짜로 프로그래밍 언어에서도 언어적 문법이 보일때가 있다. 동사+목적어 형식으로 함수가 짜진다던지 하는, 그리고 알파벳 쓰잖아! 영어 단어 쓰잖아!)

그럼에도 불구하고 새로운 언어는 맞아서 내가 1만시간도 쏟지 않고 재능이 없다고 말할 자격이 있는가에 대해 생각해본다.

그래서 답글도 내 경험을 얘기 하면서 모르는게 당연하다고! 외치는 중이다.ㅎㅎ 처음 자바스크립트 문법을 접하면서 맨날 썼던 메소드 까먹고 알고리즘 문제 보면 멍해지고 ㅋㅋ 그래서 2주동안 알고리즘 200문제를 풀었다. 그랬더니 전보다 낫더라 문법에 조금은 익숙해졌지만, 기능들의 흐름은 이해가 안돼서 1주동안 하루에 1클론 코딩했다. 그랬더니 전보다 낫더라. 그러고 전에 내가 몰라서 질문했던 것, 노트했던것들 보면 이걸 그땐 왜 이해못했지? 이런다.. 그만큼 성장했다는 것이겠지?!!

조금은 무식하지만 사실 익숙해고 싶다면 최대한 익숙해지고 싶은 환경에 노출되어야 한다고 생각해서.. 책보단 이렇게 무식하게 공부했다 ㅎㅎㅋㅋㅋ 사실 그땐 책봐도 이해가 안되는 시기였고, (메모리 주솟값이니 참조값이니 뭐니 진짜 뭔소린지 아예 이해가안돼서 1페이지 읽고 덮었던 코어자바스크립트..)

지금은 책을 읽어도 이해할 수 있는 시기랄까.. 그래서 이번 프로젝트 끝나고 기술 면접준비하면서 궁금한부분들은 해당 주제를 깊게 다룬 책들 좀 읽어볼 예정이다.

하.. 책을 읽어도 이해할 수 있는 시기라니 얼마나 감격..ㅠ 이제 좀 올챙이에 발 하나 나온 느낌이다. 발 하나 나오기 까지 얼마나 힘들었는지..

배우면서 느끼는건 진짜로! 한번에 이해는 안된다. 근데 그냥 하다보면 나중에 다른것들 배우는데 갑자기 전에 이해 안됐던게 정말 갑자기 이해가 된다ㅋㅋㅋ 아!!! 그때 그럼 이래서 이랬던 건가? 이러면서 삘 받아서 블로그 찾고 강의 듣고 하면 전에 진짜 이해 0이었는데 갑자기 60% 이해됨 ㅋㅋㅋ 요즘은 인기글로 올라오는 미디엄글도 가끔 읽는데 재밌다. 그래도 뭔 소리인지는 알아 들을 수 있어서 재밌고 기쁘다. 이게 재밌어서 계속 공부하게 되는 것 같다.

하.. 하지만 살짝은 절망적이게도 이제 파이널 프로젝트 시작인데 리액트를 마스터 못했다 ㅠㅠ.. 그래.. 4주동안 마스터는 힘들지.. 지금 어떤 상태냐면 페이지는 어찌저찌 만드는데 상태관리/컴포넌트 분리가 난리부르스이다.ㅋㅋㅋㅋ 아직은 구조가 너무 어려워서......ㅠ

솔직히 틴더 페이지 좀 뜯어볼때 페이지 여러개 겹치는데 분할해서 한페이지로 하나의 url로 내놓고 기능도 엄청 복잡해서 충격먹었는데 리액트 배우면서 이게 어떻게 가능한지 이해했다. 그래서 이때 리액트 강점을 더 잘 이해했는데, 쓰기 왜이렇게 어렵냐 나 울어..

그래서 스터디로 프로젝트한거는 홀드됐다 ㅠ.. 수업따라기도 너무 힘들어서.. 그래도 틴더 페이지 뜯어보고 구조 잡고 기능 나열하면서 리액트 강점을 더 잘 이해할 수 있었다.

(물론~ 자바스크립트도 가능하겠지 근데 이거 자바스크립트로 할라면 진짜 자바스크립트 10년 공부해야 될듯ㅋㅋㅋ 헷)

리액트는 자바스크립트+html짬뽕을 지원해줘서 컴포넌트 분리하기 비교적 자바스크립트보다 명확하고, 코드도 더 간결해지고, 컴포넌트로 관리하니까 링크 따로 컴포넌트 따로 fetch따로 가져갈 수 있다. 처음엔 이 개념에 울었다... 하지면 페이지가 커지면 왜 리액트쓰는지 알 것 같다. 자바스크립트로 틴더 같은 페이지 관리한다? 진짜로 화면 작게했다 크게했을때 인터렉션 하는거 보면 어떻게 만들어야되는지 감도 안옴(사실 리액트도 감 안옴 ㅎ) 처음 구조잡고 분리하고 하는거 정~말 어려운데 유지보수&상태관리하기에는 리액트가 자바스크립트보다 나은것 같다.

여튼 다음 프로젝트 때문에 부랴부랴 리덕스 따라가고있는데 리덕스 무슨일? 뭔 말인지 1도 모르겠고요 ㅋ하하하~ ^_ㅠ 타입스크립트 안다고 생각했는데 모르겠고요~ 리액트 훅 진짜 돌아버려~

오늘의 처방(프로젝트 시작전까지 끝내기) -api 활용하여 crud 리액트 앱 만들어보기 -리액트/타입스크립트 강의듣기 -리덕스 툴킷/리액트 앱 만들어보기 -리코일 강의 듣기

다들 상태관리 라이브러리를 리덕스말고 리코일 추천해주던데, 차이점이 뭔지 궁금하다. 그리고 rest api말고 graphql 한번 써보고싶은데, 잠깐 들었는데 진짜 너무 좋더라 스터디 프로젝트에서 틴더 카드페이지 맡았었는데 하트 누르면, 다른 경로로 fetch 들어가야되서 비동기 실행을 2번하게 돼서 하 이거 맞나 했었는데, graphql 쓰면 한번만 해도 된다니..

오버패치, 언더패치 방지하는 graphql 써보고 싶습니다.. 그런데 잠시만요 선생님, 리액트 먼저 일단 빨리 익숙해지고요 담주에 프로젝트거든요 일단 눈물 흘리면서.. 달려볼게요~

스케줄

엘리스에서 진행하는 취업관련 도움도 필요했기 때문에 그리고 우선순위만 잘 정해서 진행한다면 할 수 있을 것 같아서 3주간 수업진도+취업관련+프로젝트 진행이라는 빡빡한 스케줄은 짜게 됐다.

프로젝트

기획은 전반적으로 내가 짜게되었는데, (아무래도 하고싶은게 너무 확실해서 전반적인 기획을 짤 수 있게 되었던거 같다.) 일단 내가 선택한 비지니스 타겟은 '틴더'였다. 다른 이유가 있던 건 아니고 '실시간'이라는 키워드가 워낙 중요하게 다뤄지다보니 관련한 기술을 다뤄보고 싶었는데, 틴더가 가장 재밌어 보였다.

기획에서는 무서워서 또는 부담스러워서 만남을 시작하지 못한 사람들을 위한, 자만추를 온라인으로 추구하는 사람들을 위한 복합 네트워킹 웹을 컨셉으로 블로그와 오픈챗팅방의 기능을 추가 커스텀 해서 최종목표는 틴더+브런치 느낌으로 잡았다.

하지만 3주동안에 해당 모든 기술을 다루기엔 부족할 것 같고, 틴더 기능에서 사이드 기능들은 빼서 속도감 있게 진행해야 할 것 같다.

사이트맵, 페이지 리스트 정리

오늘까지 프로젝트 이틀차 인데, 페이지 이동은 대략적으로 정한상태고, 스케줄을 어떻게 쪼개야할지 또한 틀은 잡아놓은 상태로, 현재 페이지 리스트 정리 중에 있다. 최대한 코딩하고 공부할 시간을 늘리기위해 미팅/기획시간을 밀도있게 진행하고 있다.

웹과 모바일 인터렉션 모두 하고 싶었지만

1) 틴더 웹구성이 생각보다 엄~~청 복잡하게 되어있어서, 인터렉션만 3주하게 될 것 같았고 (한페이지에 분할이 3개고 어떻게 한지 모르겠는데 페이지들 겹쳐져 있고 ,, 그러하다..) 2) bm으로 일했을때도 모바일 유저 95%, pc 유저 5%로 구성되었기 때문에

유입률이 좋고, 3주의 시간안에 구현할 수 있는 모바일 기준으로 웹 구성을 하기로 했다.

페이지별로 기능별/세부 기능별/요청 방식/요청 바디 수요일까지 정리해서 미팅진행하고 금요일에 한번 더 논의, 코드 컨벤션 정해서 금요일부터는 바로 코드 작성할 수 있도록 하는 것을 목표로 힘차게 달려가는중 이다.

1차에서 해봤던 페이지 같은 경우는 큰 무리없이 진행될 것 같지만(음.. 과연?) 이번 프로젝트에서는 리액트로 진행할 예정이라 약간의 난황도 예상된다.

가장 걱정되는 부분

가장 다뤄보고 싶었던 부분이지만 한편으로 가장 걱정되는 부분은 메세지 관련 기능들이다. 아직 API가 어렵게 느껴지는데 실시간으로 백과 정보를 주고받는 메세지 기능을 잘 구현할 수 있을까 하는 걱정이 먼저 앞선다. 그럼에도 불구하고, 파보니 꽤 재밌는 정보가 많아서 (메시지 브로커라던지, 이거 하면서 처음 봤다.) 어렵지만 재밌게 진행할 수 있지 않을까?! 라고 낙관적으로 생각해본다.

빨리 3주가 지나고 완성된거 보고싶다.

코드잇에서도 서로 물어보고 답할 수 있는 q&a페이지가 있는데, 너무나 감격스럽게도 순위에 들어버렸당 잇힝 코드잇 커뮤니티가 워낙 작아서 답변 3개로 순위에 올라가서 약간 날로먹는 느낌이지만, 내가 배운 지식으로 누군가에게 도움을 주었다는 것이 너무 뿌듯하다! 그리고 질문보면서 나도 어? 왜그러지 하면서 찾아보면서 배우는 부분도 많고 답을 상대방이 이해하기 쉽게 쓰려고 노력하면서 배운지식이 나에게도 잘 흡수되는것 같다! (요즘 맛들려서 맨날 질문올라오는거 한번씩 훑고 있음)

하.. 나도 이제 누군가의 질문에 답을 할 수 있는 사람이구나..(간단한 질문만 ㅋ) 새삼스럽게 2달간 달린 과정들이 주마등처럼 스쳐지나간다.

이제 리액트 시작하는데 거짓말 안치고 눈물 한방울씩 흘리면서 따라가고있다. 그냥 자바스크립트 쓰면 안되나요...? ㅜㅠ,,ㅋㅋㅋ 알면 편할거 같은데 확실히 이런 이점이 큰 툴들은 초반에 익히기가 어려운것 같다. 또 익히면 아무것도 아닌것처럼 이걸 왜 이렇게 어려워했지? 하겠지.. 빨리 넘고싶다 ~ 그 벽을!

드디어 2주간 진행된 첫번째 프로젝트가 완료되었다. 그 후기는?

일단 기획하는 시간, 백/프론트 어떻게 정보를 가공할지 어떤 페이지를 쓸지 등 서로 맞추는 시간이 부족했던 것 같다. 이에 따라 레이아웃도 맡은 페이지 별로 편차가 있고, 백/프론트 연결도 배포 이후에도 계속 맞추는 작업이 계속 되었다. (사실 2주는 너무 짧다 ㅠ.. 보통 포트폴리오 프로젝트도 못해도 준비기간 1개월 이상으로 가져가는데 2주는.. 짧지요ㅠㅠ)

만약 엘리스에서 api명세서 정해주고 페이지 구조 잡아주고 이거에 맞춰서 작업해! 라고 하면 완성도 면에서는 지금의 결과물보다 많이 개선되었을 것이라고 생각하지만,

그럼에도 불구하고 처음부터 진행하며 배우는 부분이 많았다는 점에서 이렇게 처음부터 진행하는 방식이 좋았고, 배울 수 있는게 다양했다는 점에서 첫번째 프로젝트는 성공적으로 마무리했다고 말할 수 있겠다.

1. api 명세서가 뭔데요?

api 명세서가 무엇인지 전혀 몰랐다. 프론트 관련 수업을 들을때도 프론트 강의다보니 이미 path 또는 url이 나와있고 요청방식, 어떤 정보를 줄지/받을지 정해진 상태의 수업을 듣거나 코드 실습을 했기 때문에 프론트와 백이 어떻게 회의를 하고 우리는 어디에 어떤 요청을 하고 무엇을 줄건데 너네는 우리가 어디에 무엇을 주면 이걸줘야돼 라고 약속하는 것에 대한 이해도가 0이었다.

백/프론트 페이지 붙이는 작업은 사실 형식? 같은 느낌이라 문법적으로 어렵다기보다 이러한 약속을 정하는 과정이 어려웠다. 아직도 너무 어렵고, 이해를 아직은 완벽하게 못한 상태기 때문에 조장님이 고생하셨다.. (전 페이지 fetch작업을 진행하셨음..ㅋㅋㅋ)

이러한 흐름을 이해하기 위해서 무엇보다 실습이 중요한 것 같다.

• 한 페이지 내에서 작동하는 사이드 프로젝트류 보다는 실제 페이지가 여러개로 구성된 사이트를 예시로 코드를 많이 읽어봐야 흐름과 보통 어떨 때 어떤 요청/path를 가지는지 보이고 익숙해 질 것 같다.
  

• 오픈 api로 내가 뭔가를 몇 개 더 만들어봐야 좀 더 깊은 이해가 생길 것 같다.

2. 백과 프론트 작업 차이 극복

당연히 백과 프론트 동시에 작업되며 백에 데이터를 줄 수도 받을 수도 없는 상태로, 내가 어떻게 백에 정보를 주고 정보를 받고 받은 정보대로 케이스 나누고를 어떻게 작업을 하지? 어떻게 작업을 시작 하지?? 라는 고민이 많았다.

css작업이 끝나고 도저히 작동부분은 어떻게 시작을 해야할지 감이 안와서 코치님께도 문의를 드렸는데,

코치님: '백과 프론트는 독립성이 있어야 되는게 맞다. 목 데이터 등을 이용해서 동작 구현을 하고 백이 정리된 이후에 fetch 경로를 바꿔서 작업하면 된다.'

'아!!!!' 하고 바로 오픈 api써서 작동 확인을 하며 작업을 했다.

3. 케이스 나누기

프로젝트를 진행하며 느낀 점은, 생각보다 하나의 기능에도 많은 케이스가 존재한다는 것이었다.. 회원가입 페이지를 예로들면 이메일 기준으로 기능을 잡았는데

• 이메일 형식이 아니거나('@' 여부)
• @, .외의 특수문자/이모티콘 등의 문자가 있거나
• 이메일 형식이나 문자/숫자 길이를 과도하게 입력되어 서버를 다운시킬 위험이 있거나
• 있던 이메일 이거나 등등

이메일만 관련한 케이스도 몇개로 나뉘어지고, 여기에 사용자 정보 입력란이 추가될 수록 케이스는 또 추가가 된다.. 이러한 케이스를 생각하고 범위를 잡는 작업이 어려웠다. 처음엔 응~ 그냥 받아서 post보내면 되네 easypizy이러고 있었는데 막상 서비스 시연하면서 버그 찾다보니 걸리는 케이스가 굉장히 많았다.. ^^.. (역시 한 페이지라도 쉬운것은 없다)

4. 데이터 가공하기

결제 페이지에서 정보를 많이 받다보니, 해당 데이터를 다루는게 꽤 까다로웠다. 특히 내가 만들고 싶은데로 만들어서 데이터를 백에 주는게 아니고 백이 원하는 형식이 있기 때문에 데이터 구조를 가공을 하는 부분이 머리 좀 아팠다. 백에서는 이렇게 한명의 유저라도, 여러개의 상품을 사면 상품 리스트만큼 유저정보가 중복으로 객체로 생성이되고, 한 배열로 받기를 원했는데 한 유저가 중복으로 상품만 다르게 객체로 생성하는 부분에서 애좀 먹었다. 유저에 상품이 배열로 들어간다던가, 객체로 들어가는 것까지는 만들겠는데 상품만 다르게 유저 중복...? 이것 저것 찾아보다가 카트안의 상품만큼 map으로 객체를 생성해 준뒤, 카트안의 상품만큼 만들어진 객체에 map으로 유저정보를 넣어 펼쳐줬다. 좀 더 간략하게 만들 수 있을 것 같은데 급하게 마무리하느라 작동되는 것만으로도 감사함을 느끼고 마무리했다.

let productCart = JSON.parse(localStorage.getItem("productCart"));
//productCart는 [["img", "coach", 1, 30000, 30000], ["img", "someting", 1, 25000, 25000]]형식

const productsData = productCart.map((product) => ({
    productName: product[1],
    productPrice: product[4],
    productQuantity: product[2],
  }));

  if (!savedUser || savedUserObj.userType === "nonMember") {
    const orderPassword = document.getElementById("orderPassword").value;

    const nuserDataArray = productsData.map((product) => ({
      productName: product.productName,
      productPrice: product.productPrice,
      productQuantity: product.productQuantity,
      totalPrice: product.productPrice * product.productQuantity,
      userName,
      userEmail,
      userPhone,
      userAddress,
      orderPassword,
    }));

    const nuserData =
      nuserDataArray.length > 1 ? nuserDataArray : nuserDataArray[0];

      console.log(nuserData)

5. 마무리

내가 구현한 기능정리 :

👤 사용자 관련 구현 기능

• 회원가입 : 회원가입 폼 입력값 확인, 조건에 맞게 입력 후 가입시 백엔드와 연결되어 회원가입 정보가 DB에 저장
• 로그인 : DB에 저장된 정보로 로그인 성공 시, local storage에 회원정보(유저타입, 이메일)저장 -> 다음 프로젝트엔 토큰으로!

💵 결제 관련 구현 기능

• 배송지 정보 자동 입력 : 회원일시, local storage에 저장된 이메일로 DB를 불러와 배송지 정보 자동 입력 가능

• 비회원일시 배송지 정보 자동 입력체크란 대신 주문 비밀번호 입력 가능
• 장바구니 상품갯수에 따라 결제 상품리스트/총금액 등 반영

  • 결제 방식: 결제 방식 선택 가능!
  • 프로모션 코드 : 비회원/회원 프로모션 코드 사용가능(주문당 최대 가능수량은 1개), 코드 사용에 따라 총 결제 금액 수정
  • 결제 완료시 백엔드와 연결되어 주문정보가 DB에 저장

프로젝트 정리 : https://little-eoraptor-5ed.notion.site/Super-Hot-SIX-866248cd46ae420db22fd8cc55a81c3e

6. 부록 (feat.진짜 마무리)

여러모로 많이 배웠던 프로젝트, 내가 어느부분이 부족하고 어느쪽을 더 파야할지 알 수 있었다. 추가적으로 프로젝트라고 생각하고 기능적인 부분 위주로 피드백/질문을 받을 것이라고 생각했는데 아니었다. 프로젝트를 진짜 상품이라고 가정한 피드백/질문들이 많았는데, 해당 피드백과 질문을 토대로 짧게나마 개발자들은 어떠한 부분을 고민하고 중요하게 생각하는지 알 수 있었다.

예를들면 페이지 목적에 따라 다른 피드백을 받았는데, 어떠한 로딩된 페이지는 api를 안쓰고 가져올 수 있도록 하는것이 좋다는것(비용을 줄이기 위해) 또 다른 코치님은 반대로 저장하지 않고 api를 쏴서 데이터를 실시간으로 가져올 수 있도록 하는것(유저 경험을 높이기 위해)를 말씀 주셨다. 또 장바구니 전체 삭제 부분도 전체 삭제 버튼 클릭시 바로 다 삭제되는게 아닌 전체삭제는 한번더 알림으로 확인하는 것도 굉장히 플러스를 받았다. (전에 기획자로서 유저경험은 진짜 디테일에서 갈리는게 많은데 이런 디테일한 부분도 중요하게 고려하는 구나를 알게되었다.)

단순히 기능을 구현하고 클린 코드를 작성하는 것 정도로 개발자의 영역을 이해했다면, 프로젝트에서 피드백을 들으며 생각보다 ux를 중요하게 생각한다는 것을 알았다. 유저에게 어떤 기능/상품으로 어떤 경험을 하게 만들 것 인가는 항상 숙제처럼 따라오는 것 같다. 기획자만의 숙명인줄 알았는데 유저가 있다면 모든 부서에서 경험하는 숙제 인가보다.

1. 전 직무랑 전혀 연관이 없을줄 알았는데..?

이전에 브랜드매니저로 일을 했었고 사실 프로그래밍이랑 해당 직무 경험이 전혀 상관이 없을 줄 알았다. 해당 직무들이 프로그래밍이랑 연관성이 없는것은 맞다. 그런데 프로젝트는 또 다른것 같다. 그리고 직업병은 무엇보다 무섭다.

가장 크게 엥?스럽게 느낀점은 스케줄링 때문이었는데,
분야별로 프로젝트 정의가 나뉘겠지만 브랜드 매니저로 일을 했을때를 예를 들면, 내가 생각한 프로젝트는 크게 매출관련, 상품관련, 그 외 개선등 단위시간을 갖고 진행되는 것들로 생각할 수 있다.

그리고 내가 맡았던 프로젝트는 프로젝트 단위는 다르겠지만 약 50개 정도였다. (해외영업할때는 브랜드 3개, 상품만 200개정도 였다.. 어떻게 했지..?) 심지어 하나씩 진행되는게 아니고 동시다발적으로 몇 십개씩 진행이 되고있기 때문에, 시간에 많이 민감한 사람이 되었다.(성격도 버렸다.)
업무들을 카테고라이징하고 버리는 업무는 깔끔하게 버리면서 최대한 로스를 줄이고 (예를들면 시간대비 효율이 안좋은것 -> 버리는것, 효율이 안좋지만 필수적으로 행해야되는것 -> 구색만 갖추고 버리는것 등)

실질적으로 목표와 지표에 큰 영향을 끼치는 메인에 시간을 쏟으면서 타임라인을 맞추는게 일상화된 사람인데, 이게 이렇게 도움이 될줄이야?

(업무를 카테고라이징하는 이유는 내가 조그마한거 잘못 결정하는 순간 여래 부서와 벤더업체는 괜한일을 하게 된다. 그 영향은 딜레이~ 딜레이가 되면? 당연히 손해 발생.. 이것이 나비효과..)
프로젝트 목표가 개인적 배움보다는 프로젝트 완성이고, 기간이 겨우 2주밖에 없기 때문에 메인페이지 등 아이덴티티를 보여줄수 있는 페이지가 아닌이상 css는 라이브러리쓰고(css 버리자 - 어차피 나중에 팀원들이랑 레이아웃 맞춰야됨 구색만 갖추자) 기능에 집중해서 완성도를 높이자(메인에 집중하자) 무의식중에 이미 이렇게 생각하고 있었다..
프로그래밍을 잘 모르는 상태고 내가 이 기능을 구현하는데 얼마나 걸리는지 모르는 상태인데도 언제까지 레이아웃 끝내고 언제 이 기능들어가고 언제까지는 전체적인 그림 나오면 맞춰보고 수정하면 언제쯤까지는 이정도 될거같은데? 라는 대략적인 스케줄이 머릿속으로 잡힌다..

역시 인생은 정글짐.. 점들의 연결.. 해당부분이 내가 취약한 기능부분에 집중 할 수 있도록 많이 도와준것 같다.

** 2. 어? 생각보다 쉬운데?**

는 무슨.. 누가 쉽대? 스케줄링이 다가 아닙니다.. 프론트 '엔지니어'입니다.

일단 현재 맡고있는 페이지는 로그인 페이지, 회원가입 페이지, 결제 페이지인데, 로그인 페이지에서 유저정보를 db랑 매칭해서 맞으면 로컬 스토리지에 유저타입이랑 아이디를 저장하는 작업을했는데 다행히 이전에 메모장 관련 클론코딩했던 부분에서 한번 다뤘던 내용이라 수월하게 작업했다.

특별히 복습하거나 하지도않고 한번 따라치고 넘어간 내용인데도 가뭄에 단비같이 도와줬다. 진짜 저번주 클론코딩 한 내 자신 칭찬해..
그런데 문제는 유저정보를 db랑 매칭하는 부분이 문제였는데, API 개념을 내가 이해를 못하고 있다는걸 알았다. 이것도 이전에 했던거보면서 db매칭되서 로컬스토리지에 잘 저장되는거 보고 아 이런거구나 생각했는데 코치님 오피스아워때 말씀들어보고, 응??? 했다. 무슨말인지 모르겠어서..ㅋㅋㅋ
백엔드 준비가 안돼서 그냥 돌아다니는 api로 테스트 해보고 기능이 동작돼서 오? 이런거구나 했는데 전혀 아니었다..ㅋㅋ..

내가 모르고 있던 부분은 요청방식이 필요하다는 것이었다.. get/post 등등..

나는 돌아다니는 이미 get을 지정해둔 api를 썼기 때문에 아무생각없이 fetch(url), await쓰고 받아와서 로컬 스토리지에 잘 저장되는 것이었던건데.. 그래서 백엔드에서 회원가입 페이지에 post 넣어달라는 말을 아예 이해를 못했다.(음?)
문제점을 인식하고 api 강의를 듣고 이제야 좀 백엔드랑 프론트가 어떻게 연결되면서 분리되는지 큰 맥락은 잡히는 것 같다. 맥락을 잡았으니 이제 디테일하게 공부하면서 코드를 다시 짜야될 것 같다 ㅠ

그래서 주말간 할 일 : fetch, promise, api 등 관련 강의 다시 듣고 제대로 이해하기.. api추상화 연습 해보기, 다음주에 백엔드랑 깊게 얘기해보기
팀회의때 스키마 어쩌고 하는데 혼자 네이버에 스키마뜻 치는 나.. 여기까지 한 것도 대단해.. 분명 배운건데 이해를 못한 상태로 흘러간 나의 지식들... 프로젝트로 다시 주워 담아줄게..

참고 API 강의) API가 뭐냐면

** 3. 중꺽마**

2개월전 자바스크립트랑 자바랑 같은건가?라고 생각했던 걸로 생각하면 내가 어느정도나 성장한지 알 수 있다.ㅋㅋ

프로젝트 시작때만해도 프론트가 해야되는 기능이 뭐지..? 뭘 구현해야되는거지..? 하고 디자인만 생각했는데, (원래 모르면 눈에 보이는것부터 생각하게 되니까) 근데 그 사이에 프론트의 역할을 이해하고 어느새 회원가입, 로그인, 결제페이지 반 이상은 작업이 끝난거같다.

확실히 초반에 익히기가 어렵지만, 신기한건 꾸준히 하면 어느순간 갑자기 머리속이 반짝거리면서 '아!' 하는 순간이 생긴다. 그리고 연달아서 연관된 다른 부분들도 이해도가 확 깊어진다. 이해되면 이걸 왜 이해못했지 할 정도로 지나고 나면 아무것도 아닌.. (하지만 아직도 깨달음을 얻을게 무궁무진하다는것이 살짝 나를 힘들게 하지만)

현재 모르겠다고, 안된다고 좌절하지말고 끝까지 알고자 노력하고 깨달음의 기쁨을 생각하자. 중요한건 꺽이지 않는 마음~ㅠㅠ..