개발하고 싶은 초심자

어제와 오늘 계속 statesairline client, server, 그리고 mini node server sprint를 계속 클론해서 새 파일에 풀어보았다. client는 괜찮은데 server요청이 은근히 힘들다. 아직 파일을 보면 어떤 것부터 해야하는 지 눈에 잘 보이지 않고, 여러 번 반복하여 풀면 눈에 보이지만 그냥 코드만 외워서 치는 듯한 느낌을 지울 수가 없다. 회고록들을 보면 그동안 풀어왔던 과제 파일들을 많이 풀어보는 것이 도움이 많이 되었다고들 하는데, 그 분들도 이런 느낌을 받아본 적이 있을까? 나만 이런 것일까? 항상 힘들 때마다, 의구심이 들 때마다 '나만 이런 것은 아니야!' 라고 생각하는 것이 도움이 많이 되지만, 순간 순간 '나만 이런 것이 맞는걸까?' 하는 생각이 드는 것은..

어제 해봤던 react hooks를 redux로 상태 관리하는 스프린트로 진행했다. 다들 리덕스가 더 어렵게 느껴졌다고 했는데, 나는 어제 했던 훅을 이용한 상태 관리가 더 복잡하고 힘들었기 때문에 상대적으로 리덕스를 사용하는 것이 괜찮았다. 스프린트를 진행하면서 switch case 조건문을 사용하는 방법에 대해 알게 되었는데, 이렇게도 쓸 수 있다는 것을 알게 되어 흥미를 갖고 찾아보았다. 5시부터 진행했던 코스 리플렉션에서는 설문조사와 함께 HA에 대한 이야기를 들었다. 이번 section 2 HA는 첫 날엔 코플릿형, 둘째날엔 퀴즈형과 과제형 문제들이 있다. 지난 section에는 없었던 퀴즈형이 추가되어 어떤 것이 나오는 지에 대해 들었는데, 퀴즈형은 유어클래스에 가끔 나오던 정답을 알려주지 않..

1. 프론트엔드 개발에서의 상태 관리(State Management) ① state(상태): 동적인(변하는) 데이터. UI에서 동적으로 표현될 데이터. ⇒ class component 내에서 관리함 ② Side Effect: 함수의 입력 외에도 함수의 결과에 영향을 미치는 요인. 대표적으로 네트워크 요청, API 호출이 있다. ⇒ side effect를 최대한 배제하고 컴포넌트를 구성하더라도, 불가피한 경우가 있다. ⇒ 로딩 중을 나타낼 것인지 아닌지에 대한 여부는 데이터 전송 여부에 따라 다르다. 앱을 만들고, UI를 구성할 때에는 항상 이러한 로딩 중 상태를 고려한다. ③ 상태의 적절한 위치 ‣ 상태의 두 가지 구분 → 로컬 상태 : 특정 컴포넌트 안에서만 관리되는 상태. 컴포넌트 내에서만 영향을 끼..

페어 프로그래밍으로 cmarket react hook 스프린트를 진행했다. 상태 관리에 대한 전반적인 공부를 하고 스프린트를 진행을 했는데, 오늘 한 것은 지금까지 했던 모든 내용들을 조금 더 실용적인 내용으로 다뤄본 것 같다. 오늘의 스프린트는 제출을 해야하는 것이 아니여서 마음 놓고 페어와 함께 의견을 나누며 할 수 있었다. 하면서 계속 컴파일은 잘 되었는데 갑자기 수량 체크가 되지 않고, 장바구니에 담는 것도 되지 않아 당황스러움의 연속이었다. 로직을 잘 짰고, 큰 그림을 잘 생각하며 코드를 짰다고 생각했는데 막히는 부분이 나오니 답답했다. 결론은 내가 생각하지 못한 부분이 있었고, cartItem을 cartItems 라고 써서 원하는 대로 동작하지 않았던 것이다. 그럴 때가 가끔 있는데, 그럴 때..

오늘은 AutoComplete와 ClickToEdit을 구현했다. 이 부분은 advanced 과제라 무조건 해야 하는 것은 아니었지만, 어제 했던 Modal과 Toggle, Tab, 그리고 Tag까지 복습을 한 후 한 번 구현해보는 것이 내 실력을 올리는 데에 도움이 될 것이라 생각이 들었다. AutoComplete는 상태를 3가지로 내어주는데, 3개를 전부 사용해야함은 물론이고 내가 만들기까지 해야해서 어렵게 느껴졌다. useState를 만드는 것 자체는 어렵지 않은데, 구현하기 위해 사용해야 하는 상태를 생각해내는 것이 어려웠다. 상태와 이벤트 함수가 여럿이다보니 자꾸 어디에 어떤 상태를, 함수를 사용해야됐었는지에 대해서도 헷갈렸다. 그 부분은 내가 AutoComplete를 구현하기 위한 기능은 대충..

오늘은 리액트 컴포넌트 디자인 스프린트 페어 프로그래밍을 진행했다. 아침 10시부터 6시까지 점심시간을 제외하고 하루 종일 페어를 진행해야 했는데, 기능적인 부분을 다루기도 했지만 아무래도 CSS 측면을 다루다보니, 서로의 의견을 많이 주고받는 시간을 가지지 못했다. 서로 컴포넌트를 디자인하고 어떻게 했는 지에 대해 설명하는 시간이 주가 되는 페어 시간이었는데, 나름대로 이렇게 할 수도 있다는 것을 많이 알아갔다. 모달, 토글, 탭, 태그를 했는데 기능적인 부분에서 filter는 수월하게 할 수 있었는데 map을 활용하는 부분에 있어 조금 막히기도 했다. 아직까지 map을 활용하는 것에 대해 많이 부족한 듯 하다. 내일은 advanced 문제로 autocomplete와 clicktoedit을 구현하기로 ..

오늘은 아침에 토이 문제를 풀고 하루 종일 storybook과 CSS-in-JS, styled component, 그리고 useRef에 대한 solo study를 진행했다. 토이 문제는 처음 코드는 쉽게 써내려갔지만, 뒤에서 어떻게 풀어야하는 지 막혀 레퍼런스 코드를 보고 풀었다. 내가 이해하지 못한 것은 bfs와 이진탐색이었다. 분명 주말에 공부를 하고, 설명을 들으면 이해가 되는데 막상 사용해야 하는 문제를 풀려면 바로 보이지도, 생각나지도 않는다. section 1에서 이럴 때는 어떻게서든 깊숙히 파고들면 언젠가는 이해를 했었는데, 이번에는 도저히 출구가 어딘지도 모르는 미로를 어떻게 찾는 지도 몰라 헤매고 있는 것 같은 느낌이 든다. 토이 문제를 풀 때 쉽게 느껴지는 것도 있지만, 이런 답답함이 ..

1. Component-Driven Development(CDD) : 부품 단위로 UI 컴포넌트를 만들어 나가는 개발. UI 컴포넌트 제작 방식. ✷ UI = User Interface ex) BBC, UN 사이트 등 ① Storybook : CDD를 하기 위한 UI 개발 도구의 일종. Component Driven Development 가 트렌드로 자리 잡게 되면서 이를 지원하는 도구 중 하나인 Component Explorer(컴포넌트 탐색기)가 등장했는데, 그 안의 많은 UI 개발도구 중 하나. ② Storybook을 사용하는 이유(Storybook의 장점) → Storybook은 기본적으로 독립적인 개발환경에서 실행되기 때문에 개발자는 애플리케이션의 다양한 상황에 구애받지 않고 UI 컴포넌트를 집..