낙관적 UI(Optimistic UI)
요청 보내고 기다리지 않는다. 어차피 성공할걸 알아...!!
이런 경우에 쓴다.
1. 99% 성공할 것이 예상되는 API
2. 1%확률로 실패하더라도, 문제가 안되는 API
개발을 할 땐... 좋은 컴퓨터만 있지 않다는 걸 생각해야한다!
느린 컴퓨터에서 좋아요 버튼만 누른다면? 좋아요 버튼 하트 채워졌다가 나중에 보니 안 눌려있어도 치명적인 오류는 아니잖아 + 일단 누르면 하트 채워지게 보여지게 해! 그런 것...
성공했다고 가정하고 미리 데이터를 주자.
- likeBoard 요청이 날아감
- 가짜 likeBoard를 데이터에 넘겨서 data.likeBoard 캐시 스테이트를 먼저 수정한다.
- 화면에 보여진다.
- DB에서 결과를 받아서 가지고 온다.
- 그 결과를 다시 update의 data에 넣어준다.
- data.likeBoard에 들어가서 캐시 스테이트가 수정된다. (값이 동일하면 안바뀌도록 설계 되어있다.)
slow3g에서도 빠르다! (빠르다기보단 속인거지만)
modify는 있던 걸 수정하는 것, writeQuery는 없던 것도 추가할 수 있는 것
스크래핑, 크롤링, opengraph(og)
이런 미리보기를 그린 건 디스코드 프론트엔드 개발자, 내용 아이콘, 이미지들은 네이버 개발자들이 정해놓은 것.
주소 받으면 그 주소에 요청해서 html 소스 코드를 가져온다. (스크래핑 - 긁는다)
meta로 시작한 거, og가 들어간 것, 뽑아내서 각각 변수에 담고 그 내용들을 디스코드 채팅창에 보여준다.
페이스북이 먼저 시작했대! 대단하다...
프론트엔드에서 /login 이런 주소들이 있어
페이지가 주소가 된다. 그게 api 주소 (각 페이지가 api 주소로서 나타난다.)
페이지들은 rest-api에서 get방식
HTTP / text 또는 HyperText(HTML) 하이퍼 텍스트 마크업 랭귀지 . (마크업 <>)
객체처럼 생긴 문자열
postman chrome에서 - get으로 네이버 주소 보내면 HTML 코드 받을 수 있다.
그걸 그림으로 그려주는 역할 하는게 브라우저의 역할이다.
터미널에서 curl https://www.naver.com
치면 이런 결과가 나온다.
근데 여기서 데이터를 어떻게 뽑아? 이걸 도와주는 라이브러리
XML 확장가능한 마크업 랭귀지( 원래 name 이란 태그 없는데 <name> 이렇게 쓰고…)
원랜 json이 아니라 xml로 데이터를 주고 받았어. 비효율적이어서 지금은 json 주고 받는 것
어쨌든 html 주고 받을 수 있다는 것.
JSX ⇒ JavaScriptXML(HTML이랑 똑같이 생겼는데 사실 HTML 아님)
서버사이드렌더링(SSR)
안 했을 때 생기는 문제 !
postman, axios, curl이 쿼리를 실행해주진 않는다. 단지 응답 오는 건 코드!
브라우저가 실행하고 유즈쿼리를 작동해서 받아와야 하는 애. ex) data.fetchBoard.title 이런 것 받아올 수 없다.
그럼 어떻게 해야 브라우저에서 curl, postman, axios로 요청했을 때 meta 태그에 useQuery까지 담아서 가져올 수 있는가?
요청을 하면, 일단 주고 useQuery를 보내는 게 아니라, useQuery를 프론트엔드에서 받아와서 그걸 최종적으로 보내주는거야. 그럼 브라우저에서 useQuery할 필요 없고 내용이 안에 다 들어가있다. 한 방에 해야 스크래핑이 가능해서 미리보기가 가능하다.
이 방식을 서버사이드렌더링이라고 한다.
서버사이드렌더링을 이것때문에만 하는 건 아니다.
굉장히 많은데, 가장 명확하게 이해할 수 있는 부분이 이 부분.
첫 페이지 로딩 속도가 빠르고 검색엔진 최적화 되고 등등… 여러이유가 있다.
네이버, 구글 같은 애들은 사이트들을 크롤링하고 다닌다. 검색 크롤링 봇이 있음(for문 돌려놓은 프로그램)
사이트에 접속해서 이건 날개, 호빵 관련 페이지네? 저장해놓고… 그러는데
문제는 서버사이드렌더링 안 된 페이지 경우 구글봇이 크롤링 하러 와서 데이터 가져가면 useQuery부분은 텅텅 빈 상태, 정적인 데이터만 갖고 가는 것. (핵심 내용은 다 빠져있다.) 이 페이지가 뭐에 관련된 페이지인지 알 수 없다.
Search Engine Optimization(SEO)
전달사항
팀 프로젝트 관련 결정 사안
- 디자이너 별도 배정 안 함(지난 기수에서 이슈가 많았다. 디자이너분들 강제성 부여할 수 없고, 그냥 가시는 분들이 많았다.) 캠프측에서 디자이너 모집해서 배정하진 않는다. 팀 단위로 디자이너 구하든 말든 그건 자유(…?) 모집한 디자이너에게 출입카드까지는 제공할 수 있다.
- 프로필 사진 이벤트가 지난기수까지 있었다. 수강 비용에 포함되는 부분은 아닌데 취업에 도움이 된다라고 파악돼서 서비스차원에서 제공해주는 이벤트였는데, 컴플레인 같은 게 많이 들어와서. 시간 할애를 해야되는거라서… 부정적인 피드백이 많아서 이번 기수에서는 진행하지 않고, 팀별 간식 지원할듯… 차후 구체적인 거 정한 후 말하겠음
- 이번주 금요일부터 주말까지 final check가 예정되어 있습니다.
- 팀프로젝트 시 학생 디자이너가 배정되지 않습니다.
- 이전 두 기수동안 디자이너 협업을 시범 도입해보았으나, 팀 내 마찰이나 이견으로 인한 중도 포기 등 장점보다 단점이 많은 것으로 분석되었습니다.
- 팀 단위로 직접 구인하여 참여하는 것은 가능합니다.(단, 모집 비용 등에 대해서는 지원하지 않습니다.)
- 팀 편성은 7월 1일에 공지됩니다
- 프로필사진 이벤트는 미진행됩니다
- 프로필 사진 촬영은 취업이 잘 될 수 있도록 서비스 차원에서 진행됐던 이벤트이나, 팀프로젝트 진행 시 오히려 시간을 별도로 할애해야 하는 문제로 인해 부정적인 피드백이 많아 이벤트가 종료되었습니다.
- 팀프로젝트에 도움이 될 수 있도록 팀 단위로 간식을 제공하는 이벤트로 변경되어 진행됩니다.
오늘은 Optimistic-UI와 SSR에 대해 알아봤습니다! Optimistic-UI는 실제로 성능을 높여주는 것이 아닌, 성능이 높아 빠른 처리를 하는 것 같이 보이도록 눈속임 하는 것이였습니다! Optimistic-UI는 이름처럼 낙관적 UI라 했죠? 특정 API요청을 보내기 전 요청 결과가 실패하지 않을것이라 가정하고 화면을 요청 성공이 된 것처럼 그려준 후 API요청을 보내준뒤, 결과가 돌아 온 후 다시 화면을 그려주는것이라 했습니다! 즉, 비교적 느린 refetchQueries가 아닌 optimisticResponse를 사용해 미리 보여줄 데이터 값을 가지고 update()를 통해, cache state를 직접 수정했고, 요청이 완료되기 전 화면을 처리해줘 빠르게 눈속임 해주었습니다! 우리는 이를 좀 더 쉽게 이해하기 위해 ‘좋아요’ 기능을 예시로 진행 했습니다!(느린 케이스 확인을 위해 network탭의 fast 3G를 사용해봤죠!?) Optimistic-UI를 모든 곳에 사용하면 안되겠죠? 결제와 같이 안정성이 필요한 중요한 부분에는 사용하지 않아야 했습니다! SSR(ServerSideRendering)도 알아봤죠! SSR을 알아보면서 OG(OpenGraph)를 먼저 이해했죠! OG란 html의 메타 태그 중 하나였습니다! 특정 링크가 있을때 우리는 그 링크 만으로 해당 사이트가 어떤 사이트인지 알 수 없었죠! 그때 태그로써 미리보기 이미지나 사이트의 설명, 제목을 보여주는 역할을 한다 했습니다. 즉, html 문서의 메타정보를 더 알아보기 쉽도록 표시하기 위해 사용되는 것입니다. 이를 위해 우리는 html의 head가 아닌 Next.js의 Head를 import시켜 헤드 태그를 만들어주었습니다! Head안에는 meta태그를 통해 property와 content를 지정해주었습니다! 이렇게 해주면 카카오,디스코드,슬랙 등 해당 플랫폼의 개발자분들이 미리보기를 구현시켜놓았기때문에 OG태그를 읽고 미리보기를 만들어 줄 수 있었습니다 실습에서는 모두 하드코딩을 통해 진행했었죠? 하지만 상품상세 페이지라면 어땠나요? 품목마다 Head태그를 여러개 입력할 수 없었죠? meta의 content를 useQuery()를 통해 받아온 data의 값들로 채워주면 문제가 생겼죠! data요청이 가기 전 frontend-server에서 화면을 그려주기에 meta의 내용이 비어있게 되어 data를 받아올때까지 기다려야 한다는 점이였습니다! 이를 SSR은 해결할수있었죠! 사이트에 대한 접근이 요청 되었을경우 SSR이 된 페이지라면 frontend-server에서 Browser를 거치지 않고 바로 Backend로 요청이 보내져 meta에 data들이 들어간 상태로 스크래핑이 가능했습니다! SSR을 사용하는 가장 큰 이유는 SEO(SearchEngineOptimization/검색엔진최적화)라고 했습니다! 사전에 크롤러가 어떤건지 알아봤죠! 이를 시행하는 검색봇이 여러 검색엔진사이트에 존재합니다. 이 검색봇은 24시간 여러 사이트를 돌아다니며, 해당 사이트에 대한 정보를 읽어 해당 사이트가 어떤 사이트인지 판단하게 된다했습니다! 하지만 사이트 안 내용이 있어야 특정 키워드들에 점수를 올려주게 되는데, 이 검색봇은 사이트에 들어와 내용을 다 받아올때까지 기다려주지 않았죠! 그렇기 때문에 SSR로 처리를 하여 페이지에 대한 내용을 읽어 사이트 키워드 점수를 올릴 수 있게 해주는 것이 중요 포인트였습니다!
script.src =
"//dapi.kakao.com/v2/maps/sdk.js?appkey=@@@&autoload=false&libraries=services";
카카오맵
다른 api 사용할 때 libraries=services 를 붙여줘야한다!
내일부터 슬리퍼가 필요했는데 딱 맞춰와준 내 슬리퍼♡♡♡♡♡진짜 너무 가볍구 귀엽당...
비가 많이 왔다!
근데 요즘은 하도 비가 많이 왔어서 이날 뭐했는지 잘 기억이 안 나네.
창가 옆자리는 좋다,,, 하지만 내 자리는 아니지.
이 날 집에 고기 사가지고 가려고 다른 정류장에 내렸다가 우연히 갱쥐 만나서 좋았다. 인지기능장애약이 드디어 나와서! (짱 신기하게 생김 필름같아) 인지기능장애약도 받아왔다. 한 달에 삼만원~사만원 정도. 난 동물병원 때문에라도 여길 벗어나질 못할 것 같아. 너무 좋은 분이라,,,, , ,,,다른 곳엔 못 갈 것 같다.
오늘 배운 건 사실 나에겐 흥미로운 내용은 아니였다,,, 조금 어렵고 기억에 잘 안 남는다. 어렵다 어려워
'프론트엔드✏️ > 코드캠프' 카테고리의 다른 글
알고리즘 - [1차] 비밀지도 (0) | 2022.06.27 |
---|---|
220624 프론트엔드 부트캠프 45일차 🌺기말고사🌺 파이팅🫶 (0) | 2022.06.24 |
[문제...] react-hook-form, 엔터치면 뮤테이션이 날아감 (0) | 2022.06.23 |
[문제 해결] Warning: Failed prop type: The prop `children` is marked as required in `InfiniteScroll`, but its value is `undefined`. (2) | 2022.06.23 |
[문제 해결] toast-ui 디폴트 밸류, 수정할 때 빈값 들어가는 문제, 랜딩 페이지 엔터쳐서 넘어가기 (0) | 2022.06.23 |