Life (242) 썸네일형 리스트형 20200928 T.I.L 오늘 한 일 저번 주 과제 풀이 영상을 본 것으로 가볍게 시작했다. 뭔가 id를 설정하고 그런 접근법들 같은 거는 내가 시작할 때 했던 접근법과 유사했던 거 같은데 디테일한 부분들이 다른 느낌이 들었다. 근데 그 디테일들이 다 중요한 것들이라 ㄷㄷㄷ 놓치지 않고 새겨놔야겠다 생각하며 들었다. 수업을 다 듣고 생활코딩 redux의 마지막 강의 시리즈인 react-redux 실전 curd 앱 만들기 영상을 틀었다. 근데 보니까 이게 redux 수업을 했을 때 html, javascript, redux만으로 구현했던 페이지를 다시 react와 react-redux를 가미해 만들어 보는 내용이었다. 역시 배운건 실전으로 바로 써먹어봐야 내가 뭘 모르는지 안다 라는 마인드로 강의를 보지 않고 혼자 구현해보기로 했.. 20200926 T.I.L 오늘 한 일 조금 여유 있게 공부한 날이었다. 간단하게 todo 리스트 앱의 리뷰받은 사항들을 수정하고 리액트 리덕스 기본강의를 다 듣고 리덕스에 대한 기본 개념이 잡혔다. 처음에 영어강의를 들을 때는 정말 뭔 말인지 몰라서 멍하게 보고만 있었다면 이번에는 이해해가며 적용해가며 들었다. 사실 강의에서 쓰는 코드들이 세련되지는 않은 느낌이지만 강의가 가지고 있는 본질적인 내용이 잘 담겨 있는 명강의이다. 이런 강의를 무료로 배포해 준다는 것에 정말 감사드린다. 나같이 돈 아끼며 개발자를 꿈꾸는 사람에게 그저 빛일 뿐!! 리덕스에 대해 알고 싶다면! 이 강의를 정말 정말 추천한다. 리덕스: opentutorials.org/module/4078 리액트 리덕스: opentutorials.org/module/45.. 20200925 T.I.L 오늘 할 일 상태 관리에 대해 많은 정리가 되는 날이었다. 머리로 간단히 이해를 하고 코드숨 슬랙에서 어떤 분이 나와 같은 고민을 하셔서 글로 정리를 해서 올렸더니 정리가 착착 잘 되는 느낌이었다. const [todoList, setTodoList] = useState([]); const [todoInput, setTodoInput] = useState(''); 이 코드에 대한 답변으로 이렇게 답했다. "간단한 앱을 만들 때는 저렇게 상태 관리를 하면 todoInput값과 todoList값 이렇게 두 개로 서로 연동이 되지 않게 관리를 해주어서 todoInput값이 변화할 때 쓸데없이 todoList값까지 재할당이 되지 않는 장점이 있지만 관리하는 상태 값들이 많아지면 코드 자체가 길어져 가독성이 떨어.. 20200924 T.I.L 오늘 한 일 오늘은 이제 리뷰받은 부분들을 자잘하게 수정하는 것보다 원천적인 고민을 더 오래 하는 날이었던 거 같다. 사실 코드를 요청받은 고치는 것은 어렵지 않았다. 수정 요청받은 부분들은 충분히 내가 놓치고 있는 자잘한 부분들이기도 했고 혼자서는 알 수 없었던 궁금증이 해소되는 부분들이기도 했다. 중요한 건 역시 상태 관리에 관한 내용이었던 것 같다. state의 데이터를 어떤 구조로 어떻게 관리할 것인가에 관련된 것 말이다. 계속 리액트로 컴포넌트를 만들다 보니 상태 관리 라이브러리의 중요성을 너무너무 너무 느끼고 있다 ㅜㅜㅜㅜ 와 이 과제가 이렇게 나를 자연스레 리덕스로 이끄네~ 하는 느낌이랄까. 인강에서 리덕스에 대한 부분들이 나와서 자꾸 인강으로 회귀하게 된다ㅋㅋㅋ 근데 최대 단점은 영어 강의.. 20200923 T.I.L 오늘 한 일 자료구조에 대한 건 정말 어렵다 ㅜㅜ. 오늘은 리뷰를 받았는데도 리뷰에 대하 이해가 잘 가지 않았다. 객체와 배열을 어떻게 잘 구성하는지 아직은 완전 술술 쓸 정도로 익숙해지지는 않았나 보다. 이 부분에 대한 질문을 장황하게 다시 질문으로 달아두고 다른 작은 부분들을 수정했다. 사실 자잘한 부분들은 금방금방 수정해내기도 했고 고민하는데 오래 걸리진 않았지만 중요한 부분은 큰 문제들이다. 원론적인 문제들, 자료구조를 어떻게 만들 것인가? 컴포넌트의 재사용할 때 상태 관리의 중요성과 어떻게 관리할 것인가 하는 문제들 말이다. 많이 고민해보고 또 고민해보지만 이 부분들은 혼자 고민만 하는 것이 아닌 여러 공부와 조언들이 필요한 부분인 거 같다. 오전에서 오후까지 또 계속 고민하다 고민 부분을 다시.. 20200922 T.I.L 오늘 한 일 어제 Counter App을 만들면서 제일 의문으로 남고 찝찝했던 부분이 내가 짧은 코드를 작성하고 있기도 하지만 작은 컴포넌트를 바로 적용해 주지 않고 상위 컴포넌트로 감싸서 적용시켜주는 부분이 왜 필요한지 이해가 부족했던 거였다. 물론 상위 컴포넌트의 이름을 의도가 내포되어있게 짓기는 하지만 그게 컴포넌트 파일을 하나 더 만드는 수고를 할만한 가치가 있는가 싶었다. 그게 리뷰를 받으며 조언을 받고 싶었던 부분이었는데 오늘 정말 깔끔하게 이해가 됐다. 어마어마한 양의 코드를 작성하고 여기저기서 코드를 재사용하게 된다면 그리고 그 각각들이 다 다른 부분과 기능, 스타일까지 가진다면 과연 내가 이것들을 잘 분리하고 기능과 스타일을 부여할 수 있을까? 반드시 묶어줄, 구분시켜줄 상위 컴포넌트가 .. 20200921 T.I.L 오늘 한 일 저번 주의 두 번째 과제까지 통과를 받고 오늘은 새로운 내용을 배우기 시작했다. 리액트의 기본에 대해 배우고 있는데 내가 흥미롭게 느낀 점은 클래스 컴포넌트와 함께 배우는 것이 아닌 바로 훅스를 이용한 함수 선언 컴포넌트로 넘어갔다는 것이다. 리액트 공식 사이트에서도 훅스 사용을 권장하고 있고 현업에서는 훅스가 더 많이 쓰이기 때문에 훅스로 배워두어도 상관은 없지만 그래도 전에 클래스로 리액트 컴포넌트를 배웠었던 것이 다행이라는 생각도 든다. 뭔가 이중으로 배우면 함수의 동작원리나 라이프사이클에 대한 이해가 잘된다고나 할까..(기분 탓일지도 모른다.) 리액트와 리액트 돔, 컴포넌트와 props, 그리고 useState등 리액트로 DOM을 구성하는 법의 기초를 배우고 첫 번째 과제를 하기 시작.. 20200919 T.I.L 또 다음날 쓰는 19일 T.I.L 요즘 코딩에 집중하다 보니 자꾸 T.I.L을 잊어버리나 보다.. 두 번째 다음날 잊어버리기 전에 얼른 작성하는 T.I.L 하루 종일 고민하고 노력했던 부분은 if문에서 else를 사용하지 않는 법이었다. else를 사용한다는 것 자체가 SRP위반이기도 하고 의도한 바를 더 정확하게 표현하기 위해서는 Guard Clause방식을 사용하는 것이 더 효과적이기 때문에 else문 대신 Guard Clause를사용해주어야한다. 또 중요하게 배웠던 점 하나가 파라미터의 객체화였다. 파라미터들이 늘어나면 늘어날수록 코드가 길어지면 길어질수록 가독성 면에서나 의미적인 면에서나 파라미터를 객체화시켜주는 것이 좋다. 이 부분을 이해하기까지 조금 오래 걸린듯하다. 왜냐하면 객체화를 시키면 .. 이전 1 ··· 21 22 23 24 25 26 27 ··· 31 다음