개발하는 리트리버

[미리결론] navigator.userAgent.match(/ipad|ipod|iphone/i) 써보기!

앱이 돌고있는 플랫폼을 파악할때 매우 좋은 값이다.

iPhone 인지 Mac 인지 등을 표시해준다.

특히나 앱 프로그래밍에서 iOS 와 Android를 나눌때 매우 유용하다.

하지만 vscode 기준으로 해당 값을 작성하면

위 같이 밑줄이 그어진다

흠.. 근데 아직 값이 잘 나오기는 하던데?

알빠노?

값은 아직까지 잘 나오지만.. 빠르게 바뀌어가는

트렌드에서 언제 무슨일이 벌어질지 모르는법.

deprecated 인 것들을 쓰지 않아야

안정적인 어플리케이션을 개발하는

개발자가 될 수 있지 않을까?

그럼 해당 값은 어찌 대체할 것인가.

navigator.userAgent.match(/ipad|ipod|Mac|iphone/i)

위의 값으로 플랫폼 체크를 할 수 있다. 

userAgent

보통 해당 값은 [Mozilla 버전 + OS + 렌더링 엔진 + 브라우저 이름]  의 형태이다

구글 기본 페이지에서 해당 값을 찾아보면 

이런 값이 나온다. 여기서 돌아오는 값을 가지고 플랫폼을 파악하는 것이다.

해당 값에서 플랫폼값에서 정규식 match() 를 이용하여 원하는 플랫폼인지 체크한다.

딱 값이 나오는 방법은 아니지만.. deprecated 되는 값을 이용하는것 보다는 안정적인 방법이라 생각된다.

개인적으로 아주 만족스러운 platform 값이

왜 deprecated 된 것인지는 좀 아쉽다.

타입가드에는 여러 방법이 있다.

여기선 is를 이용한 타입가드를 가볍게 알아보고자 한다.

결론

아래 처럼 is 사용하기!

		const isTypeA = (item): item is AType => {
			return item.hasOwnProperty('QWER');
		}

나의 경우엔  2가지 타입이 담겨있는 배열에

map 함수를 쓸 때 문제가 발생했다.

map을 통해서 AType일 때, BType일 때 각각의 다른 렌더링을 줬다.

(AAA는 AType에만, BBB는 BType 에만 있는 속성이다.)

하지만?

저렇게 해 두어도

BType에는 AAA가 없다!

does not exist on type....

는 타입에러가 발생했다.

어 그럼 typeof를 쓰면 타입이 나오려나?

하는 말도 안 되는 생각을 순간 했지만

찍혀 나오는 건 'object' 뿐, 너무 멍청하고

이럴 땐

item.AAA? 조건문을 다른 타입을 예측해 주는 함수로 바꿔주면 된다!

아래의 isAAA처럼!

item is AType 

부분은 type predict 하는 역할을 한다.

혹시나 해당 부분만 지운다면.. 

바로 귀신같이 에러가 발생하므로 주의!!!!

다른 타입가드 방식은..

간단한 string, object 에는 위에 언급한 typeof 사용가능하고,

값이 확실한 경우 key 값 비교 시 in으로 단순 비교가능하다.

때문에 사실 위 문제도

이렇게 바꾸어도 타입에러는 사라진다 ^오^

하지만 is는 신박했잖아 한잔해~

그렇다면..

item.AAA 와 AAA in item

의 차이는 뭘까?

훌륭한 GPT 센세의 말을 빌리자면

item.AAA 가 false 일 때의 의미는

값이 존재하지 않을 때도 있지만,

값이 있는데 0이나 false 값인 경우도 있다. -> 타입 에러 발생가능!!!

반면 in 비교는 확실히 해당 값이 존재하지 않는다는 것만

확인해 주기에 타입문제 해결이 가능하다

끝

onChange, onClick 등에 함수를 추가해 줄때,

우린 해당 event 에 대한 타입을 추가해 주어야한다.

귀찮을때는 그냥 any...

TS를 쓰는 멋쟁이들에게 any란 있을 수 없는법

type은 굳이 검색해서 찾을 필요 없다. 

onChange 속성위에 마우스를 올려놓으면

친절하게 알려준다.

하지만 저 값을 그대로 쓰면

'Property 'target' does not exist on type 'ChangeEventHandler<HTMLInputElement>'

target 속성이 없다고 나온다.

왜냐면..

해당 속성은 onChange 함수의 타입이기 때문이다 : )

우리가 원하는건 Handler 의 타입이 아니기에 Handler 를 지워주고

React.ChangeEvent<HTMLInputElement>

로 수정해준다!!

짜잔~

추가로

 많이 사용되는 onClick!!

해당 함수의 event는

React.MouseEvent<HTMLButtonElement>

이다!

은근 생각안나서 찾아보거나 하는데, (저만 그럴지도)

한번씩만 잘 기억해두면 찾아두거나 할필요 없이 스스르륵 써지니

이 기회에 머릿속에 잘 저장해두는것을 추천드립니당 ㅎㅎ

특정 파일을 서버로 업로드하는 개발 중이었다.

알려준 api로 열심히 파일을 보냈지만 돌아오는 대답은

파일 형식이 아닙니다. 인코딩 형식을 확인해 주세요

아오! 얼마나 얄밉던지

어느 블로그에서는 formdata를 만들어서 append 하는 형식으로 보내라!

라고 했지만.. 잘 되지 않았다...

결론부터 말하자면 api의 headers 부분을 수정하는 것이었다...!

기본적으로 input 태그를 사용하여 아래와 같이 파일을 받았다.

			<input type='file' accept='.xlsx' ....>

그리고 api...!!!

보통 다른 api들을 보낼 때

'Content-Type': 'application/json',

으로 설정하고 보낸다. (아마 많이들..?)

Restful API에서 request 요청 시 json을 많이 사용하기에 많이들 사용하는 설정이다.

하지만!!

지금은 파일 전송을 위한 api이지 json을 전송하려는 것이 아니다.

파일 전송 시에는 

'Content-Type': 'multipart/form-data',

으로 해당 값을 바꾸어 주어야 한다..!!

그러고 나니 너무나 스무스하게 200!!

파일을 보낼 때는 Content-Type을 한번 더 확인해 보쟈!

Content-Type 좀 더  살펴보기

형식

 해당 값은 보통 {type}/{subtype}으로 이루어진다. 주분류와 소분류로 생각하면 된다.

예를 들어 데이터가 이미지 일 때,  Content-Type 값의 type은 image, subtype png, jpg 등이 올 수 있다.

그러면 Content-Type : image/png로 설정할 수 있다.

대표적인 값들

외에도 많은 값들이 많이 있는데.. 아직 전 많이 사용해보지는 않았던 것 같아요.

일단 이 정도 있다는 것 체크하고, 나중에 필요시에 확인해 보면 될 것 같습니다~

끝

 프런트 엔드는 다른 파트에서 데이터를 받아 뿌려주는 경우가 많다.

단순 값들이 내려올 때는 너무나 편안하게 값을 표시만 해주면 된다

이때..! 받는 데이터가 단순한 값이 아니라 (ex : '태양', '핸드폰', 0 , 3)

html 값이 내려온다면..? 

 html 태그와 같이 내려주는 경우에 맞추어서 페이지에 작업을 해두어야 한다.

물론 엄청 간단하다! EZ.

안 좋은 예시

const tempHtml = '<div>난 div야<p>난 p야</p></div>';
<div>{tempHtml}</div>

이 코드의 결과는 아찔하다.

우린 div 태그에서 dangerouslySetInnerHTML 속성을 사용할 것이다.

좋은 예시

const tempHtml = '<div>난 div야<p>난 p야</p></div>';
<div dangerouslySetInnerHTML={{ __html: tempHtml }} />

해당 특성 사용 시 바로 원하는(?) 결과를 손에 넣을 수 있다!

그런데... 뭔가 좀 무섭다.. dangerously... 이름이 왜 이러지?

그리고 요즘 쓰는 React 등 에서는 html 값 정도라면.. 바로 html 화면으로 보여줄 수 있을 텐데

왜 단순 텍스트로만 치환해서 보여주는 걸까?

정답은 보안을 위해서 이다.

페이지에서 XSS (Cross-Site-Scripting) 공격을 막기 위해 기본적으로

스트링으로 오는 html 태그값을 그냥 스트링 값으로 보여준다고 한다.

(XSS은 공격자가 스크립트를 웨에 심어서  발생시키는 공격이다!!) 

물론 html 결과값을 보여줘야 할 때가 있다. 

그래서 해당 특성이 생겼고,

잠재적인 위협을 사용자에게 인지시킬 수 있게

'dangerously'라는 어마무시한 워딩을 사용했다고 한다.

html 값을 넣을 때에는.. 한 번씩 단어 선정의 이유를 떠올려보는 건 어떨까?

끝 

vscode로 개발하다 보면 간간히 올라오는 업데이트 팝업,

중요 업무중이라면 'Later'

아니라면 'Install Update'를 진행한다. 

한번 껐다 켜지면서 열리는 영어로 가득한 릴리즈 노트, 

조용히 X 누르고 하던 작업으로 돌아간다.

생각보다 자주 있는 업데이트, 과연 무엇을 이렇게 자주 업데이트 시켜주는가?

뭐 자세히 볼필요는 없겠지만~ 신박한 내용들만 입맛에 맞게 정리해보려 한다

내가 쓰는 IDE와 조금만 친해져 보자!

그럼

VSCode Update 시리즈 시작

[2024 2월 업데이트_version 1.86 ]

요약 (업데이트내용들 중 제 입맛대로 골라 담았습니다)

1. 폴더 Sticky Scroll

2. zoom in/out 윈도우별 작동

3. autosave 설정 강화

4. extension별 notification 설정

5. Custom Bar visibility

6. 파일 변경점 한눈에 보기

7. 말로 코드 짜기

8. 파이썬 conda 환경설정

vscode 릴리즈 노트

https://code.visualstudio.com/updates/v1_86

1. 좌측 폴더 Sticky Scroll

스티키 스크롤 기능을 파일 전체 트리에서 사용할 수 있습니다!

가끔 파일이 많은 폴더에서 어지러웠는데.. 좀 편해지겠는걸요?

세팅에서 아래 부분을 통해 키고 끌 수 있어요

workbench.tree.enableStickyScroll

최대 높이의 40퍼센트만 차지하도록 설정되어 있어요! 

또한 최대 개수를 따로 설정해 둘 수 있습니다

workbench.tree.stickyScrollMaxItemCount

2. Zoom In / Zoom Out / Zoom Reset  윈도우 별로 따로 작동

하단바나, 맥 기준 [command + or -] 단축키로 화면을 확대하고 축소할 수 있는 기능이 있었는데요, 

기존에는 하나의 윈도우에서 동작시키면, 모든 윈도우에서 zoom in, zoom out 등의 기능이 활성화되었어요.

작업하는 윈도우에서만 작동하기를 원했는데... 하시는 분들!

이제는 각각의 창에서 따로 동작한답니다~ 

3. Autosave 기능 강화

autosave는 기존에 있던 기능이나, 조금 더 디테일 해졌어요

세팅을 특정 파일별로, 언어별로, 또는 workspace에 있는 파일만 오토세이브가 가능하게끔 설정할 수 있어요! 

4. Extension 별로 보내는 notification 제한하기

사용하는 extension 별 notification을 끄는 기능이 생겼어요!

5. Custom Title Bar Visibility

[기존] 

[windowed]

최상단바가 사라지는 세팅을 추가할 수 있어요! native bar를 좋아하는 맥유저에게 특히 좋을 거라고 하는군요?!

6. 파일 변경 부분 한눈에 보기(Git)

source control 쪽에 보시면 새로운 아이콘 [파일+] 이 추가되었습니다. 해당 버튼을 누르면 

여러 파일의 변경점들을 한눈에 볼 수 있어요! 마치 깃허브에서 MR 올릴 때 보이는 것처럼 말이죠~

커밋하기 전에 한 번에 보기 편하겠죠? 개인적으로 참 마음에 드는 패치인 것 같아요!!!!!

7. 이젠 말로 코드짜볼까~

새로운 extension이 추가되었습니다! copilot과 연동되어 사용할 수 있다고 하는군요!

8. 파이썬 conda 환경 선택 표시

언제나 함께하지만 잘 몰랐던 IDE, 

오늘 한 발짝 가까워진것 같지 않나요?ㅎㅎ 

-끝-

장고에서 값을 받아 리엑트로 작업 중이었는데

받은 값들 중에 0E-8 발견.

 그냥 0으로 생각하면 된다고 한다.

과연 무슨 값인 걸까??

[결론] : 0E-8는 0에 가까운 값. 

해당 값의 정확한 의미는 0을 10의 -8 거듭제곱 한 의미이다. 

그렇다 우리가 고등학교 수학시간에  배운, 바로 그 e이다. 

(대문자로 되어있어서 그런지, 예상치 못한 곳에서 등장해서 그런지 그 e 일 줄이야)

물론 기억이 나지 않으니 가볍게만 살펴본다면,

무리수 e는 x가 0에 가까워질 때....

(1+x)^(1/x)의 값이 일정값에 가까워지고...

극한의 값을 e, 그때 e는....

e=2.718.....

PASS,, 아래 그림으로 가볍게 아~ 만 하고 넘어가자. 굳이 이 부분을 다시 공부할 필요는 없으니,

그래서? 예를 들어 1.23e3이 있다면

1.23을 10의 3승으로 곱한 것과 같다.

다시 돌아와 0E-8을 이에 대입해 보면

0을 10의 -8으로 곱한 것과 같다.

결과론적으로 0에 매~우 근사한 값을 갖는다고 생각하면 된다.

근데 그럼 그냥 0을 보내주면 되지 왜 저런 이상한 값으로 보내주는 걸까?

그건 디비 같은 곳에서 숫자를 처리하는 방식에 기인한다

데이터 베이스나 다른 데이터 소스에서매우 작은 소수를 표현하기 위해

이러한 표기법을 사용한다. 이 과정에서 해당값이 보내진것이다.

이러한 값들은 주로 금융 데이터나 과학 연구 데이터 등에서 나타날 수 있다.

이를 통해서 매우 작은 값을 효율적으로 저장하고 표시할 수 있게 되는 것이다.

프런트에선.. 뭐라고 보여줘야 할라나.. 

끝

전 이 단어를 면접에서 처음 들어보았어요.. "브라우저 렌더링 순서에 대해서 설명해 보세요"

...? sry...

지금 생각해도 아찔하군요

여러분은 그럴 일 없도록..

자 그럼, 웹 브라우저 렌더링 순서에 대해서 살짝 알아볼까요?

브라우저 렌더링이라 함은 Html, CSS 그리고 JS 등의 파일들을 받아와서 읽고 사용자가 보는 화면을 그리는, 일련의 과정을 의미합니다. 

각각의 순서와 정의를 알아보죠.

순서는 아래와 같아요

Parsing ➙ Style ➙ Layout ➙ Paint ➙ Composite

하나씩 훑어보죠!

Parsing

처음 단계는 파싱단계입니다. 단어 뜻 그대로 파싱 한다는 것으로, 받아온 HTML 파일을 파싱 즉 해석하는 단계예요.

이렇게 파싱을 통해서 DOM(Document Object Tree)를 구성해요. 우리가 돔돔 거리는 바로 그 돔 DOM이에요! 

추가로 CSS가 포함되어 있다면 CSSOM (CSS Object Tree)도 함께 구성하죠!

Style

DOM 트리와 CSSOM 트리를 매칭시켜서 Render Tree를 그리는 과정이에요. 참고로 meta 태그나 display: none과 같은 속성은 사용자에게 보이는 요소가 아니죠? 그렇기에 Render Tree에 포함시키지 않아요!

여기서 visibility : hidden 같은 요소는 Render tree에 포함된다는 사실! 왜? 해당 특성은 보이지는 않지만 특정 장소를 차지하고 있는 요소이기 때문에 Render Tree 포함됩니다!

Layout

Render Tree를 화면에 어떻게 배치해야 할지 노드의 정확한 위치와 크기를 계산하는 단계예요.

사용자가 쓰는 모든 화면이 같지 않기 때문이죠. 웹에서 볼 수도 앱에서 볼 수도 있고, 또 각각의 기기 마다도 화면이 다르니까요!

css에 % 나 vh 같이 상대적인 값으로 설정했다면 이 단계에서 픽셀 단위로 변환해요.

후에 화면 크기의 변화, DOM 추가/삭제 등의 행동에 따라서 Layout 이 다시 발생하기도 하는데 이를 Reflow라고 해요! 후에 알아보죠

Paint

layout 단계를 통해서 계산된 값들을 단어 그대로 실제 픽셀에 그리는 단계예요. 렌더 트리의 요소와 텍스트가

픽셀로 그려집니다. 첫 발생하는 Paint를 FMP(First Meaningful Paint)라고 해요. 

2048 x 1536 해상도 기준으로 iPad는  3,145,000개의 픽셀을 가지고 있어요.

이렇게 무수히 많은 픽셀들을 짧은 시간 안에 채우기 위해서 여러 개의 Layer를 만들어고

각각 픽셀을 합치고 계산하는(composite) 하는 단계를 거치죠. 

❗TMI❗ 성능을 높이는데 주요한 역할을 하지만 메모리를 많이 차지하는 편이기에 남용하면 안 된다고 하는군요!

Composite

앞 단계에서 만든 여러 개의 Layer를 하나로 모으는 단계예요.

이 단계에서 Layer 들을 계획된 순서로 합치면서 최종적으로 사용자가 볼 화면을 보여줘요

여기까지가 1차적인 화면 그리기 순서였어요. 하지만 한 번만 그리고 끝나지 않죠? 사용자의 액션이나 화면크기 변화로 인해서

다시 그려야 할 때면 또다시 순서가 시작돼요.

Reflow

페이지의 크기, 폰트 크기등의 Style 변화에 의해서 일어나요. 크기가 달라짐으로 인해 방금 했던 전체 순서를 다시금 그려야 하죠. 

이를 Reflow라고 해요.  전체 순서를 다시 하는 건 성능 면으로 좋지 않겠죠? 인라인 스타일을 사용하지 않는 것이 Reflow를 줄이는 방법 중 하나라고 하니 참고하세요! (하지만 CSS 파일 따로 만들기 귀찮은걸..).

Repaint

반면 레이아웃에 영향을 미치치 않고, 색의 변경이나 visibility 같은 성격이 변경된 경우 이를 Repaint라고 해요.

아마 이런 것들을 React를 처음 사용하고 배울 때 들어봤을 거예요.

layout, repaint, reflow 발생을 최소화하기 위해서 Virtual DOM을 만들어서 연속적 변경을 한 번에 처리하는 것이죠!

❗TMI❗ [크롬 개발자 도구] -> [성능] -> [렌더링]을 보면 페인트와 레이아웃을 시각적으로 확인할 수 있어요.

해당 부분을 체크하고 화면에서 마우스를 움직이고 해 보면 변화되는 곳에 표시가 된답니다

개발자 도구에 생각보다 다양한 도구들이 들이 많아요.

다음엔 이 부분을  파보아도 좋을 것 같군요.

참고 : https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

[iOS]

react native의 ios 폴더를 Xcode로 열어주고

Xcode ▶ Genral ▶ Identify ▶ Version 값 을 변경해주고 빌드하면 해당 버전으로 빌드 됩니다.

❗TMI❗

App Category

app 카테고리

Display Name

앱 이름을 설정 할 수 있어요

Bundle Identifier

프로젝트 생성시 package 명과 동일

Version

앱 버전값 설정해줍니다.

Version 값에도 일반적인 의미가 있습니다.

첫번째 자리는 메이저한 업데이트,

두번째 자리는 메이저는 아니지만 유의미한 패치일때 올려주고

마지막 세번째 자리는 자잘한 오류나 버그를 수정할때 올려줘요!    

Build

개발에 영향이 있지는 않습니다. 빌드 번호는 개인의 취향껏 값을 주면 돼요

간단하게 1같은 숫자를 줘도 되고 20240201  같이 날짜표기를 넣어줘도 돼요

해당 빌드를 확인하려는 용도인것이죠

물론 자세한건 같이 일하는 팀원끼리 맞추는게 좋겠죠?!

[Android]

{프로젝트폴더}/android/app/build.gradle 에서 versionName 수정을 통해 앱 버전을 변경할 수 있어요

defaultConfig {
     versionCode 123
     versionName "1.0.1"
}

❗TMI❗

versionCode

내부 버전 번호로 사용자에게 보여지지는 않아요!

기존것과 비교해서 최신여부를 판단하는 대에 쓰여요.

이런 판단을 통해 원래 버전보다 낮은 apk를 설치하는 다운그레이드를 막아줘요

versionName

우리가 아는 버전 이름이요! 앱의 버전을 나타내요

개발 앱 버전 변경은 매우 유용하게 사용돼요

특히나 버전별로 앱 기능 제한을 둔 기능 개발/확인 할때 아주 좋죠

+Xcode를 좋아하지 않지만, ios 앱 빌드는 vscode에서 보다는

Xcode 에서 설정하고 빌드하는것이 정신건강에 이로운것 같아요..+

캐시로부터 데이터를 받고, 데이터 fetch 요청을 하고, 최종적으로 최신 데이터를 가져오는 전략

[SWR 정의]

SWR은 State While Revalidate 의 약자로 서버에서 데이터를 가지고올 때 사용되는 리엑트 hook 이에요.

불러온 데이터를 캐싱하여 여러 컴포넌트에서 편하게 사용할 수 있는 장점이 있죠!

useSWR hook은 5가지의 값을 반환해요

• data              :      비동기로 가지고 온 데이터예요
• error             :      데이터 호출 시 에러 유무를 Boolean 값으로 알려줘요. 해당 값으로 화면에서 에러처리 가능해요
• isLoading     :      데이터 호출 상태를 알려줘요. 해당 값을 가지고 화면에서 로딩상태를 관리할 수 있어요
• isValidating  :      요청이나 갱신 로딩의 여부를 표시해요
• mutate          :      값을 업데이트하기 위해 호출하는 함수라고 생각하면 돼요, 호출하고 나서 변경값이 있다면 'data' 값이 바뀌어요 

import useSWR from 'swr'
 
function Profile () {
  const { data, error, isLoading } = useSWR('/api/user/123', fetcher)
 
  if (error) return <div>failed to load</div>
  if (isLoading) return <div>loading...</div>
 
  // 데이터 렌더링
  return <div>hello {data.name}!</div>
}

이 값들을 이용해서 위와 같이 작업할 수 있죠, 위의 예시는 SWR 홈페이지에 나와있는 예시입니다!

useSWR hook은 3가지의 값을 파라미터로 가져요

• key               :      해당 요청을 위한 고유한 값이에요.
• fetcher         :      데이터를 가져오기 위한 함수를 입력받아요.
• options        :      SWR hook 관련된 옵션을 추가할 수 있어요. 해당 글에서는 깊이 다루지 않아요~!

[SWR 이점]

데이터를 호출에 useEffect 나 useState를 사용한다고 해봅시다. 만약 해당 값들을 여러 자식들에게 넘겨줘야 한다면

일일이 다 추가해주어야 합니다. 넘겨주어야 할 페이지들이 많아질수록 더욱 힘들어지겠죠.

function Page () {
  const [user, setUser] = useState(null)
 
  // 데이터 호출
  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data))
  }, [])
 
  // 전역 로딩 상태
  if (!user) return <Spinner/>
 
  // 자식들에게 각각 전달 
  return 
  <div>
    <Navbar user={user} />
    <Content user={user} />
  </div>
}

반면 useSWR을 사용한다면 한 줄로 모든 데이터를 받을 수 있습니다.

// 자식 컴포넌트
const Chile1 = () => {
     const { data, error, isLoading } = useSWR('/api/user/123', fetcher)
     return(
     	{isLoading 
     		? <div>로딩중..</div> 
        	: <div>{data}</div>
      	}
     )
}

const { data, error, isLoading } = useSWR('/api/user/123', fetcher)

한 줄이면 어느 컴포넌트에서도 같은 값을 가지고 화면을 구성할 수 있습니다.

[SWR 커스텀]

useSWR을 이용해서 커스텀해서 사용 할 수도 있어요!

function useExample(id) {
	const { data, mutate, error } = useSWR(id, () => fetchData(id));
	return {
		data: data,
		mutate,
		isLoading: !error && !data,
		isError: error,
	};
}

이렇게 커스텀 하게되면 data의 값, isLoading 이나 error 값을 따로 정의내려서 사용할 수 있어요!

좀더 입맛에 맞춰서 사용할 수 있는 것이죠

SWR 맛보기였습니다.

SWR 사용 시 다른 컴포넌트들에 값을 보내줄 필요없이

편하게 사용할 수 있고, 그런 부분의 작업이 필요없으니

자연스레 작업양도 줄일 수 있게되죠

기회가 되면 좀더 깊이 파보는 것도 재밌을 것 같아요. 

참조한 SWR 공식문서 

https://swr.vercel.app/ko/docs/getting-started