.gitignore 파일에 분명히 .env가 있는것을 확인하고 push 했다고 생각했지만 … 확인해보니 github에 기록이 남아있게되었다! 이유를 찾아보니 파일을 생성하기 전 이미 git에 .next를 올렸기 때문에 적용이 되지 않는 것이라고.. 아마 env 를 무시하였으니 그 이유가 아니었을까 다시 한번 더 조심하자고 느꼈다.
이 사이트에서는 좀 더 체계적으로 commit 이력을 삭제하는 방법을 알려주었지만 역시 컴플릭트 문제를 먼저 해결해야만 하는 것일까. 일단 deploy 상태인 것을 정지 시키고 새롭게 짜는게 더 빠를지도 모르겠다.. 원본 파일은 있으니 그게 더 빠를 것같기도 하지만 혹시 실제로 이렇게 될 경우를 아주 조금이지만 대비하는 측면에서 조금만 더 살펴보도록 하자
next js의 Image url 파싱할떄 초기 설정이 필요하다는 부분을 배웠다. next.config 설정시에 url 의 내용을 파악하고 jpg인지 png인지 혹은 null 일때 처리는 어떻게 해야하는지에 대해서도 한번 깊게 생각하는 계기가 되었다.
getServerSideProps와 getStaticProps 를 실제적으로 경험하여 SSR과 CSR 의 차이를 어느정도 알게 되었다. getStaticProps는 최초 빌드 시에 딱 한 번만 호출된다는 점이 매우 중요한 차이를 만든다는 것을 알수 있게 되었다. 예를 들어 notion api 사용을 한다고 getStaticProps를 사용한다면 notion을 수정한다해도 getStaticProps를 쓴 페이지는 변함이 없다. 반대로 getServerSideProps는 실시간으로 렌더시에 데이터가 수정될 경우에 사전렌더링이 되기 때문에 promise 를 통한 비동기 방식으로 데이터를 받아온다면 실시간 변동도 바로 확인이 가능하다. 왠만하면 수정이 거의 없는 상품 설명서, 또는 제품 목록 등은 SEO를 생각하면 getServerSideProps가 좋지 않을까 생각해본다. 밑에와 같이 ({ params })과 같은 객체를 넘겨 API주소를 변동시켜서 데이터를 바꿀수도 있기에 다른 방식으로도 써볼 생각이다.
1 2 3 4 5 6 7 8 9 10 11 12
// getStaticProps 페이지 안에서만 쓸수 있다. export async function getStaticProps({ params }) { // API 호출 const response = await fetch(`https/example.com/posts/${params.id}`); // const post = await response.json();
return { props: { post }, // 컴포넌트가 전달받을 props 객체 revalidate: false, // 페이지의 Regeneration을 수행하기 위한 유예 기간 notFound: false // 404 페이지 반환 여부 (fallback: false일 때는 불필요) }; }
nextjs는 React로 만드는 서버사이드 렌더링 프레임 워크다. 서버사이드렌더링이란 브라우저 혹은 클라이언트에서 실행하지 않고 서버측에서 데이터를 실행하여 모든 js 파일을 로드하고 그 데이터를 웹상에서 먼저 확인 뒤에 사용자는 웹을 보게된다
기존의 react의 구동원리는 클라이언트 사이드렌더링 방식이며 이 경우에는 자바스크립트가 dom을 생성하기 전에는 아무것도 파악되지 않아서 문제를 만들게 되는데 그 문제의 대표적인 문제가 SEO의 부재처리가 될 것이다.
SEO(검색 엔진 최적화)라는 것은 구글의 검색엔진만의 문제가 아닌 대부분의 검색엔진에서 서버사이드렌더링 방식의 데이터만 파싱되기 때문에 검색에 걸리지 않고 그것은 바로 매출에 큰 악영향을 주게 됩니다. 프론트엔드만의 문제가 아닌 회사 전체의 사활이 걸린 문제라고 할 수 있다.
Next.js의 이점
그러한 SEO문제를 NEXT.JS에서는 두가지 방식을 한번에 쓰는 것으로 해결하였습니다. 데이터를 인식하게 할 부분( meta ,description ,keyword etc)은 서버에서 자바스크립트를 로딩하게 하며 ( Server Side Rendering) 비동기적인 부분이나 api를 통해서 새로운 페이지를 불러오는 경우에는 클라이언트 사이드 렌더링(Client Side Rendering)을 통해 빠른 속도로 데이터를 처리하는 것이 nextjs의 큰 이점이라고 생각한다.
html에서 자주 쓰는 Html, Head와 같은 방식으로 서버사이드 방식으로 할 부분을 지정하는 기능이다 모든페이지에 아래 메타테크가 head에 웹 타이틀,ga,meta기능을 추가하여 SEO적인 부분을 크게 보완하였다.
Link 기능
보통 페이지간 이동은 a 태그를 사용하나 next에서는 사용하지 못한다.
a 태그를 사용하면 처음 페이지에 진입시 번들 파일을 받고, a 태그에 의해 라우팅 되면 다시 번들 파일을 받는 것이 문제가 되기에 또한 redux의 경우 store의 state 값이 증발되는 현상도 일어난다. 그렇기 때문에 a 태그는 전혀 다른 사이트로 페이지를 이동시켜 다시 돌아오지 않는 경우만 사용하고, 그 이외에는 모두 Link 태그를 사용합니다.
getStaticProps
페이지에서 (정적 사이트 생성) 이라는 함수 를 내보내는 경우 Next.js는 빌드 시getStaticProps를 통해서 반환된 props를 사용하여 페이지를 미리 렌더링하기 위한 기능이다. 보통 api나 데이터 파싱을 하고 그 데이터를 서버에 남겨 데이터를 SEO에 기여하고 싶을 경우에 사용한다.
javascript Event는 매우 방대해서 아직 안써본 기술들이 많았다. 그중에 잘 쓰지 않았던 것들은 한번 정리해보려고 한다.
Event.stopPropagation() 자바스크립트에서 stopPropagation() 메서드는 event 객체의 버블링을 제거하는데 유용한 메서드이다. 예를 들어 검색을 하고 클릭을 하는 이벤트를 만들어두었을때 어느 순간에는 클릭만 되게 만들 필요가 있을 것이다. 이벤트 버블링 와 함께 매우 자주 사용되는 중요한 메서드입니다.
여기서 event 버블링이란 이벤트가 연속하여 발생하는 버블 현상을 의미한다 .이벤트는 이벤트캡쳐링과 이벤트버블링으로 나타나는데 클릭이 발생한 경우를 예로들면 클릭 시점에 해당 위치에서 이벤트가 발생하고 발생하고 다시 겹쳐진 요소를 올라가면서 해당 엘리먼트의 이벤트를 다시 발생시키는 현상을 의미한다.
리엑트 엘리먼트를 통한 방식에서도 유용하게 쓸수 있어보였다
1 2 3 4 5 6 7 8 9 10 11 12 13 14
let div=document.createElement('div') div.innerText='testing' div.addEventListener('click',()=>{ console.log('test1!') }) document.body.append(div) let div2=document.createElement('div') div2.innerText='testing2' div2.addEventListener('click',()=>{ console.log('test2!') }) div.append(div2)
//VM997:1 test1! div1을 클릭했을 때는 test1!만 출력 //VM1315:1 test2! //VM997:1 test1! div2을 클릭했을 때는 이벤트 버블링 발생 둘다 출력
event.defaultPrevent()
defaultPrevent는 기본적인 html의 기능을 막을 수 있는 메소드이다.체크박스의 클릭 기본 동작,a 태그의 링크 이동 select 선택 기능 전부 다 막을 수 있다. 실질적으로 필요한 경우는 다른 이벤트를 넣었을때 체크박스나 셀렉트와 같은 기본기능이 필요없을 경우에 사용할 수 있지않을까 생각한다.
react와 javascript 를 하다보면 값이 TypeError: Cannot read property ‘?’ of undefined 라는 에러를 자주 만나게 된다. 이 방식을 가장 쉽게 해결하는 것이 옵셔널 체이닝이라고 생각한다. foreach 등을 통해 데이터를 받아올 경우에 값이 안받아올때 undefined를 반환하게 되기때문에 이것이 TypeError를 일으키게된다. map에 일부 데이터만 없다고 해서 못받아오는 경우는 없어야하기 때문에
let nestedProp = obj.first?.second; //Optional chaining
Optional chaining 위의 함수가 옵셔널체이닝의 기본적인 방식이라고 공식에서 소개하고 있다. 객체에first라는 프로퍼티를 생성하였을때 nestedProp라는 변수에서 obj.first?.second는 결국 temp가 null이나 undefined일 경우 undefined를 반환한다는 뜻이다. 정확하게 변수의 타입을 지정해줘서 TypeError를 회피하는 방식이다.
1 2 3 4 5 6
//현재 에러때문에 옵셔널체이닝 사용한 예시 .then(data => { // fetch 나 axios와 같은 방식으로 데이터를 받아왔을 경우 constArray= data.response?.docs; //((data.response === null || data.response === undefined)? undefined : data.response.docs
위와 같은 fetch 방식으로 보내서 해결해보려고 했지만 서버자체의 접근문제라 문제 해결 방식을 찾는데 시간이 조금 필요할것 같다.
1 2 3
header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
서버별로 해결방식은 여러방식이 있었는데 그 전 직장에서 해결했던 방식은 PHP 서버에서의 해결 방식이었다.Access-Control-Allow-Origin: *을 입력해서 모든 도메인을 허용하는 방법이고 * 대신에 특정 url만 허용할 수도 있다. 밑의 내용은 GET, POST, PUT, DELETE, OPTIONS을 허용한다는 의미이다.
노드 방식의 해결 방식도 있었다.
1 2 3 4 5 6 7 8 9 10 11 12 13
const cors = require('cors'); const domains = ['http://localhost:3000']; //현재 도메인 지정가능
get 또는 post로 데이터를 주고 받는 테스트를 하는 도중 너무 많은 에러가 있어 다시 한번 라이프 사이클을 정리하고 비동기를 어디에서 써야할지 변수 선언은 어디서 할지 한번 더 확인하는 겸 글을 정리해보려고 한다. 특히 hook의 useEffect가 이해가 아직 잘 안되서.. 💀
- 리액트가 웹 상에 렌더링 되기 위해선 render() 메서드가 실행되어야한다 배운바에 의하면 리엑트는 순서가 정의되어있고 그 순서가 맞지 않으면 실행되지 않는다
Mounting 단계
컴포넌트가 시작되면(생성자) 우선 context, defaultProps와 state를 저장하는 단계입니다.
componentWillMount
DOM접근 금지 단계 render하기 전이라서 여러가지 변수 설정이나 변환하기 어려운 단계이다
componentDidMount
DOM에 접근할 수 있습니다. 그래서 여기에서는 주로 AJAX 요청을 하거나, setTimeout, setInterval같은 비동기 처리가 가능해진다.
-
리액트의 컴포넌트는 생성된 후 Mount 상태에서 한 번 render() 메서드를 실행하고, 후에는 Update 상태에 진입해 shouldComponentUpdate의 값이 true일 때만 render() 메서드를 실행한다