2024년 7월 15일 오후 1:57Workthrough for prev. projectCode SplittingSuspenseReact.lazySuspense 와 함께 사용되는 hooksAsync React RouterReact Conf. 2024 와 근황 이것저것Final Project마치면서…BaaS : BackEnd as a Service Provi

#6-1. Suspense and Next

<img src="https://image.until.blog/steady/article/1727694635128.jpeg" alt="until-1663"><h2>암호화란?</h2><hr>암호화는 데이터를 허가 받지 않은 사용자가 알아보기 어렵게 만들고, 허가 받은 사용자는 알아볼 수 있게 하는 것을 뜻한다.특히 타인이 취득하여 악용할 소지가 있는 데이터들을 주로 암호화 처리해서 보관한다. (ex. 휴대폰 번호, 주민등록번호 등)<blockquote>학습 전에 헷갈렸던 부분: 해시 함수를 이용한 데이터 변환은 복호화가 불가능 하기 때문에 암호화에 속하지 않는다.해쉬 함수를 이용한 보안 기법이라고 부르는 것이 맞다.</blockquote><h2>어떤 방식이 있나?</h2><hr><h3>대칭키 암호화( ex. AES, DES 등 )</h3>: 데이터를 암호화 할때 쓰는 키값과 데이터를 복호화 할때 쓰는 키값이 동일한 암호화 방식<ul><li>하나의 키를 이용해 암복호화가 쉽지만, 키 값을 공유하여 사용할 때 각별한 주의를 기울여야 한다.</li></ul><pre spellcheck="false"><code>"안녕" -(비밀키)-&gt; "62758dda68a287fd310ee918d070fcac" -(비밀키)-&gt; "안녕" </code></pre><h3>비대칭키 암호화( ex. RSA, ECC 등 )</h3>: 데이터를 암호화 할때 쓰는 키와 데이터를 복호화 할때 쓰는 키가 다른 암호화 방식<ul><li>키를 사전에 공유하지 않아도 이용이 가능해 안전하지만, 대칭키 방식에 비해 속도가 느리고 충분한 보안성을 위해서는 긴 길이의 키가 필요해 암복호화 연산이 복잡해 자원을 많이 소모한다.</li></ul><h4>공개키? 개인키?</h4>: 암호화 키를 생성할 때 공개키와 개인키 두 개의 쌍으로 생성을 한다.공개키는 데이터를 암호화 할때, 개인키는 데이터를 복호화 할때 사용한다.<ul><li>모두에게 공개된 공개키 값을 이용해 암호화 된 값을 서버로 보내면 서버에서 개인키로 복호화 하여 데이터를 확인하는 순서다.</li><li>개인키는 공개되지 않고 서버에서만 사용해 공유 중에 유출 될 가능성이 없다.</li></ul><pre spellcheck="false"><code>"안녕" -(공개키)-&gt; "CO//3lsN30ryl8EXFV0Oubq2erPoP4DfedM0zRnLjOiet81uo4gtzKp3H3DpBJkq/lY3547jVK7jArbwO1EA6w==" -(개인키)-&gt; "안녕"</code></pre><h2>그래서 뭘 쓰면 좋을까?</h2><hr>일반적인 상황이라면 보안성이 더 뛰어난 비대칭키 암호화 방식서버의 성능이 좋지 않거나 대량의 데이터를 전송할때는 대칭키 암호화 방식<h2>돌아보며</h2><hr><blockquote>부끄럽지만 나는 "개발할때 무슨 암호화 방식을 사용하셨나요?" 라는 질문에 "Base64 요" 라는 이상한 답변을 한 적이 있다. 답을 들은 면접관은 "그건 암호화 방식이 아닌데요" 라고 답하였고, 나는 그 당시에는 내가 뭘 잘못 말한지 몰랐었다. (물론 시원하게 탈락했다.)암호화 파트를 개발했었지만, 기능이 동작할 정도만 찾아보고 자세한 내용은 모르고 개발을 해왔던 것이다. 누군가 이 글을 읽고 나와 같은 멍청한 실수를 방지했으면 한다.</blockquote>

암호화란?암호화는 데이터를 허가 받지 않은 사용자가 알아보기 어렵게 만들고, 허가 받은 사용자는 알아볼 수 있게 하는 것을 뜻한다.특히 타인이 취득하여 악용할 소지가 있는 데이터들을 주로 암호화 처리해서 보관한다. (ex. 휴대폰 번호, 주민등록번호 등)학습 전에 헷갈렸던 부분: 해시 함수를 이용한 데이터 변환은 복호화가 불가능 하기 때문에 암호화에 속하지

[Security] 암호화에 대한 이해

#6-2. Suspense and Next

Wes Boss 선생이 한 달 쯤 전에 작은 돌 하나를 던졌습니다.State of JS 설문에서 영향력있는 인물로 상위권에서 늘 빠지지 않는 선생님이죠.그가 한 레거시 웹사이트를 소개하는 영상을 유튜브에 올렸습니다...<h2>How is this website so fast?</h2><a target="_blank" rel="noopener noreferrer nofollow" href="https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab_channel=WesBos">https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab_channel=WesBos</a>어느 오래된 .asp 기반의 하드웨어 부품 이커머스 사이트의 말도 안되는 응답속도를 분석하고 소개하는 영상이었는데요.<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.mcmaster.com/">https://www.mcmaster.com/</a>지금도 멀쩡히 운영되고 있는 이커머스 웹사이트입니다.링크를 붙이기가 사이트 운영자에게 조금 죄송한 생각이 들지만, 정말로 말도 안되는 응답속도를 보여주고 있습니다.Wes Boss 선생의 소개가 알려진 다음부터, 어느날 갑자기 개발자들의 성지가 되어버린 곳이랄까요.. 암튼, 커스토머는 아닌 개발자들이 반갑지 않은 트래픽을 발생시키고 있는 곳입니다. (지금은 일부 pre-fetch 기능을 꺼버린 것 같습니다. 개발자들의 의도치 않은 ddos 이펙트? 때문인 것 같아요.)McMaster 의 놀라운 응답속도의 비밀은,Aggressive Pre-RenderingAggressive Pre-Fetch로 Wes Boss 선생은 분석하고 있습니다.mouseOver 이벤트에, 타겟 페이지의 프리렌더링 된 Dom 을 먼저 prefetch 해오는 것이지요.비록 20년 묵은 .asp 기술로 만들어진 레거시 웹이지만, 사용자 경험 UX 측면에서는 지금보다 앞선 접근이라고 소개할 수 있겠습니다..그런데, 이 재미난 떡밥을 그냥 놔둘 개발자들이 아니죠.놀이감을 발견한 몇몇 개발자들이 <a target="_blank" rel="noopener noreferrer nofollow" href="http://McMaster.com">McMaster.com</a> 의 기본 컨셉을 승계한 NextJS 기반의 오픈소스 프로젝트를 만들었습니다.두둥!!..<h2>NextFaster Project</h2>오픈소스 프로젝트 NextFaster<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/ethanniser/NextFaster">https://github.com/ethanniser/NextFaster</a>버슬에 라이브 데모도 올려져 있습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://next-faster.vercel.app/">https://next-faster.vercel.app/</a>엄청난 반응속도에 헛웃음만 나오게 되는데요..ㅋㅋㅋㅋㅋ반응속도가 정말로 웃깁니다.ㅋㅋㅋㅋlighthouse 의 평점은 모든 항목에서 100점이군요.ㅋㅋㅋㅋ.NextFaster 프로젝트에서 UX 를 향상시킨 비밀은 아래 네가지로 소개하고 있습니다.<ul><li>Partial Pre-Rendering</li><li>Aggressive Pre-Fetching</li><li>Aggressive Caching</li><li>Avoid database joins</li></ul>물론, 이 놀라운 반응속도를 제공하기 위해서는 서버 인프라가 더 많은 땀을 흘리는 댓가를 지불해야 하겠죠.그러나, 매우 의미있는, 재미있는 오픈소스 프로젝트인 것 같습니다.React - NextJS 진영의 한 사람으로써, 자부심과 긍지가 느껴지는 경험이었던 것 같습니다.엣헴.

Wes Boss 선생이 한 달 쯤 전에 작은 돌 하나를 던졌습니다.State of JS 설문에서 영향력있는 인물로 상위권에서 늘 빠지지 않는 선생님이죠.그가 한 레거시 웹사이트를 소개하는 영상을 유튜브에 올렸습니다...How is this website so fast?https://www.youtube.com/watch?v=-Ln-8QM8KhQ&amp;ab

NextFast Project

<h1>NextJS 15 ‘use cache’</h1>NextJS 15 에서, fetch 를 이전 버전처럼 사용하면 에러가 발생하는데요..NextJS 15 버전 부터는 fetch 의 캐시 정책을 명시적으로 표현해줘야만 합니다.이 때 <code spellcheck="false">‘use cache’</code> 가 사용됩니다..fetch 모듈에 대해서, 데이터를 캐싱 할 것인가 아닌가에 따라 두가지 구현 방식으로 갈라집니다.<ol><li>fresh data for every request : <code spellcheck="false">&lt;Suspense&gt;</code></li><li>cached data : <code spellcheck="false">'use cache'</code></li></ol>..<h2>Fresh Data for every request</h2>모든 요청에서 fresh data 를 받아와야 할 때는, 해당 컴포넌트를 <code spellcheck="false">Suspense</code> 로 감싸줍니다.<pre spellcheck="false"><code class="language-tsx">// fresh data for EVERY requests..
// 이제 Next 가 자체적으로 캐시를 오버라이드하지 않는다. fetch 는 캐시되지 않는다.
export function Notice() {
 const data = fetch(...)
 return (...data)
}

// 이제는 Suspense 가 없으면 에러를 뱉는다.
export default function Page() {
 return(
 &lt;Suspense fallback={...loading}&gt;
 &lt;Notice /&gt;
 {... some other Data}
 &lt;/Suspense&gt;
 )
}
</code></pre>..<h2>Cached Data</h2>Cache 와 Static Yuji 가 필요할 때, <code spellcheck="false">'use cache'</code> 를 선언주고 <code spellcheck="false">Suspense</code> 를 제거합니다.<pre spellcheck="false"><code class="language-tsx">// Cache 해야 할 때
'use cache'

// 'use cache' 디렉티브에 따라 cache 는 캐싱된다. 
export function Notice() {
 const data = fetch(...)
 return (...)
}

// Notice 컴포넌트가 SSG 가 되는지는 아직 확인하지 못했다. 
export default function Page() {
 return(
 &lt;Notice /&gt;
 (...other Data)
 )
}
</code></pre>SSG 같은 컴포넌트 단위의 Static-Component-Generation 과 'use cache' 의 관계와 차이를 아직 분명히 확인하지 못했습니다.사이트 내에서 100만개의 캐시가 발생할 수도 있기 때문에, 관리를 위해선 Static Component 가 될 것 같지만, 펑션 단위의 ‘use cache’ 도 허용되는 것을 봐선 그렇지 않을 것 같기도 합니다. 때가 되면 저절로 알게 되겠죠...<h2>Cache Handling for Route Segments</h2>Route Segment 들은, use cache 와 Suspense 가 믹스되는 방식으로 중첩구조를 이루게 되는데, 특히 layout.tsx 에서는 use cache - Static 이 유용합니다.<pre spellcheck="false"><code class="language-tsx">// 이제 layout 은 캐싱 되고, children 에 대해 각각의 cache segment 가 할당된다.
// ContextProvider 들과 NavBar, Footer 는 Static 고정되고, 
// Navigation 은 children 내에서만 각각의 Route Segment 정책에 따라 이동하고 캐싱된다.
'use cache'
export default function RootLayout({
 children
}: Readonly&lt;{
 children: React.ReactNode
}&gt;) {
 return (
 &lt;html
 lang="en"
 suppressHydrationWarning={true}&gt;
 &lt;body
 className={inter.className}
 suppressHydrationWarning={true}
 suppressContentEditableWarning={true}&gt;
 &lt;AuthProvider&gt;
 &lt;NavigationGuardContextProvider&gt;
 &lt;ThemeProvider
 defaultTheme="dark"
 storageKey="ganymedian-ui-theme"&gt;
 &lt;RootFrame&gt;
 &lt;NavBar /&gt;
 &lt;MainFrame&gt;{children}&lt;/MainFrame&gt;
 &lt;Footer /&gt;
 &lt;/RootFrame&gt;
 &lt;Toaster /&gt;
 &lt;/ThemeProvider&gt;
 &lt;/NavigationGuardContextProvider&gt;
 &lt;/AuthProvider&gt;
 &lt;/body&gt;
 &lt;/html&gt;
 )
}**
</code></pre>..<h2>Cache Stale &amp; Revalidate</h2>이건 아직 unstable 버전이라고 합니다… Next Conf 에 납품 기일을 못 맞춘 팀이 있었나본데.. 감정이입이 되는군요.<pre spellcheck="false"><code class="language-tsx">// cacheTag : Cache Id 
// cacheLife: Cache Life for Cache Id
import { unstable_cacheTag as cacheTag, unstable-cacheLife as cacheLife } from 'next/cache'

async function getNotice() {
 'use cache'
 const data = fetch(...)

 cacheTag('cache-control-' + data.id)
 cacheLife({
 revalidate: 60,
 expire: 3600,
 stale: 10,
 })

 return ({...data})
}

export default function Page() {
 return(
 &lt;div&gt;
 {await getNotice()}
 (...other Data)
 &lt;/div&gt;
 )
}
</code></pre>..세줄 요약<ol><li>NextJS.15 에서 fetch 가 사용될 때, ‘use cache’ 를 명시적으로 표현해줘야 한다.</li><li>Cache 하지 않을 때 : <code spellcheck="false">&lt;Suspense&gt;</code></li><li>Cache 할 때 : <code spellcheck="false">'use cache'</code></li></ol><code spellcheck="false">'use client'</code> , <code spellcheck="false">'use server'</code> 못지 않게 <code spellcheck="false">'use cache'</code> 도, 중요한 디렉티브 키워드가 되었습니다..-끗-.

NextJS 15 ‘use cache’NextJS 15 에서, fetch 를 이전 버전처럼 사용하면 에러가 발생하는데요..NextJS 15 버전 부터는 fetch 의 캐시 정책을 명시적으로 표현해줘야만 합니다.이 때 ‘use cache’ 가 사용됩니다..fetch 모듈에 대해서, 데이터를 캐싱 할 것인가 아닌가에 따라 두가지 구현 방식으로 갈라집니다.fre

NextJS 15 ‘use cache’

.....이 주제는, Javascript 에 대한 사전 지식을 필요로 합니다......<h2>React 는, Javascript 프레임워크입니다.</h2>고도화 된 프레임웍 은 독립된 랭귀지 수준의 고유의 개발방식과 생태계를 갖게 되기도 하는데, 바로 리액트가 그러합니다.비슷한 시기에 태어난 Angular, Vue 등도 아직 건재합니다만, React 의 입지는 갈수록 탄탄해지고 있는 느낌이죠. 생태계의 규모도 워낙 압도적입니다.왜 React 인가.. 라는 질문은 이제 굳이 할 필요 없을 것 같습니다. 여기에서는, 어떻게 하면 React 를 빠르게 이해햘 수 있는가 라는 문제에 집중해 보려고 합니다...<h2>이 프로젝트는, 리액트 초급 용으로 기획되었습니다.</h2>이 프로젝트의 최종 단계에서 우리는,<ul class="tight" data-tight="true"><li>React-Router with dynamic Routing</li><li>React-Hook-Form and Zod Form Validation</li><li>Zustand 를 이용한 전역상태관리</li><li>Suspense</li></ul>까지 이해하는 것을 목표로 합니다. (NextJS 까지 다루지는 않습니다.) zustand 와 suspense 를 초급단계에서 핸들 되는 주제라고 말하기는 어렵겠지만, 본 프로젝트를 충실히 수행한 이후에는, ‘초급’ 이라는 수식어를 자신있게 떼어낼 수 있겠다는 의미로 받아들이시면 좋겠습니다...<h2>이 프로젝트는, 총 6 개의 연속 아티클로 기획되었습니다.</h2>#1. 리액트를 배우기 위한 사전 준비#2. npm create vite@latest &amp; first hooks#3. more hooks &amp; custom hooks#4. Form handling in React#5. React-Router-Dom#6. Suspense and Next..<h2>전체 목차</h2>,.<h1>#1. 리액트를 배우기 위한 사전 준비</h1><ol class="tight" data-tight="true"><li>JSX 구문</li><li>Imperative &amp; Declarative</li><li>v = f ( s )</li><li>ES5/ ES6 functions and literals</li></ol><h1>#2. npm create vite@latest &amp; first hooks</h1><ol class="tight" data-tight="true"><li>npm create vite@latest</li><li>Hello World React</li><li>basic hooks : useState</li><li>basic hooks : useEffect</li><li>Virtual DOM &amp; StrictMode</li><li>Components &amp; Props</li><li>React Dev-Tools</li><li>first project : your_name</li></ol><h1>#3. more hooks &amp; custom hooks</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>useRef</li><li>useMemo, useCallback, useId</li><li>useReducer</li><li>useContext</li><li>zustand</li><li>Custom Hook #1. useLocalStorage</li><li>Custom Hook #2. useAxiosFetch</li><li>second project : not yet fixed</li></ol><h1>#4. Form handling in React</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Form Basics : Controlled Input &amp; UnControlled Input</li><li>React-Hook-Form</li><li>Zod + Resolver</li><li>fourth project : React-Hook-Form Project</li></ol><h1>#5. React-Router-Dom</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Routing in React</li><li>React-Router-Dom Basic</li><li>Nested Route</li><li>Dynamic Route</li><li>Error Handling and Fallback</li><li>Action handling</li><li>fifth project : not yet fixed</li></ol><h1>#6. Suspense and Next</h1><ol class="tight" data-tight="true"><li>Workthrough for prev. project</li><li>Portals</li><li>Suspense</li><li>Lazy</li><li>Async React Router</li><li>final project : not yet fixed</li></ol>

.....이 주제는, Javascript 에 대한 사전 지식을 필요로 합니다......React 는, Javascript 프레임워크입니다.고도화 된 프레임웍 은 독립된 랭귀지 수준의 고유의 개발방식과 생태계를 갖게 되기도 하는데, 바로 리액트가 그러합니다.비슷한 시기에 태어난 Angular, Vue 등도 아직 건재합니다만, React 의 입지는 갈수록 탄탄

React 를 배워봅시다. #0

React 에서 전역 상태관리…React 생태계에서 전역 상태관리는 3rd 파티 라이브러리를 통해 구현하는 게 일반적입니다.React 에서 상태관리 라이브러리로는 Redux, Recoil, Zustand 등이 널리 사용되고 있는데, 이 중 Zustand 의 보급과 사용이 확산되고 있는 추세인 것 같습니다. (npm 다운로드 Zustand 3.4m/w 으로,

React Project : zustand-and-useContext

State of CSS 2024 설문이 시작되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://survey.devographics.com/en-US/survey/state-of-css/2024">https://survey.devographics.com/en-US/survey/state-of-css/2024</a>설문은 11개 페이지에 총 소요 시간 약 20분~25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하다보면,<img src="https://image.until.blog/ganymedian/article/1724427177172" alt="until-1266">설문항목 박스 우상단에 “+” 아이콘이 있습니다.자세히 알아보고 싶거나 흥미로운 항목일 때, 우상단 아이콘을 클릭하면 해당 기술항목이 차곡차곡 보관되고, 설문 종료시에 이를 모두 모아서 이메일로 받아볼 수 있습니다.이메일에는 모질라 재단의 공식문서 링크가 각각 포함되어 있습니다. 공부해야 할 기술 항목들을 이메일에서 하나씩 클릭해서 학습할 수 있겠죠...설문 결과 발표는 매우 늦습니다. 아예 궁금해 하지 않는 쪽이 정신건강에 이롭습니다.State of […] 설문조사에서는, 매년 일본인 개발자들은 눈에 뜨이지만 한국인 개발자의 참여는 목록에 보여지지도 않고 있는데, 이 점이 기분 안좋아요. 우리도 활발하게 참여해서 내년 부터는 Korean 이 리스트에 보여지면 좋겠다는 생각을 해봅니다...그리고, 설문 종료시에 무슨 의미인지는 잘 모르겠습니다만, 스코어가 뜹니다. 똬~악!!<img src="https://image.until.blog/ganymedian/article/1724427218896" alt="until-1267">상위 74% 라면.. 하위 27% 라는 거죠?? ㅋㅋㅋㅋ 기분 꿀꿀해지는군요.

State of CSS 2024 설문이 시작되었습니다.https://survey.devographics.com/en-US/survey/state-of-css/2024설문은 11개 페이지에 총 소요 시간 약 20분25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하

State of CSS 2024 Survey

<a target="_blank" rel="noopener noreferrer nofollow" href="https://2023.stateofjs.com/">https://2023.stateofjs.com/</a> State of JS 2023 Survey&nbsp;발표가 나왔습니다.State of JS/ CSS 는,매년 전 세계의 개발자들에게 직접 설문 조사를 받아서 이를 취합, 발표하는 공신력 있는 조사에요.1년 단위 조사이고 발표는 이듬해 봄, 여름에 하는데...&nbsp;발표가 좀 늦는게 단점이지만, 개발 쪽 트랜드는 가장 뚜렷하게 볼 수 있는 조사입니다.이번 발표는 그제? 쯤 나온 것 같습니다.이번 발표에서는 Vite 와 Bun 이 가장 많은 항목들에서 높은 스코어를 받았군요 .그런데, 제게 는 Jest 가 가장 눈에 뜨였네요.생각보다 많은 사람들이 테스트 코드를 쓰고 있다는 사실에 놀랐고,,&nbsp;음.. 분발해야겠다는 생각이 들었습니다.Vercel 의 약진도 눈에 뜨입니다. 음...&nbsp;그리고 올해 처음 추가된 설문항목 인 것 같은데... AI assistant 항목도 흥미롭습니다.AI 는 1개월 단위로 판도가 바뀌는데 1년만의 발표라니, 좀 박물관 기록같은 느낌도 있네요.ㅎㅎ시간 될 때 한번 들러 보시는 것도 좋겠습니다.관심 있으신 분들에겐 재밌는 시간이 될 것 같네요 .-Fin-

https://2023.stateofjs.com/State of JS 2023 Survey&nbsp;발표가 나왔습니다.State of JS/ CSS 는,매년 전 세계의 개발자들에게 직접 설문 조사를 받아서 이를 취합, 발표하는 공신력 있는 조사에요.1년 단위 조사이고 발표는 이듬해 봄, 여름에 하는데...&nbsp;발표가 좀 늦는게 단점이지만, 개발 쪽 트

State of JS 2023 Survey

State of React 2023 Survey 결과가 발표되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://2023.stateofreact.com/en-US/">https://2023.stateofreact.com/en-US/</a>지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를 기다리는 건, 기술동향에 대한 궁금함도 있겠지만,"어떤" 기술을 사용할 것인지를 결정하는데 중요한 자료가 된다는 것이죠.러닝커브가 도사리고 있는 기술인데, 애써 배워놨더니 쓸모 없어지는 경험은 누구에게나 악몽이 될 수 있으니까요..그런 의미에서, 제 채널에서 진행하고 있는 강좌에서 선택한 기술들이 대체로 높은 스코어를 받고 있다는 건 흡족한 일이네요.개인적으로는 Zustand 가 급상승하기를 기대했지만 이번 결과에서는 그렇지 못했습니다. Zustand 가 관심을 받기 시작한 건 얼마 안됐으니까요.. 그리고 이 조사 발표는 정말 늦습니다.그리고 ' 가장 고통스러웠던 API' 설문에서는 forwardRef 와 memo 가 나란히 선두에 뽑혔군요.React 19 에서는 forwardRef 가 없어질 것이라는 이야기도 돌았죠. 컴파일러가 도입되면 memo 도 설 자리를 잃게 될 테고... 이제 HOC 는 서서히 소멸되어가는 기술이 될 것 같습니다.관심있는 분들에게는 매우 의미있는 시간이 될 것입니다.

State of React 2023 Survey 결과가 발표되었습니다.https://2023.stateofreact.com/en-US/지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를

State of React 2023 Survey 결과 발표

State of React 2024 설문이 시작되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://survey.devographics.com/en-US/survey/state-of-react/2024">https://survey.devographics.com/en-US/survey/state-of-react/2024</a><a data-type="bookmark" href="https://survey.devographics.com/en-US/survey/state-of-react/2024" target="_blank"><div class="content"><div><div class="title">State of React 2024</div><div class="description">Take the State of React survey</div></div><div class="href">https://survey.devographics.com/en-US/survey/state-of-react/2024</div></div><img src="https://assets.devographics.com/surveys/react2024-og.png"></a>NextJS 15 가 이미 발표되었고, React 19 는 사실상 모두에게 강매? 된 셈이 되었어요.React 생태계가 어느해 못지 않게 급변하고 있는 한 해인 것 같습니다.설문 박스 우상단의 "+" 아이콘을 클릭하면, 해당 항목에 관한 레퍼런스들을 차곡차곡 모아서 이메일로 받아볼 수 있습니다. 관심있는 항목들을 모아서 나중에 공부할 수 있겠죠.시간 되시면 한번 참여해보시는 것도 의미있을 것 같습니다.

State of React 2024 설문이 시작되었습니다.https://survey.devographics.com/en-US/survey/state-of-react/2024State of React 2024Take the State of React surveyhttps://survey.devographics.com/en-US/survey/state-of-r

State of React 2024 Survey

DevTools

프로그래밍언어

<code spellcheck="false">JDK21</code>이 등장했다! 그렇다면, 먼저 JDK 21에서 어떤 기능이 추가되었는지 알아보는 것이 개발자된 도리가 아닌가!일단, 다음 <a target="_blank" rel="noopener noreferrer nofollow" href="https://spring.io/blog/2023/09/20/hello-java-21">Hello, Java 21</a>에 들어가보자. JDK 17부터 쭉 스토리를 이어가보자.<h1>JDK 17</h1><h2>Multiline Lines</h2>파이썬 주석을 쓰는 방식처럼 Java 17에서는 <code spellcheck="false">""" .... """</code> 을 이용하여 다중줄을 지원한다. JSON, JDBC, JPA QL, etc., 을 더 쉽게 표현할 수 있을 것이다.<pre spellcheck="false"><code class="language-java">package bootiful.java21;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

class MultilineStringTest {

 @Test
 void multiline() throws Exception {

 var shakespeare = """

 To be, or not to be, that is the question:
 Whether 'tis nobler in the mind to suffer
 The slings and arrows of outrageous fortune,
 Or to take arms against a sea of troubles
 And by opposing end them. To die—to sleep,
 No more; and by a sleep to say we end
 The heart-ache and the thousand natural shocks
 That flesh is heir to: 'tis a consummation
 Devoutly to be wish'd. To die, to sleep;
 To sleep, perchance to dream—ay, there's the rub:
 For in that sleep of death what dreams may come,
 """;
 Assertions.assertNotEquals(shakespeare.charAt(0), 'T');

 shakespeare = shakespeare.stripLeading();
 Assertions.assertEquals(shakespeare.charAt(0), 'T');
 }

}</code></pre><h2>Record</h2>프로젝트를 수행할 때, 필자는 이 녀석을 굉장히 좋아한다. 이 녀석은 <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.oracle.com/en/java/javase/17/language/records.html">오라클 문서</a>에 잘 나와있다. <code spellcheck="false">Record</code>는 외부 라이브러리인 Lombok의 의존성을 줄이고, 간결하고 가독성 높은 데이터 클래스를 작성할 수 있게 한다.<ol><li>명시적인 필드 선언, 생성자, getter, setter 등을 대체</li><li>기본적으로 불변객체로 생성해 데이터의 안정성과 무결성을 보장 (암묵적으로 final)</li><li>toString, equals, hansCode 메서드가 자동으로 생성</li><li>static 메소드, static 필드 선언 가능 (클래스 기능과 동일)</li><li>중첩 클래스 사용 가능 및 제너릭 타입으로 지정 가능 (클래스 기능과 동일)</li></ol><code spellcheck="false">record(헤더) {바디}</code> 형태로 이루어져있는데, 헤더에 나열된 필드는 private final로 정의된다.<pre spellcheck="false"><code class="language-java">package bootiful.java21;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

class RecordTest {

 record JdkReleasedEvent(String name) { }

 @Test
 void records() throws Exception {
 var event = new JdkReleasedEvent("Java21");
 Assertions.assertEquals( event.name() , "Java21");
 System.out.println(event);

 }
}</code></pre>Record 클래스는 어디서 사용할 수 있을까? DTO에서 Record 클래스를 자주 사용한다.<pre spellcheck="false"><code class="language-java">@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class MemberResponse {
	private Long memberId;
	private String name;
	private Role role;
	private Building building;

	@Builder
	public MemberResponse(Long memberId, String name, Role role, Building building) {
		this.memberId = memberId;
		this.name = name;
		this.role = role;
		this.building = building;
	}
}</code></pre>Record도 특수한 종류의 클래스이므로 <code spellcheck="false">new</code>키워드를 사용하여 레코드 객체(레코드 클래스의 인스턴스)를 생성한다.<pre spellcheck="false"><code class="language-java">public record MemberResponse(Long memberId, String name, Role role, Building building) {
 public static MemberResponse fromRequest(Request request) {
 return new MemberResponse(request.getMemberId, request.getName, request.getRole, request.getBuilding);
 }
}

// 사용
public MemberResponse createMember(MemberRequest reqeust) {
 ...
 return MemberResponse.fromRequest(request);
}</code></pre><blockquote>💡 <a target="_blank" rel="noopener noreferrer nofollow" href="https://medium.com/javarevisited/deciphering-jpas-hibernate-s-limitations-the-reasoning-behind-java-records-not-being-supported-56a57d3ff9ca">Entity가 Record 클래스가 될 수 없는 이유</a> Record는 불변객체이며, 매개변수가 없는 생성자를 제공하지 않으며, Record의 필드 또한 private final로 설정되어있다. 그러나 JPA를 사용하는 1) 엔티티 클래스에는 쿼리 결과를 매핑할 때, 객체를 인스턴스화할 수 있도록 public 또는 protected인 매개변수가 없는 생성자가 있어야한다. 또한, 2) 프록시를 생성할 수 있도록 클래스는 final이면 안된다. 3) 필드도 setter가 있어야하기 때문에 final이면 안된다. Hibernate를 사용하면, final 클래스를 유지할 수 있고, 매핑된 엔티티 속성에 대한 접근자 메서드가 필요하지않지만, 프록시를 생성하기 위해 여전히 기본 생성자와 final이 아닌 필드가 필요하다.</blockquote><h2>Switch Statement</h2>잘 쓰고싶지않던 Switch문이 바뀌었다!가장 눈에 띄는 것은 <code spellcheck="false">case label1, label2 .. -&gt;</code> 와 같은 형태로 바뀌었다는 것인데, 1. 여러개의 label를 동시에 작성 가능, 2. 번거로운 break문이 없어짐을 확인할 수 있다.switch문은 이제 표현식이기 때문에 switch문의 결과를 변수에 할당하거나 반환 값으로 줄 수 있게 변경되었다는 점도 중요하다!<pre spellcheck="false"><code class="language-java">package bootiful.java21;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import java.time.DayOfWeek;

class EnhancedSwitchTest {

 // 기존 
 int calculateTimeOffClassic(DayOfWeek dayOfWeek) {
 var timeoff = 0;
 switch (dayOfWeek) {
 case MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY:
 timeoff = 16;
 break;
 case SATURDAY, SUNDAY:
 timeoff = 24;
 break;
 }
 return timeoff;
 }

 // 변경
 int calculateTimeOff(DayOfWeek dayOfWeek) {
 return switch (dayOfWeek) {
 case MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY -&gt; 16;
 case SATURDAY, SUNDAY -&gt; 24;
 };
 }

 @Test
 void timeoff() {
 Assertions.assertEquals(calculateTimeOffClassic(DayOfWeek.SATURDAY), calculateTimeOff (DayOfWeek.SATURDAY));
 Assertions.assertEquals(calculateTimeOff(DayOfWeek.FRIDAY), 16);
 Assertions.assertEquals(calculateTimeOff(DayOfWeek.FRIDAY), 16);
 }
}</code></pre>반환값이 있기 때문에 아래 코드같이 작성도 가능하고, 출력문에도 쓸 수 있다.<pre spellcheck="false"><code class="language-java">static int coverage(Object o) {
 return switch (o) {
 case String s -&gt; s.length();
 case Integer i -&gt; i;
 default -&gt; 0;
 };
}</code></pre><h2>InstanceOf Check &amp; Sealed Types</h2>Sealed Class, Interface는 간단하게 상속하거나(extends), 구현(implements)할 클래스를 지정해두고 해당 클래스들만 상속 혹은 구현을 허용하는 키워드이다. 이것의 목표는 어떤 Super Class의 Sub Class들을 명확히 인지할 수 있어야 한다는 것이다! 몇가지 제약사항이 존재한다.<ul><li>모든 하위 클래스를 알아야함</li><li>하위클래스는 sealed된 클래스를 직접 상속받아야함 (중간에 다른 클래스가 끼어들면 안됨)</li><li>세 가지 종류의 하위 클래스 규칙<ul><li><code spellcheck="false">final</code>: 더 이상 다른 클래스가 이 클래스를 상속받을 수 없다. 즉, 이 클래스가 상속의 끝이다.</li><li><code spellcheck="false">sealed</code>: 다시 봉인된 상태로, 특정한 클래스들만 이 클래스를 상속받을 수 있다.</li><li><code spellcheck="false">non-sealed</code>: 제한 없이 어떤 클래스든 이 클래스를 상속받을 수 있다. 봉인된 클래스가 하위 클래스를 제한해도, <code spellcheck="false">non-sealed</code>로 선언되면 그 제한을 풀어버릴 수 있다.</li></ul></li><li>같은 모듈이나 패키지 안에 있어야함</li></ul><pre spellcheck="false"><code class="language-java">package bootiful.java21;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

class SealedTypesTest {

 // ①
 sealed interface Animal permits Bird, Cat, Dog {
 }

 // ②
 final class Cat implements Animal {
 String meow() {
 return "meow";
 }
 }

 final class Dog implements Animal {
 String bark() {
 return "woof";
 }
 }

 final class Bird implements Animal {
 String chirp() {
 return "chirp";
 }
 }

 @Test
 void doLittleTest() {
 Assertions.assertEquals(communicate(new Dog()), "woof");
 Assertions.assertEquals(communicate(new Cat()), "meow");
 }

 // ③
 String classicCommunicate(Animal animal) {
 var message = (String) null;
 if (animal instanceof Dog dog) {
 message = dog.bark();
 }
 if (animal instanceof Cat cat) {
 message = cat.meow();
 }
 if (animal instanceof Bird bird) {
 message = bird.chirp();
 }
 return message;
 }

 // ④
 String communicate(Animal animal) {
 return switch (animal) {
 case Cat cat -&gt; cat.meow();
 case Dog dog -&gt; dog.bark();
 case Bird bird -&gt; bird.chirp();
 };
 }

}</code></pre>