prpos 로 상위에서 하위로 내려줄수있음. 루트요소에 리턴해주는게 중요하군. 모듈단위로 잘 나눠야한다. Example 같은 컴포넌트 작성의 네이밍 규칙도 있고, 컴포지션(합성)의 개념이라는 것도 있다. 스타일이 중복되고 재사용되는걸 아 이렇게 표현하는구나. 다 비슷비슷하네 묶어주는걸 의미하는군 children 이란 예약어가 있어 와 이걸 이제알았어. props.children ...ㅠㅠ 어쩐지 여기저기서 말도안하고 쓰더라 .. 요즘은 모든 파일에 react import 하진 않는구나. 과거엔 reactCreateElement 같은것도 있었군. JSX 문법은 대안이었구나. 하지만 명시적으로는 import react 다 써주는게 좋군. 컴포넌트 파일 구성은 보자... 그냥 정리하는거네 체계적인 폴더구분이 중요. state. ... 선언적 접근법... 인터렉티브의 기본이라. 모듈로 이벤트 정의 상태변경의 핵심은 이벤트를 어떻게 전달하는냐겠지. on으로 시작하는 이벤트들이 JSX에 내장되어있어. 이게 중요하네. 함수를 컴포넌트에 바인딩하는것. 그럼 이벤트 리스너에 등록 된다. 이걸 헨들러 방식이구나. () 로 해버리면 실행되니 주의.(포인터로 전달됨) 함수 이름의 관례는 뭐시기핸들러(clickHandler) 프로젝트에 따라 알아서 할것. 클릭핸들러가 컴포넌트에 반영된것이 왜 적용이 안된걸까 DOM에? 리액트는 이런식으로 동작하지 않음... 펑션콜을 React에서 평가할 때 실행 순서가 다르구나. 그럼 어캐바꾸는데? ㅇㅇㅇ.. 재평가 되는 방법은 state를 쓰는거구나 그래서 아ㅏ아....... 어쩑지 트리거되지 않았군 그래서 ..useState 라는 훅을 쓰는거구만 그냥 썻더니 아휴... 재호출되도록 하는 좋은 친구ㅏ. 배열과 업데이트 함수가 순서대로 인자에 반환됨. 그래서 title, setTitle 썼던거구나. 뷰랑 다르네 ㅇㅇ.. 스벨트가 좋다. 아무튼 훅으로 관리한다는 개념이 저런거구나.. state를 다시 보네 여기서. ㅇㅋㅇㅋ.재평가됨. 평가는 예약인것이고 바로 바뀌지 않는다. UX에서는 후에 바뀌기때문에 반영되는 개념을 기억해. 재평가 되는 과정은 빠름. 키컨셉임. const로 쓰는 이유는 컴포넌트 인스턴스로 등록하기 때문인거같은디? 변경되지 말라고 하는거 아냐? ㅇㅇ.. 그렇네. 잘못건드릴수있으니 특정 컴포넌트에서만 재평가하라고. 다른곳에 영향받지말라고. 결론은 useState 훅에 상태를 잘 등록해두자. 그리고 초기상태를 추적하는 형태가 있으니, state 추적이 가능한거군. 상태값과 업데이트함수를 기억해! 자. 이건 또 여러가지 로 업데이트 될 수 있구나. 입력값을 위한 폼 모듈에 대해 export default 로 정의한다. (하나밖에없으니까 ㅇㅅㅇ) 폼 만드는건 기본적이고... 잘 분리해서 관리하면 좋다. 사용자 입력은 어찌 관리하나... onChange 같은걸로 하긴 하네. changeHandler 에는 자동으로 event 가 넘어와 편리하긴하구나.state 다중관리도 있는데.... 방법은 뭐 useState 여러번 쓰는거아닌가맞네ㅋㅋㅋ event.target.value 오랫만~ 컴포넌트당 여러 상태를 가지는것은 좀 중요한듯... 근데 이 대신 쓰는 방법이 있다. 대안 대안 대안...같은개념으 반복되니 객체로 전달하면 한번에 된다. 아... 1키에 1벨류로 잘 관리하게 하려면 업데이트하지 않은 값은 수동으로 복사하는 구린 방법이 있는데, 아니면 스프레드연산자로 ...값을 잃어버리지 않게 채워주면 되네. *구려 흠... 좋은 방법의 이전 state에 의존하는 state 갱신은? function으로 이전 상태와 다음 상태를 업데이트하면서 얻는 방법이군.... prevState 개념이 이렇게 들어오는구나. 잘못된 스냅샷 상태를 손수 관리하는건 수동적일 수 있으니 함수로 작업하도록 하는게 좋다.
onSubmit에 핸들러 다는것도 있고...근데 이벤트가 쏴 지면 안되니까 .event.preventDefalut()로 만들어서 디폴트 시켜버리는구나. 쏘지말라고 ㅇㅇ.. 양방향바인딩~~~~ useState로 저장한 경우, 값을 초기화 하고 싶은데~ value를 초기화 하면 되겠지. 어... 어~ 무한루프 안빠지는구나... 의외네 .. 자. 부모에서 위로 올리는 방법. 끌올이랬지? 여기도 emit을 쓸까요? 글쎄요... .... . .... .... .. .. 아... 위에서 만들어준다음 아래로 내려서 거기서 리턴한다고? prpos로 핸들러에 담아 내려주고 값받아서 재정의한다. 으흥. 체인을 걸어서 또 위로 올려 app.js 까지 올릴 수 있긴하겠네. 관습은 on어ㅓㅉ구로 정한다. state 끌올~ (State up -lifting 이라 부르기도 함.) 아무튼 컴포넌트간에 직접적인 전달은 없긴함. 그치만 맨날 루트로 끌어오리진 않고 필요한 트리까지만 올리면 된다 'ㅅ' - 아... 사용자 지정으로 prpos 정해서 투방향 바인딩하는게 이 이래서 중요하군.
후... 처음으로 회고라는걸 해보고, 적어본다. 1년간 많은 일들이 있긴 했는데... 특히나 우울한것이 많았던 것 같다.
친구의 죽음 연초에 비보가 날아들었다. 2월 3월 계속 우울했던 것 같다. 아직도 1년이 다 되어가지만 그때를 생각하면 정신이 없다. 스트레스성으로 불안을 겪고, 모든것에 두려움을 느꼈던 것 같다. 선택장애와 반대로 빠른선택을 하게 되었고, 무차별적으로 결정하고 과감하게 저지르고 던지는 패턴을 반복했다.
퇴사 전배 사내에 이런 저런 윗선의 일들이 겹치면서, 집중적으로 성장할 수 없는 부담이 가중되었다. 업무조차 전혀 생각하지 않은 방향들로 흘러갔고, 데이터 업무가 가중되면서 (1)과 더불어 스트레스가 높아졌다. 프론트를 그렇게 하고 싶었는데, 잘 안되었던 것 같아 결국 옮기기로 결심했다.
중간에 스타트업도 면접을 봤지만 조건에 충족할 수 있는 조건도 나오지 않았고, 현재 내 위치가 어느정도인지만 확인했다. 너무 쓴 경험은... 내가 하고싶은 일은 내가 실력이 부족했으며, 별로 싫어 했던 일이 그래도 남들보다 어느정도 할 줄 아는 수준이었다. 문제는 해당 분야는 내 내면으로도 확실하게 재미가 없다 느끼고 있었고, 이쪽으로 경력을 쌓고싶은 마음이 없었다. 절대로 프론트가 하고 싶다는 마음을 절실히 담아서 어필했고, 그 길을 열어준 현재 조직에 너무 감사하다.
어쩌다 다시 인프라 사람 사는 일이 쉽진 않다. 하고싶은것을 하고 살아간다면 얼마나 좋을까. 강단이 있다고 해야할까... 사람들은 자신이 할 수 있는 일과 할 수 없는 일을 분명하게 표현하며, 결정을 내리는 사람들이 대부분이다. 나도 그렇게 하고 싶기는 했는데 그럴 처지가 아니었다. 아니. 그저 잠시 잊고싶었는지도 모른다. 아무생각없이 일을 잡고 싶었는지도 모른다...
뭐 살다보면 봄날도 오겠지 이런 생각이었나보다. 한달도 안되어 인수인계 해주고 떠나는 사람을 보면서... 착잡한 마음보다, 이 사람도 나 처럼 가고싶은 길을 가게 되었구나. 하고 인정해주었고 나 말고는 지금 딱 적절한 포지션이 없었기 때문에 그렇게 또 다시 일을 했던 것 같다. 잘 하진 못했다. 객관적으로 많이 부족했다. 나는 내가 늘 부족하다고 느낀다.
얼레벌레 제로 스터디 운영하던 스터디는 다들 취업하고 각자 공부의 계기가 된 것 같아서 뿌듯하다. 그래도 줄곳 상담해 주시는분도 있고 가이드 해줄 수 있어 다행이라고 생각한다. 포기하지 않고 취업하신분들도 대단하고... 가끔 만나긴 하는데, 잘 되어 만나는 것 만큼 좋은 일도 없다. 덕분에 회 잘 얻어 먹었다.
전반적인 회고
- 멘탈도 바닥으로 치닫고, 정처없이 떠돌기만 한 것 같지만...앞으로 좋은 일들만 있을거라고 생각하자. 내년에는 내가 할 수 있는것이 무엇인지, 사람들에게 더 도움이 될 일은 무엇인지 찾을 수 있을거라고 본다.
많이 부족한건 알고있다. 늘 부족하다 늘 노력하고 있다.
매번 잊어버리지만 지속적으로 반복할 수 밖에 없는 내 자신을 보면서 또 이렇게 한번 메모를 하고... 고생했다.
+ 연결리스트의 내용을 공부하고 정리한다. + 연결리스트의 정의와 성질 + 연결 리스트의 종류 + 단일 연결 리스트 (Singly Linked List) + 이중 연결 리스트 (Doubly Linked List) + 원형 연결 리스트 (Circular Linked List) + 배열과 연결리스트의 차이 + 1) 임의 위치에 있는 원소에 접근 = `O(N)` > 찾으러 가는것에 한세월... + 2) 임의 위치에 있는 원소를 변경 = `O(1)` > 변경은 빠름. + 3) 원소를 끝에 추가 = `O(1)` > 끝에 있는 것 추가라 + 4) 마지막 원소 제거 = `O(1)` > 끝에 있는 건 빠르지 + 5) 임의 위치에 원소 추가 = `O(n)` + 6) 임의 위치에 원소 제거 = `O(n)` + 이중 원형 (Doubly Circular) 연결리스트를 기반으로 기능 구현 + 1) 임의 위치에 원소 추가: `insertAt(...)` + 2) 임의 위치의 원소 제거: `removeAt(...)` + 연결리스트 관련 문제를 Leetcode에서 풀고 github에 공유한다. + 파트너 조원의 코드를 리뷰한다. + 본인의 피드백을 확인하고 수정하여 github에 올린다.
### 개인 + 배열의 내용을 공부하고 정리한다. + 배열의 정의와 성질 + 1) 임의 위치에 있는 원소에 접근 = `O(1)` + 2) 임의 위치에 있는 원소를 변경 = `O(1)` + 3) 원소를 끝에 추가 = `O(1)` + 4) 마지막 원소 제거 = `O(1)` + 5) 임의 위치에 원소 추가 = `O(n)` + 6) 임의 위치에 원소 제거 = `O(n)` + 기능 구현 + 1) 임의 위치에 원소 추가: `insertAt(...)` + 2) 임의 위치의 원소 제거: `removeAt(...)`
// 샘플 배열
const arr = [1, 2, 3, 4, 5]
const insertAt = function (targetArray, value, index) {
// 입력할 배열, 입력할 내용, 입력할 인덱스 위치
console.log('짱짱센,,, 인설트엣 친구를 동작합니다...')
let preArr = []; // 앞 배열
let postArr = []; // 뒷 배열
for (let i=0; i < targetArray.length; i++) { // 슬라이스 못쓰니까 열심히 잘라보자. O(n)
index > i ?
preArr[i] = targetArray[i]
: postArr[i] = targetArray[i] // 가독성 말아먹고
}
// preArr.length; // 앞 배열의 길이가 나올것이다. 끝에다 추가한다. O(1)
preArr[preArr.length] = value;
const loofFunc = function (weight = 0) {
for (let j=0; j < postArr.length + weight; j++) { // O(n)
if (postArr[j + index] !== undefined) {
preArr[j + index + 1] = postArr[j + index]
}
}
}
// index 0 용
if (index === 0) {
loofFunc();
return preArr;
} else if(index <= 0) {
console.error('index에 음수넣지말자..')
return []
} else {
// 리턴용 새 배열
loofFunc(1);
return preArr;
}
}
// 삭제할 배열, 삭제할 인덱스 아까랑 비슷하겠지....
const removeAt = function (targetArray, removeIndex) {
console.log('나약한 .. 리무브엣을 동작합니다..')
// 리턴내용 그것이 삭제된 새 배열
let preArr = []; // 앞 배열
let postArr = []; // 뒷 배열
for (let i=0; i < targetArray.length; i++) { // 슬라이스 못쓰니까 열심히 잘라보자. O(n)
// filter 안쓰고 하려니까 매우 어렵구나...
if (removeIndex > i) {
preArr[i] = targetArray[i]
}
else if (removeIndex < i) {
postArr[i] = targetArray[i]
}
}
for (let point = removeIndex; point < postArr.length; point++) {
preArr[point] = postArr[point + 1]
}
preArr.length = preArr.length - 1
return preArr;
}
const insertArr = insertAt(arr, 8, 4);
const removeArr = removeAt(arr, 0);
console.log('=======0ㅅ0======\n', insertArr, removeArr);
1. Utility > terminal에서 해당 명령어를 복사하고 다시 한 번 삭제 작업을 진행합니다.
명령:
sudo kextunload /Library/Extensions/PRISM\ Live\ Studio\ SoundDriver.kext
2. 명령어 입력하여 삭제 후 Finder에서
/Library/Extensions/PRISM\ Live\ Studio\ SoundDriver.kext
목록을 찾아서 삭제합니다.
- setTimeout : 일정 시간 후 호출함. 사용법은 간단함. 함수를 실행하지 말고 함수 자체를 넘길 것 이란 경고 정도와 id 반환해서 clearTimeout(타이머식별아이디) 정도로 스케쥴 관리 하는 것만 하면 될 것 같다.
setTimeout(sayHi, 1000, "인자", "인자2");
- setInterval : 위랑 동일한 문법인데, 계속 반복하는가, 1회성인가 차이이다. (인터벌은 계속 반복), clearInterval 할 때 까지 지속 반복하니 잘 쓸것.
- 중첩 setTimeout : 일정한 간격으로 실행하는 방법인데, 딜레이 증가 시킨 후에 성공하면 딜레이 초기화 하는것도 넣어주는게 좋다. (뭐 별개 이야기로는 셋인터벌은 너무 작은 시간에 대해 반복되는경우, 반복카운터도 구현해야하고, 그게 근데 딱 잘라서 동작한다는 보장도 없기도하지만..하단에 그림으로 잘 설명 되어 있음.)
clear 하기 전까지 둘 다 메모리에 존재하는 것. 잊지않길.
- 대기시간이 0초인 setTimeout : 🙂한국말로 써있는거 맞지? 즉시 실행 한 것 과 같은 효과를 내는 것 처럼 보인다고 어필하는 것 같아. (실제론 0이 아니라 밀린다고 표현되고)
하단에 브라우저 환경에서 실제 대기시간은 0이 아니라는 부분은 "5번재 중첩 타이버 이후 대기시간을 4ms 로 강제" 하라는 부분이 명시되어 있어서인데, 그냥 넘어가도 된다. 구형브라우저 레거시 대응에 대한 것 때문에 명세변경을 못하고 있어서...🥺
- call/apply 데코레이터, 포워딩 : 재밌는 주제다. 데코레이팅 - 꾸며주고, 포워딩 - 이어주고 어떻게 하는지 알아본다고 한다.
- 코드 변경없이 캐싱 기능 추가하기 : 핵심은 코드 변경 없이 이다. 뭘까 좀 더 살펴보면 메모라이제이션과 흡사하다.
메모라이제이션이란? -> 9 * 7 = 63인데 이걸 계속 반복 할 때 마다 9 를 7번 곱하고 하고 있으니, 63이란 결과를 어디 저장해놓고 key나 인자로 9, 7 이 들어오면 첨에 한번 계산했던걸 서랍에서 쨘 하고 꺼내주는 걸 말한다. (즐겨찾기, 북마크 비슷하다고 볼 수 있다.)
- func.call 를 사용해 컨텍스트 지정하기 : 실행컨텍스트를 잘 생각해 보면 함수에서 worker.slow 를 받아서 func로 바꿔서 실행 하려고 해도 캐싱을 하려고 데코레이터를 만든 부분에서 func 자체의 this가 undefined 라고 표시하고 있다. 맞는 말인데 이렇게만 써두면 어 그런가보다 하고 넘어갈 수 있는데... 지금까지 잘 따라 온 사람들은 함수의 실행 위치에 따라 this 값이 바뀌는 부분을 생각 해 낼 수 있을거라 느낀다. - 근데 바로 아래 내려가면 설명 함 ... 아니 다음쪽 🔥 사라진 this 컨텍스트를 call을 통해서 원하는 범위로 고정할 수 있는 방법에 대해 설명을 하고 있다.
파랗게 선택 한 function (x)
하단의 설명한 부분에 문제는 없는 것으로 생각 됨.
- 여러 인수 전달하기 : 캐싱데코레이터를 조금 더 가지고 놀아본다. 인자를 2개를 받는걸 만들어 보려고 하는데, 이 경우 중첩맵을 쓰거나, 키를 중복으로 쓰는 라이브러리를 쓰거나, 두 키를 합해서 하나의 키로 만들어 해싱함수로 만든다고 세가지에 대해 소개하면서 마지막걸 썼다.
- func.apply : 아래 16줄 대신 쓸 수 있다고 한다.
스프레드로 args를 펴 발라 하나하나 분해해서 call에 넣어줬는데 apply를 쓰면 유사배열객체가 넘어가도 하나하나 분해해서 끄집어내 넣어주니 이 얼마나 좋은가. 하여 이것을 쓴다.
- 메서드 빌리기 : 앞에서 구현한 해싱을 개선해보자고 한다. args 대신 여러 인자를 받는 낡은 arguments 를 활용해서 해결하려 함. 유사객체배열에는 join이 없기 때문에, 이걸 사용하기 위해서 빈 array에서 join 메서드 call 을 통해 빌려 와 해결했다.
- 데코레이터와 함수 프로퍼티 : 음... 뭔가 주어를 살짝 빼먹고 하는 것 같아서 이해가 살짝 안되넹, 오리지널인이 되는 원본 함수에 func.calledCount 속성이 있으면, 중복된 친구인 데코레이터 속성은 감싼 래퍼이기 때문에 사용할 수 없는 그런 문제가 있나본데, 예시까지 들어서 slow 가 속성으로 있으면 데코레이터의 slow 는 래퍼라서 쓸수 없다는 소리같은데 확신을 못내리겠네... 뭔가 말을 장황하게 한 것 같은데 -_- 한국어 맞아?? 일어는 아예 해석을 포기했나 항목이 없고... 영어도 이상하고.. 일단 넘어가고 나중에 확신이 서면
- 함수바인딩 : 잃어버린 this를 찾아서... 맨날 사라지는 친구 어떻게 가져와서 잘 쓸지 고민될 때! !!!여러분은 바인딩을 합니다!!! 라고 광고...
- 사라진 this 🥺 : 사라지는걸 구경 해보자. 사용자라고 유저 객체를 만들고, 프로퍼티로 퍼스트네임에는 존 메서드 (ES6 문법으로) 세이하이라는 친구를 만들어서 내부의 this로 유저 객체에 접근하게 한 후, 퍼스트네임을 찍어주는 친구를 만들었다.
자 일단 그래 열심히 만들었으니 확인해보면 언디파인드가 뜨니 당황스럽다.
함수 실행 위치를 잘 생각해서 user.sayHi가 window가 있는 전역에서 실행이 되었다. sayHi 친구는 전역! 전역... global 에서 실행이 되었으니, 본문에서 말하는 부분인 window 에서 실행이 된 것이다. sayHi는 global 에서 firstName을 찾기 시작하지만, 집(user 라는)안에 들어있는 firstName 을 불러도 찾을 수 없...
그래서 해결책이라고 제시하는데
- 방법 1: 래퍼 : 가장 간단하다고 한다. (당신으 ㅣ입장에서) setTimeout을 사용해서 user를 받아 호출하기나 화살표 함수로 똑같이 구현 하는 등. 전역 렉시컬에서 벗어나게 하는 방법이다. 1000ms라는 1초의 시간 사이에 user의 firstName이 바뀔 수 있고, sayHi가 바뀔수도 있는 부분이다. 다른 사람을 부른다던가, 다른 내용을 동작하게 될 수 있다는것이다.
- 방법 2: bind : 모든 함수는 this를 수정하게 해 주는 내장 메서드 bind가 있다고 함. - 간단하게 함수.bind(this로 지정할대상컨텍스트) 지정하면 해당 내용으로 지정 된 함수가 실행되게 된다고 한다. 리액트에서 class 문법으로 작업 시, 엄격모드가 적용되어 bind가 안되어 있는 경우가 있기도 한다.
- 부분적용 : 인수 바인딩을 이야기 하네. 사용법은 간단. 기본 this로 바인딩할 컨텍스트 부분을 bind(null, 뒤에 인수를 넣는다) 써본적 없는데 써봐야징.
- 컨텍스트 없는 부분 적용 : bind의 컨텍스트 null 같은게 아니라 아예 없는걸 하고 싶단건데, 헬퍼 함수 partial 을 만들어 주면 된다.
모던JS 튜토리얼 읽으면서 드는 생각 메모 6장의 마지막 메모.
- 화살표 함수 다시 살펴보기.🔁 : 짧고, 독특하고, 유용하다. 현재 컨텍스트를 잃어버리지 않는다. (가장 스코프 체인 상의 가까운 컨텍스트에 쫄래쫄래 디스있니? 하고 놀러 가기 때문에)
- 화살표 함수에는 this 가 없다 : 두둥. 본문에서 접근하면 외부 값을 가져온다... 두두둥! forEach에 화살표 함수를 썼기에, 바깥의 group와 같아짐. 반대로 일반 function 을 쓰는 경우, 일반 함수 실행 컨텍스트에 따라 global 에서 찾게되고, title을 못찾거나 name을 찾게되면 엉뚱하게 빈값을 출력하는 모르는 경우 기가막힌 상황이 연출 될 수 있다.😭
기타 - 생성자가 없어서 new 불가(만들고 컨스트럭터 걸려있나 보던가..) 화살표 vs bind(this) - 바인드는 범위가 있고 화살표는 묶어서 한정짓지 않는다. 단지 this를 빌료와서 가장 가까운 스코프체인상 실행 컨텍스트에 가서 찾을 뿐.
잡담을 너무 많이 안썼네, 간단한 생각은 글로 쓰는것보다 다른 SNS에 적는편이 좋아서 여기에 안남기는 편이다.
그래고 긴 고민들이 많이 있으니 적어보려고... 커리어라는건 대체 어떤건지 모르겠다. 실력을 평가하는 기준에 있어 남들이 요구하는 스킬을 맞춘다 하더라도 결국 연차가 쌓이고나면 남의 선택과 강요에 의해 만들어진 기술이다. 이것은 과연 내가 만족한 결과인가 고민하게 되었다. 하고싶은것은 무엇이었을까 다시 생각하고 고민하게 되었다.
스스로 결정하고 스스로 발걸음을 내딛고, 스스로 선택을 하고 갈 길을 알아본다는건 대단히 중요했다. 실패할 수 있는 두려움을 가지고 약간은 준비가 안되고 부족할지라도.. 위에서 남들이 요구한 스킬이었다면 이번엔 내 자신이 요구하는 스킬을 채워나갈 수 있다는 자신감으로 새로운곳에 문을 두드렸고 결과는 나쁘진 않았다. (스스로는 나쁜 것 같았는데...)
고민은 결론을 내려놓고 시간을 소비하는 과정 같다.
언제 시행할지... 정말 해도 될지...
그냥 두려워도 하는게 중요한 것 같다.
hello world 를 처음 찍어보는 것 처럼... 글 쓰고보니 아직 플러터 시작도 안했네 ^ㄴ^
- 함수의 구분 : ES6 이전과 ES6 이후의 함수를 사용하는 목적과 몇가지 종류로 구분하는 이야기를 한다. 참... 과거엔 복잡했구나 싶다. ........ 그래서 ES6부터 크게 3개로 나눴구나...
화살표 함수 부족한 사람은 여기서 익혀가면 좋고... 생성자도 없고 프로토타입도 슈퍼도 agruments 도 없는 그런 슬픈 친구 하지만 깔끔한친구. 가장가까운곳에 척을 두고있는 친구... 언제나 생각하지만 얘 없었으면 코드 많이 너저분해지지 않았을까.(빌드기준) 뭐, 메서드의 부작용은 this 위치만 잘 알고 함수 생성 표현도 메서드쪽에 간단한 친구도 생겼으니 적재적소에 뭐든 잘 사용해야한다는 생각이 들었다.
아 근데 이 앞장에 클래스에서 생성자 없이 쓰면 사파리는 왜 안되거지? 크롬 72 이하에서도 안되던데... 미구현이 확실한건지 뭐라고 딱 말을 못하겠는게 아직 안되는게 많나보네? 음... 이건 좀 더 상세하게 알아봐야겠는데 요즘 잠깐잠깐 이 책에서 듣는거 말고 시간이 별로 없군... 음 Rest 파라미터, 함수에 요즘 새로나온 (이건 좀 아닌가)
급 회고 ???? 실은 읽는게 너무 느린거같아서 이 책 천페이지 넘는데 어느 세월에 하나하나 나눠서 읽고있어... 기존에 책 읽던 방식대로 훑고 넘어가고 아 전에 저기에 뭐가 있었는데 하고 인덱스 기억하는 식으로 해야겠다... 핵심적인 부분은 일단 차근차근 짚어서 넘어갔고, 이번달에 스스로 정한 CSS도 보는 진도율과 목표치에 부합하지 않으니 다시 기존 방식으로 돌아가야곘다. 하나 하나 짚어보고 생각하고 적자니 너무 오래걸렸다. 되풀이 하면서 생각해봐야지. ㅠㅠ
- static을 메서드명 앞에다가 잘못쓰면 에러도 안나고, 동작이 안되는 경우가 있네.. 아무래도 해당 클래스 내에서만 써야하는것 같은데 이렇게 잘못 제한을 잡아 막은 경우에는... 동작 안하는 건에 대해 어떻게 디버깅 하면 될까나... 흠~..... static 코드에서 안써야지.....에러로그로 안남네. - ref는 사용법이 뷰랑 비슷한듯. - 리액트 공식 한글 문서 11장 12장 내용 왜이렇게 헷갈리게 써놓은건지 모르겠네 자습서에 틱택토 해보면 해결되고 이해할 수 있는 내용을 꼬아놓은 것 같다. A는 B다 하면 되는데 A는 블라블라해서 와하니 B한걸 우리는 B라 하고, A' 라고 하는걸 그럼 이제 B' 라고 부를 수 있게 된거다. 라고 써둔거 같아서 보는데 너무 힘들었다. 공식문서는 뷰가 진짜 보기 편했다.
- 리액트에서 그럼 리플로우랑 리페인트(리드로우) 대신에 종합적인 리콘실리케이션(재조정 or 조화과정)으로 납득하고 넘어가면 되는것인가. 갈아끼우면 끝인가... 나는 헷갈린다 -ㅅ- ... render 함수가 대충 이전과 이후 컴포넌트 돔 트리 꼬라지를 보고 다른 부분이 있으면 그부분을 교체하는건 알겠는데... 복합이야 이거? 진짜? DOM 자체는 문제가 없는데 리페인트 할 때 어떤걸 하는진 까봐야하나..
아무튼 성능면에서는 다들 짱이니까 쓰고있겠지? 맨날 편하다고 뷰만 쓰다보니 거의 생각없이 코드짜곤 했네. 최적, 효율, 그런걸 만들었나보다. 하고 지금은 생각 중... (그래 그거 가상돔 그거, 뷰도 있는 그 가벼운 버춸돔 그거)
- 아직 그리고 JSX가 익숙하지 않다. 한달쯤 지나면 익숙해질 수 있을까? 흠... 이제 곧 한달인데... -ㅅ- 책산걸 꺼내서 훑어보자. 옛방식을 쓰고있네... ㅠㅠㅠㅠ 전자책이면 전자내용도 업데이트 되면 좋겠다
var(--변수명); 써서 잘 만들고, 동작하나 확인하자. 마지막으로 필터까지 먹이면 완성~ 아. 클래스 h1 ... JS 글자까지 먹이기 ^^
CSS 변수를 업데이트 해보자꾸나.
도쿠먼트 쿼리설랙트 올~ (.countrols input)~ 😓 ... 해서 각 컨트롤러의 값을 받자. 이것은 유사 배열 객체요. 상속받은 메서드들이 참 많다. 핸들 업데이트를 하나 만들고, 반복을 돌며 변경되는경우, 핸들을 건드리면 이벤트를 받는 콘솔을 찍어보자. 드래그 해도 체인지 하고 싶으면 마우스무브로 바꿔라. 난리난다.
😭 아무쪼록, 근데 이 CSS와 input을 바인딩해서 연결을 해야할 것 같은데 어떻게하느냐가 중요하니까 dataset을 통해서 돔에 data-어쩌구저쩌구로 하면 에 저장해둘 수 있는 공간이 생긴다.
... 아 똥같네... 예제가 ㅠㅠ 아무쪼록, suffix 를 하나 만들어서 사이즈를 받아보자. 없으면 || '' ; 해서 초기화 하는걸로
아무튼 사이즈를 다 가져오고 아닌경우 안받아오니 좋은 예제이다.
가지고온 네임을 이용해서 document 의 set property를 위에서 만든 변수명으로 지정한다. 이런식으로 바뀌는 변수명을 업데이트 할 수 있다.
20장 - 엄격모드 : 🙂 적용 할거면 다하고, 부분적으로 섞어 쓰지말고, 린트를 쓰는것도 좋다.
21장 - 빌트인 객체 : 여러가지 객체의 분류를 다루어 주었다. 빌트인 객체, 원시값이 있는데 왜 있는지, 전역객체(새로나온 globalThis), eval은 쓰지말고, 암묵 전역의 경우도🙂... 음...😓 개인적으로 사람들이 안썼으면 좋겠다.
22장 - this ✨디스! 이것! 이건... 이거다! 이 챕터도 중요한 챕터다. 자기자신! 식별자가 없으면 식별할 수 없잖어... 그치만 함수의 경우 기명 함수 표현식으로 재귀 식별해도 되긴하는데 쫌 모양새라고 해야하나... 어렵잖아... 사람이 보기에... 그래서 클ㄹㅐㅅㅡ..... 함수호출 방식에 따라 정적(렉시컬) 스코프에선 this 바인딩 시점이 좀 다른거랑... 뭐... 프레임워크 다루게 되면 일반함수 호출은 거의 안할거고 메서드나 생성자로 많이 쓰게되니, 오해하는 경우가 있다. 호출 방식에 따라 바인딩 되는곳이 다르다. 아. bind는 은근 꽤 많이 쓰인다... 그러니까 마지막의 표 주의깊게 볼 것.
23장 - 실행 컨텍스트 : 중요한장이다. 이 실행 컨텍스트라는 친우의 역할을 알려준다. 전역 객체 생성(객체환경레코드) -> 전역 코드 평가 -> 전역 코드 실행 -> 함수 코드 평가 -> 함수 코드 실행의 과정을 익히고 실행스택, 스코프, 렉시컬환경의 이해도를 높여주었다.🔥🔥🏓 렉시컬 환경은 - TL;DR... 컴포넌트로 구성되어있고, 전역환경레코드, 객체환경 레코드랑 선언적 환경 레코드 이런건 첨듣네 ㅠㅠㅠㅠㅠㅠㅠ 얼마나 이 무지했단말인가 ㅠㅠ그냥 메모리 저장인줄알았지ㅠ레코드가 있었구나ㅠ ES6에서 그럼 선언적 레코드 환경이 새로 추가된건거구나. let const 를 위해서.. .. ㅠㅠㅠㅠㅠㅠㅠ그림 23-24 ㅠㅠㅠ 참 친철하네..
24장 - 클로저 : 얘도 중요하잖아... 아니 이책에 안중요한게 없는 것 같다. 근데 앞에 실행컨텍스트랑 렉시컬 환경 험한거 지나와서 정말 책에 써있는데로 쉽네. 그림 24-1을 참고하자. 이전 실행컨텍스트 장에서 나왔던 내용을 환경을 추가해서 더욱 잘 설명하고 있다. 외부함수보다 ㅁㅁㅁㅁ가 긴 내부함수. 이러한 중첩 함수가 클로저. 캡슐 정보화 은닉의 경우, 직접 접근하면 안되는 정보를 대표적인 우리들의 모던한 예제인 makeCount 함수로 표현하고 있다. 이건 모던 자바스크립트 튜토리얼에도 나오는 좋은 예제. 거기에 더해서 두번 호출하는 딥다이브를 보여주는군...🥺 두번 호출 하면서 생기게 되는 자유변수 공유 문제 해결을 표현하고... predicate MDN: 클로저는 함수와 함수가 선언 된 렉시컬환경의 조합이다. 😇
25장 - 클래스 : 문법적 설탕인가? ... ㅇㅇ 난 설탕이라도 맛있으니 새로운 객체 생성 방법으로 필요한 절차라고 생각했다.🙂 418쪽에 4번이 최근 당한 내용이네... 암묵적으로 strict 적용 되는 부분.😓 클래스명에 파스칼 케이스는 쓰는것을 권장 함.
함수로 평가되는것과 호이스팅이 되는구나. 다른 언어의 교육에서 붕어빵틀로 표현하... 는 클래스... 인스턴스 생성 안하면 무용지물이니까 new 연산자 없이 쓰면 ... 음 그렇군...🙂
클래스 문법에 익숙해지면 프로토타입으로 했던것보다 손쉽게 구현할 수 있구나. Prototype 메서드와 Static 메서드의 차이점을 이야기하는구나.. Static 공간이다 보니까 내꺼만 쓸 수 있군. Math.max 같은걸로.
옹...✨클래스 몸체에 정의하는 방식이 ....... 생겼는데 25-69예제 super는 여기서부텉 다시 좀 봐야겠네 졸리나 ㅠㅠ...
