++ 연산자 관련 알게된 사실 : 본래 이런식으로 ++ 연사자를 쓰면 num = num + 1 한 것과 같은 결과를 내는 것은 알고 있었다. 그러나, 이렇게 앞에다 ++ 연산자를 써도 같은 결과를 낸다는 것을 알게 됐다. 사실 ++ 연산자를 이렇게 써본적이 없었기에

: 개발을 하다보면 초기 렌더링 시기에는 useEffect 내의 로직을 쓰고 싶지 않지만, 초기 렌더링 이후에는 쓰고 싶을 때가 있다. 이 때마다 컴포넌트 외부에 변수를 선언해놓고 componentDidMount 시점에 변수에 false/true 등의 값을 줘서 개발하

useEffect의 dependency로 static한 데이터를 넣었을 때, 만약 다른 setStateAction과 엮인 state가 업데이트 돼서 컴포넌트가 리렌더링되면 state에서 특정 객체 내의 특정 값을 dependency에 넣었을 때와 마찬가지로 특정 값이

contextAPI를 사용할 경우, Provider의 children 요소들은(바로 하위 컴포넌트) 반드시 리렌더링 된다(React.memo와 상관없이). 하지만 children의 children에는 메모가 적용된다. 이는 결론적으로 contextAPI를 쓰면 Prov

GPU를 쓰도록 css 설정을 하고 싶을 때 '레이어 핵(Layer Hack)'을 쓸 수 있다. 예를 들어, 위와 같은 흔히 알고 있는 CSS style에 3d를 붙여주면 GPU 가속을 활성화시킬 수 있다고 한다. 그러나, GPU 가속을 사용하면 웹 페이지의 렌더링 속

Today I Learned Provider 내부나 어쨌든 Component 내부가 아닌 곳에서 setStateAction 타입을 호출한다해도 그 아래에 속한 하위 컴포넌트의 리렌더링에는 영향을 미치지 않는다. setStateAction이 리렌더링 시키는건 컴포넌트

: 하나의 redux state 단위(객체라고 했을 때)에서 하위 depth의 프로퍼티 값을 변경했을 때(dispatching),useSelector 가 뭐를 타겟으로 하고 있냐에 따라 리렌더링 로직이 어떻게 바뀌는지를 확인하고자 합니다.예를 들어, server 라는

프로그래머스 코딩테스트 연습 - 나머지 구하기: 너무 쉬운 구몬 학습과 같은 문제들이지만 너무 오랜만에 코테 문제를 풀어서 이렇게 가벼운 문제들로 워밍업을 해보고자 풀어본다(왜 혼자 핑계를 대시고 계시죠..?): 문제는 너무나도 간단하다. 너무 간단해서 나만의 룰을 추

프로그래머스 분수의 덧셈 문제: while 문을 써서 분모를 통합하고, 그만큼을 분자에 곱해주고, 말그대로 분수의 덧셋 패턴을 이용해서 분수를 더해 준다음에 구한 값의 분자, 분모의 공약수를 써서 다시 기약 분수로 나타내면 되는 문제이다. 나는 굳이(?)라기보다는 좀

최상위 컴포넌트인 index.tsx에서 위의 코드에서 아래와 같은 TS2345: Argument of type 'HTMLElement | null' is not assignable to parameter of type 'Element | DocumentFragment'

useEffect vs useLayoutEffect 1) useLayoutEffect layout !codesandbox[jolly-jasper-qkx9zr?fontsize=14&hidenavigation=1&theme=dark] 위의 버튼을 눌러보면 UX 상으로

: 짤막한 상식 기록: 결론적으로 상위 컴포넌트에 없는 변수를 props의 키와 값으로 설정해놓고, 하위 컴포넌트에서 그 키값을 받아서 렌더링하면 자동으로 true가 된다. 프로젝트 코드를 분석하다 이게 왜 true지? 해서 알아봤는데, 저렇게 돼더라,, 자동으로 리액

: SOP(Same Origin Policy)에 대한 일종의 관용책(?) 요즘 같이 다른 origin을 가진 사이트 간에 request & response 통신이 많은 시대(?)에 맞춰 CORS Policy가 나왔다. 즉, SOP만 있던 시절에는 사실상 같은 origi

: 이 글 이전에 2개의 포스팅을 하면서 Redux MiddleWare에 대해서 열심히(?) 알아봐놓고 갑자기 middleware 없이?에 대한 주제로 글을 써본다. 여담이지만 Frontend 개발 시장의 변화 속도는 너무 빨라서 비유적으로 표현해보면 나는 이전 프로젝

Despite its simplicity, thunks have limitations. One of the most cited limitations is the inability to run code in response to dispatched actions or s

: 흔히 redux의 비동기 처리 로직 혹은 사이드 이펙트를 처리하기 위한 용도로 redux-thunk나 redux-saga를 많이 사용한다. 이번 포스팅에서는 앞서 말한 redux와 연관되는 라이브러리가 필요한 이유부터 시작해서 각 라이브러리의 장단점을 가지고 서로를

: 본래 React를 쓰면서 'state 끌어올리기'에 부담을 느끼거나, 불필요한 props drilling 등이 이슈가 되면서 전역적인 state 관리법이 필요해졌고, 그에 대한 해답(?)으로 나온 것이 Redux라고 할 수 있다(React + Flux 패턴). 하지

최종 마무리 사항env 파일에 firebase config 파일 넣기핸드폰 기종별 반응형 UI 완성error 처리React Native 플젝 만들고, web view 심기배포

recordModal 에서 이전 기록을 수정할 수 있도록 하는 기능workout 단위로 삭제할 수 있는 기능운동 이름 바꾸기 or 특정 운동 기록 자체를 삭제(예를 들어, 푸시업을 했으면 푸시업 set를 전부 삭제)set 수정 및 삭제(kg, reps를 수정할 수 있음

recordModal 에서 이전 기록을 수정할 수 있도록 하는 기능workout 단위로 삭제할 수 있는 기능운동 이름 바꾸기 or 특정 운동 기록 자체를 삭제(예를 들어, 푸시업을 했으면 푸시업 set를 전부 삭제)set 수정 및 삭제(kg, reps를 수정할 수 있음