프로그래밍은 사회 활동이다.

📚 읽은 범위

📝 기억하고 싶은 내용

• 이름에는 의도가 분명해야한다.
• 그릇된 정보를 피하라
• 발음하기 쉬운 이름을 사용해라
• 검색하기 쉬운 이름을 사용해라
• 개발에 관련된 이름을 사용해라, 없다면 도메인 관련 용어를 사용해라
• 맥락을 주의하라

💡 읽은 소감

프로그래머가 가장 힘들어 하는일이 무엇일까?

그렇다. 네이밍이다. 그만큼 프로그래밍에서 네이밍이 얼마나 중요한 부분을 차지하는지 짐작할 수 있다.

글에서도 밝히듯이 프로그래밍은 사회 활동이다. 대부분의 개발자는 혼자 코딩하지 않고, 협업한다. 자신만이 알 수 있고 읽기 편한 코드는 일의 효율을 해치고 협업에 도움이 되지 않는다.

토스 | SLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code

네이밍으로 한글을 거부하는 개발자도 많다. 하지만 컴파일 상에 문제가 없다면, 복잡한 영어 네이밍을 구상하는 것보다 한글 네이밍이 더욱 직관적이고 사용하기 쉽다는 것을 알 수 있다.

또한, 한글을 외국어로 표현했을 때, 읽기 힘들거나 어색한 표현이 있다. 예를 들어 부동산 앱에서 전세 임차 보증금을 변수로 저장한다면 영어 표현은 한글로 작성한 표현 보다 가독성이 떨어진다.

const 전세임차보증금 = money;

const depositForLease = money; // GPT

현대의 라이브러리들은 명명 규칙을 몇 가지 권장한다. 가령 필자가 발 담고 있는 프런트엔드 라이브러리인 React에서도 다음과 같은 관례가 있다.

const [state, setState] = useState()

// 훅은 use라는 prefix로 시작한다. 
// useState는 배열을 반환하는 데 두번째 인자인 setter는 첫 번째 인자인 상태 이름 앞에 set을 붙여 사용한다.

const HelloComponent = ()=><h1>hello </h1>

// 컴포넌트 이름은 대문자로 시작한다.

이렇듯 네이밍과 관련된 관례는 해당 라이브러리로 작업하는 개발자들과의 약속이다. 이러한 네이밍 컨벤션은 독자로 하여금 자신의 코드를 훨씬 파악하기 쉽게 하는 역할을 한다.

필자도 네이밍에 신경 쓴다 하지만, 잘 챙기지 못하는 부분이 많다. 2 장에서 언급하듯, 맥락에 따라 변수, 함수, 클래스에 동일한 단어를 사용하는 습관이 필요할 것 같다.

🤔 궁금한 내용

다른 분들이 네이밍 컨벤션으로 접했던 신기했던 사례나 중요하다 느낀 사례가 궁금합니다!

사소한 곳에서 발휘하는 정직은 사소하지 않다.

📚 읽은 범위

📝 기억하고 싶은 내용

프로그래밍도 유행이나 스타일이 변하기 때문에 독자가 읽는 시점의 현실과 책이 소개하는 원칙이 잘 맞지 않는 부분 역시 존재하기 마련이다.

핵심은 팀이나 공동체에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통에 있다.

제조업과 마찬가지로 소프트웨어의 80%는 유지보수로 이루어져있다.

코드는 요구사항을 표현하는 언어라는 사실을 명심하라.

나중은 결코 오지 않는다. 나쁜 코드는 개발 속도를 크게 떨어뜨린다.

유명한 프로그래머들은 깨끗한 코드에 대해 다음과 같이 설명한다.

• 가독성 있고, 보기 즐거운 코드다.
• 한가지에 집중하고 간결하다.
• 명쾌한 추상화다.
• 타인이 수정하기 쉬운 코드다.
• 주의 깊게 작성한 코드다.
• 깨끗한 변수 이름, 깨끗한 함수, 깨끗한 클래스다.

💡 읽은 소감

남자는 태어나 3번 운다는 말이 있다. 나는 클린코드를 읽기 전에 빈번하게 들은 말이 있다.

이 책은 한번 읽고 끝이 아닌 신입 때, 주니어 때, 시니어 때 3번 읽어야 한다. 때마다 읽고 받아들이는 의미가 달라진다.

책의 서문과 1장을 읽고 들은 생각은 아직 내가 읽기에는 적합하지 않는 책일 수 있다는 것이다. 서문에서도 언급하듯 클린 코드의 핵심과 이 책이 주는 교훈은 팀이나 공동체에서 동의하는 합리적인 원칙을 세우기 위한 소통이기 때문이다. 아무래도 사내 스터디에 어울릴만한 책이라고 감히 판단해 본다.

그렇지만 이 책은 대부분의 사람들이 납득할 만한 이유를 토대로 깨끗한 코드에 대한 중요성을 강조하고 있다. 아직 아마추어인 나도 공감 가는 내용들이 한가득인데, 프로들은 얼마나 흥미롭고 재밌는 책일까? 이 책을 완독하고, 오랜 시간이 지난 후에 프로의 씬에 진입한 내가 다시 읽고 난 뒤 감상이 궁금해진다.

1장은 코드가 지저분해지는 이유와 유명한 프로그래머들의 말을 인용하면서 깨끗한 코드가 무엇인지 독자에게 설명한다. 설명하는 내용과 그간 내가 본 깨끗한 코드에 대한 다른 글들에서 봤던 주장들과 비교해가며 읽으니 더욱 흥미로웠다.

특히 “깨끗한 코드는 타인이 수정하기 쉽고, 가독성 높다.”라는 부분에서 그동안 내가 추상화를 하면서 깨끗하게 보이는 것처럼 한곳에 쑤셔 박아왔던 것이 아닌가 반성한다.

(토스 | SLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code)

클린 코드는 원하는 로직을 빠르게 찾을 수 있는 코드 즉, 가독성 있는 코드라는 것을 명심하자.

🤔 궁금한 내용

이번에 블로그를 다시 만들었다… (블로그 최종_최최종__최최최종…)

이번 블로그의 가장 큰 핵심은 글을 발행할 때 재배포 하지 않도록 DB나 CMS를 이용해 실시간으로 블로그에 글을 업로드 하는 것과 마음에 들지 않는 블로그 디자인을 수정하는 것이다. (디자인이 젤 어려워…)

DB를 이용하기에는 DB 클라우드 서비스를 이용해서 사용해야 하기 때문에 작업량이 많아질 것 같아서 전부터 봐왔던 Notion Api를 이용했다.

Notion을 이용해서 실시간으로 노션에서 새 글을 발행할 때마다 서버를 재배포하지 않고, 실시간으로 글을 발행할 수 있게 되었다.

이 과정에서 그동안 봐왔던 Next.js의 ISR을 사용하게 되었는데 이렇게 글로 남기게 되었다.

야심찬 시작, 실시간 글 발행

처음엔 단순히 노션에서 지원하는 Javascript SDK를 이용해서 개발했다.

역시 추상화되어 있는 SDK는 사용하기 편했고, Next.js의 SSR을 이용해서, 페이지 요청을 보낼 때 마다. 글을 불러와 MarkDown으로 만들어서 페이지에 표시해 주었다. 응답까지 대기 시간이 발생하기 때문에 Skeleton Ui를 구현해서 사용자가 로딩 중 임을 인식할 수 있게 만들었다.

블로그를 만들고 포스트를 올리던 중 느낀 점은 내가 이전의 봤던 페이지도 다시 불러올 때마다 기다려야 한다는 점이었다. 그렇다고 페이지를 SSG로 만들자니 글을 수정할 때마다 재배포 해야 했기 때문에 원점으로 돌아가게 된다.

그러던 중 Next의 ISR이 떠오르게 되었다. 바로 적용해 보자!

그래서 ISR이 뭔데

Next.js 공식 문서에서는 ISR을 다음과 같이 설명하고 있다.

ISR(Incremental Static Regeneration)을 사용하면 전체 사이트를 재 구축할 필요 없이 페이지별로 정적 생성을 사용할 수 있습니다 . ISR을 사용하면 정적의 이점을 유지하면서 수백만 페이지로 확장할 수 있습니다.

즉 정적으로 만들어 놓은 페이지 들도 필요시 업데이트할 수 있다는 것이다.

Next의 ISR 구현 방식은 현재 2가지가 있다.

Time-based Revalidation

Time-based Revalidation (시간 기반 재검증)은 요청에 ravalidate Time을 설정해 일정 시간이 지난 후, 데이터를 재검증하는 방법이다.

그림을 보면, 첫 번째 요청에서 cache가 없으므로 Data Source에 접근해서 응답 결과를 반환한다.

그다음 같은 요청을 보내면, cache에서 응답 결과를 반환한다.

이때 미리 지정해 둔 revalidate가 만료되면, 다음과 같이 작동한다.

• 백그라운드에서 데이터 재검증을 시작한다.
• 데이터를 성공적으로 가져오면 Next.js는 새로운 데이터로 cache를 업데이트한다.
• 재검증이 실패하면 이전 데이터가 변경되지 않은 상태로 유지된다.

On-Demand Revalidation

On-Demand Revalidation(온디맨드 재검증) 은 revalidatePath() 혹은 revalidateTag() 를 이용하여 요청을 재검증 한다.

revalidatePath() 는 페이지의 경로 기반으로 재검증하는 방식이고, revalidateTag() 는 ****fetch요청시 option으로 보내준 tag를 기반으로 재검증하는 방식이다.

사진은 revalidateTag() 를 사용한 예시를 보여준다. 첫번째 요청에서 tags를 포함해 요청을 보내주면, Data Source의 데이터를 가져와 cache에 저장한다.

이후 revalidateTag() 를 이용해 트리거 해주면, 트리거의 tag와 같은 tag를 가진 요청들이 캐시에서 제거된다. 다음에 같은 요청을 보내면, cache가 miss되어 다시 Data Source의 데이터를 가져와 cache에 저장한다.

Time-based Revalidation (시간 기반 재검증) 은 데이터가 자주 변경되지 않고 신선도가 그다지 중요하지 않은 데이터에 유용하다. On-Demand Revalidation(온디맨드 재검증) 은 가능한 한 빠르게 최신데이터를 표시하는 경우에 유용하다.

나는 블로그의 포스트가 최신화 되었을 때 데이터를 재검증 해주고 싶기 때문에, On-Demand Revalidation(온디맨드 재검증) 을 이용했다.

(공식문서도 친절하게 On-Demand방식의 예시로 CMS 콘텐츠 업데이트를 들고 있다…)

코딩 시작

나는 ISR의 revalidateTag()를 이용했는데, Tag를 이용한 이유는 단일 path로 최신화하는 것보다 tag로 직접 내가 그룹을 묶어서 캐시를 지워줄 수 있다고 생각했기 때문이다.

다는 두 가지 종류의 태그를 만들었다. 첫 번째는 글의 목록을 fetch 하는 “series” 두 번째는 글의 각각 id 값을 이용해서 글마다 최신화 상태에 대한 tag를 만들었다.

그렇다면 포스트 내용에 ISR을 적용한 코드를 보자

(이번 포스트는 ISR에 대한 내용이기 때문에 다른 코드는 참고로만 봐두자, 블로그 개발기는 시리즈로 계속 포스트 하겠다.)

이것은 내 글 본문을 만드는 코드다.

// app/post/[postId]/_components/PostBody.tsx

export default async ({ postId }: { postId: string }) => {
    const post = await notionPostData(postId);

    return (
        <section className="flex justify-center">
            <section className="w-full dark:prose-invert prose prose-md prose-hr:mt-5 p-5 prose-headings:mt-10 prose-blockquote:border-l-deepblue prose-a:no-underline">
                <MDXComponent source={post} />
            </section>
        </section>
    );
};

notionPostData() 에 글의 id인 postId 파라미터를 보내주면 postId와 같은 notion의 글 내용을 불러와 MarkDown String으로 변환해 준다. (이후 MDXComponent에서 source로 받은 문자열을 HTML로 렌더링 해준다.)

notionPostData() 에서 Data fetching 해주는 코드는 다음과 같다.

const res = await (
        await fetch(url, {
            method: "GET",
            headers: { accept: "application/json", "Notion-Version": "2022-06-28", Authorization: `Bearer ${process.env.NOTION_KEY}` },
            next: { revalidate: false, tags: [id] },
        })
    ).json();

Next.js의 확장된 fetch 옵션에 next에서 제공하는 옵션을 지정해 줬다.

next: { revalidate: false, tags: [id] },

revalidate의 type으로는 false 와 number 가 있다.

false는 말 그대로 데이터를 자동으로 재 검증하지 않는 것이다.

number를 넣어주면, next는 number(초) 이후에 발생하는 같은 요청에 revalidate 트리거를 실행한다.

나는 포스트를 직접 트리거 하지 않을 때는 정적 페이지로 이용할 생각이기 때문에 false를 사용했다.

Next.js에서 tags는 배열로 받는다. 즉, 트리거 될 태그를 여러 개 지정해 줄 수 있다.

나는 tags에 post의 id를 지정해 주었다. 이렇게 하면 각각의 포스트가 최신화되었을 때 전체 포스트를 갱신하는 게 아니라 변경된 포스트의 cache만 을 지정해서 지워줄 수 있다.

이렇게 data fetching 설정을 마치고 나면, 트리거를 할 수 있도록 코드를 작성해야 한다.

Next에서 RevalidatePath() 혹은 RevalidateTag()을 이용하기 위해서는 Sever Action을 이용하거나 직접 API를 만들어주는 방법을 사용해야 한다.

나는 직접 API를 만드는 방식을 이용했다.

//app/api/revalidate/route.ts

import { NextRequest, NextResponse } from "next/server";
import { revalidateTag } from "next/cache";

export async function POST(request: NextRequest) {
    const tag = request.nextUrl.searchParams.get("tag");
    const secret = request.nextUrl.searchParams.get("secret");

    if (secret !== process.env.REVALIDATE_SECRET) return NextResponse.json({ message: "Invalid secret" }, { status: 401 });
    if (!tag) return NextResponse.json({ message: "no Tag" }, { status: 401 });

    revalidateTag(tag);

    return NextResponse.json({ revalidated: true, now: Date.now(), message: "새로고침 성공" });
}

코드는 Next 공식 문서를 이용해서 작성했다.

해당 API는 Endpoint에 tag와 secret을 params로 받는다.

secret은 미리 지정해 둔 암호를 이용해서 무분별한 새로고침을 방지하기 위해 넣었다.

(지금은 임시방편으로 단순 문자열을 사용하고 있는데, 이런저런 블로그의 기능이 추가되면 변경해 보겠다.)

tag가 없거나 secret이 다를 경우에는 early return을 이용해서 트리거 되지 않게 만들었다.

요청이 오면 해당 tag를 이용해 tag의 cache를 제거하고, 이후 요청에 새로운 cache를 생성하게 된다.

이렇게 블로그에 해당 API 요청을 보내주는 버튼을 만들어서 글이 최신화되면, 눌러 트리거 되게 만들었다.

마치며

당연한 이야기지만 SSR을 이용했을 때와 ISR을 이용했을 때의 속도 차이는 분명했다.

(와우 ISR 만세!)

이번에 블로그에 ISR을 도입하면서, Next의 ISR을 좀 더 잘 알게 되었고, 조금이나마 블로그 성능 개선도 할 수 있던 좋은 경험이었다.

역시 실제로 개발을 진행하면서 발생하는 문제를 해결하는 과정에서 얻는 경험과 지식이 책으로만 얻는 것보다 값진 것 같다. (물론 그렇다고 책으로 얻는 지식이 별로라는 말이 아니다.)

이번에 테스트하면서 알게 된 내용과 고민해 봐야 할 문제들이 생겼다.

1. 노션에서 글이 최신화되었을 때 따로 버튼을 누르지 않고 트리거 되도록 만들기 이건 내가 직접 서버와 DB를 이용한다면, DB를 최신화하는 과정에서 트리거 하는 API에 요청을 보내주면 되는 데, 지금은 notion을 CMS로 이용하고 있기 때문에 고민을 해봐야겠다.
2. 현재 노션에서 블록이 많은 글을 불러올 때 속도가 너무 느리다. 지금 내 블로그에서 글 본문을 불러오는 방식은 글의 모든 블록을 가져온 다음 Markdown으로 변환하고, 렌더링하는 방식이다. 블록이 너무 많으면, 변환하는 과정에서 사용자는 긴 로딩 시간을 겪게 되는데, 블록을 각각의 작은 블록으로 만들어서 조금씩 렌더링 하는 방식을 생각해 봐야겠다.

(블로그 포스트는 걱정 안 해도 될 것 같다… 블로그도 만들고 개발 포스트도 만들고 1석 2조….)

내 블로그 - https://tealsblog.vercel.app/posts/a17fba55-be05-4589-bead-6f076f10093b

참고 자료

https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation

https://nextjs.org/docs/app/building-your-application/caching#on-demand-revalidation

네 맞습니다... React할때 무지성으로 CRA만 하던 사람 바로 접니다...

CRA는 개발자 본인이 React를 위한 환경을 만들어 주지 않아도 자동으로 React 프로젝트를 시작할 수 있게 환경을 만들어 주는 개발도구 입니다.

npm create-react-app "" 만 입력하면 자동으로 의존성들을 설치해주고 기본적인 보일러 프로젝트를 생성해 개발자는 작업만 할 수 있도록 만들어줍니다!

그치만 문제가 있죠..

1. 기술에는 항상 발전이 있습니다.
2. 가볍게 시작하기에는 불필요한 의존성도 포함되어 있습니다.
3. 어썸하지 않습니다?!

사실 CRA만 이용해도 큰 문제는 없습니다. 저도 지금까지 CRA로 모든 react프로젝트를 진행했구요... 하지만, 이번에 새로운 React 프로젝트를 진행하기 위해서 tailwind를 설치하는 과정에서 이런 걸 봐버렸습니다.

(엥? 아무튼 Vite를 쓰는게 좋다는데?)

Next.js를 사용하는 방법도 있었지만, 저는 이미 Next.js로 기능 구현을 해 보았으며 이번에는 React로 진행 해보고 싶던 와중에 Vite는 좋은 대안이 될 것 같았습니다.

그래서 Vite가 뭔데

Vite는 현대적인 웹 개발을 위한 빠르고 경량화된 빌드 도구입니다. Vue.js의 창시자인 Evan You가 개발한 Vite는 Vue.js를 위해 만들어진 것이지만, 최근에는 React와 TypeScript를 지원하기도 합니다.

(땡큐 Chat Gpt)

vite는 CRA와 같은 개발도구입니다. 처음에는 Vue를 위해 만들어 졌지만, React와 Typescript를 이용한 React 프로젝트를 지원합니다.

그리고 "현대적인 웹 개발" 이거 못참습니다.

GPT가 알려준 vite의 장점은 다음과 같습니다.

1. 빠른 개발 서버:HMR (Hot Module Replacement)을 지원하고 있어 코드 변경 시 실시간으로 변경 사항이 반영됩니다.

2. 빠른 빌드: Vite는 ES 모듈을 사용하여 개별 파일을 로드하기 때문에 초기 빌드 속도가 매우 빠릅니다. 파일 단위로 캐싱하여 변경된 파일만 다시 빌드하므로 전체 애플리케이션을 다시 빌드할 필요가 없습니다.

3. 더 작은 번들 크기: Vite는 개발 중에 ES 모듈을 그대로 유지하고, 프로덕션 빌드 시에만 번들링합니다. 이로 인해 번들 크기가 작아지고 초기 로딩 속도가 향상됩니다.

4. 확장성: Vite는 TypeScript, CSS 전처리기 (Sass, Less), 테스트 프레임워크 (Jest 등) 등과 쉽게 통합됩니다. 다양한 플러그인과 기능을 제공하여 개발자가 프로젝트에 필요한 도구와 환경을 유연하게 구성할 수 있습니다.

사실 CRA에서도 지원해주는 부분들이지만, 전체적으로 Vite가 React보다 더작은 번들의 크기와 더 빠른 속도라는 점에서 충분히 매력을 느낄 수 있는 것 같습니다.

(심지어 이름부터 프랑스어로 빠르다임)

그래서 Vite 어캐 하는 건데?

여러분이 CRA 하던것 처럼 Vite로 넘어가면 됩니다!!

먼저 npm create vite@latest를 작성합니다. 우리는 항상 최신버전을 사용하는 상남자니까 최신버전으로 진행하겠습니다.

프로젝트 이름까지 작성하고 나면 어떤 프로젝트를 진행할지 정할 수 있습니다. (뷰부터 리액트, 스벨트 까지.... 없는게 없네여)

리액트를 선택하면 다음과 같이 Typescript를 사용할 것인지 Javascript를 사용할 것인지 선택하는 창이 나옵니다.

그런데 여기서 처음보는 친구가 나옵니다 SWC? 그래서 검색을 해봤져 여러분의 시간은 소중하니까요.

SWC는 Rust로 작성된 JavaScript 및 TypeScript 코드를 변환하는 고성능 JavaScript 컴파일러입니다. 주요 목표는 향상된 성능과 더 빠른 변환 속도를 제공하는 것입니다.

아! Babel과 비슷한 친구였군요. 안그래도 vite가 빠른데 거기에 컴파일러도 더 빠른 속도? 참을 수 있습니까?

여기까지 설정하시면

어디서 많이 본듯한 폴더 구조가 생기죠? CRA에 index.tsx가 main.tsx로, index.html이 폴더 가장 최상단에 있는 차이를 빼면, 동일한 React 프로젝트를 시작할 수 있습니다!

그럼 더 빨라진 React를 즐기러 가보겠습니다.

Vite에서 환경변수를 사용할때 prefix를 VITE_로 적고 import.meata.env.로 접근할 수 있다고 합니다...

React에서 삽질을 하다가 Form을 만들면서 갑자기 든 생각이었다.

왜 input에 onchange를 사용해서 input 값을 가져올까? 그냥 submit에있는 event 안에 있는 target의 값을 가져오면 되지 않나?

그래서 한번 커스텀 훅을 만들어 보았다… 타스를 제대로 알지 못한채로 작성해서 코드가 맛이없을 수도 있습니다….

일단 전체 코드를 보자

전체코드

export function useForm<T>(initialValues: T): [T, FormEventHandler<HTMLFormElement>] {
    const [data, setData] = useState<T>(initialValues);
    const onSubmit: React.FormEventHandler<HTMLFormElement> = (e) => {
        e.preventDefault();

        const inputs = [...e.currentTarget];
        const obj: T = inputs.reduce((acc: T, crr: Element) => {
            const { name, value } = crr as HTMLInputElement;
            return { ...acc, [name]: value };
        }, {} as T);

        setData(obj);
    };

    return [data, onSubmit];
}

이게 내 useForm 훅의 전부이다.

내 useForm은 첫번째 인자로 input의 name을 가진 object를 받는다. 그 후 배열을 반환하는데 배열의 첫번째 값은 값에 접근할 수 있는 object(이때 타입은 useForm의 첫번째 인자와 동일하다.) 두번째는 form에 붙여줄 onSubmit 핸들러이다.

예시 코드를 작성해보자면 다음과 같다.

사용 예시

function App() {
    const [data, onSubmit] = useForm<Info>({ name: "", age: "", location: "" });
    return (
        <>
            <form
                className="form"
                onSubmit={onSubmit}
            >
                <input
                    name="location"
                    type="text"
                    placeholder="location"
                />

                <input
                    name="name"
                    type="text"
                    placeholder="name"
                />
                <input
                    name="age"
                    type="number"
                    placeholder="age"
                />
                <input type="submit" />
            </form>

            <div>
                <p>Name : {data.name}</p>
                <p>age : {data.age}</p>
                <p>location : {data.location}</p>
            </div>
        </>
    );
}

export default App;

보면 initialValues 안에 들어간 object의 프로퍼티 이름과 input의 name 이름이 동일한 것을 알 수 있다.

이렇게 해서 submit 버튼을 누르면 input의 name과 initialValues의 프로퍼티 값을 확인해서 값을 넣어준다.

그것이 내 훅의 동작 방법이 되는 것이다. 그럼 이제 코드를 하나씩 뜯어보도록 하자

const [data, setData] = useState < T > initialValues;

데이터를 저장할 useState! 이 친구가 있기 때문에 data값이 form을 통해서 바뀌면 우리의 ui도 바뀔 것이다.

다음으로 onSubmit 핸들러를 보자

const onSubmit: React.FormEventHandler<HTMLFormElement> = (e) => {
    e.preventDefault();

    const inputs = [...e.currentTarget];
    const obj: T = inputs.reduce((acc: T, crr: Element) => {
        const { name, value } = crr as HTMLInputElement;
        return { ...acc, [name]: value };
    }, {} as T);

    setData(obj);
};

일단 submit이벤트의 기본동작인 웹페이지 새로고침을 막아주자! e.preventDefault();

다음으로 input들의 dom을 배열로 만들어 주었다.

const inputs = [...e.currentTarget];

const obj: T = inputs.reduce((acc: T, crr: Element) => {
            const { name, value } = crr as HTMLInputElement;
            return { ...acc, [name]: value };
        }, {} as T);

다음으로 코테에서 많이 사용한 reduce함수를 이용하여 새로운 obj를 만들어 주었다.

input을 한개씩 가져와서 input 안에있는 name과 value를 가지고 initialValues와 같은 타입의 객체를 만들어 주었다.

이후 setData() 에 반환값으로 넘겨주어 data를 저장하고 랜더링한다.

마치며…

이렇게 나만의 form 커스텀 훅을 만들어 보았다..

고집때문에 삽질하다가 ts와 절교할 뻔했지만… 무사히 넘어갔다.

form안에 input을 제어하는 코드를 onchange를 이용해서 만들길래 뭔가나는 굳이? 싶어서 이런식으로 만들어 봤다. 뭔가 onchange를 사용해야하는 이유가 있다면 알려주세여….

엄청 대단한 건 아니지만 뭔가 커스텀 훅을 만들었다고 생각하니까 큰일을 해낸거 같아서 기쁘다!

Symbol : ES6에서 도입된 7번째 데이터 타입으로 변경 불가능한 원시 타입

심벌은 다른 값과 중복되지 않는 유일무이한 값이고, 주로 이름 충돌 위험이 없는 유일한 프로퍼티 키를 만들기 위해 사용합니다!

나를 괴롭히던 NEXT 13 Request 객체 프로퍼티 키들이 다 이놈이였구나..

심벌 값의 생성

심벌 값은 Symbol 함수를 호출하여 생성할 수 있습니다.

심벌은 Symbol 함수 호출 없이는 생성할 수 없고, 생성된 심벌 값은 외부로 노출되지 않아 확인할 수 없으며, 다른 값과는 중복되지 않습니다.

const tag = Symbol();
console.log(typeof tag); // symbol

console.log(tag); // Symbol()

Symbol함수는 선택적으로 문자열을 인수로 전달 할 수 있습니다.

이 문자열은 생성된 심벌 값에 대한 설명으로 디버깅 용도로만 사용 되고, 심벌 값에 어떠한 영향도 주지 않습니다.

고로, 이 문자열이 같아도 둘은 다른 심벌값이기 때문에 서로 간섭이 없죠.

const tag = Symbol("name");
const list = Symbol("name");

console.log(tag === list); // false

심벌값도 래퍼 객체를 생성합니다. description, toString 은 Symbol.prototype의 메서드입니다.

const tag = Symbol("name");

console.log(tag.description); // name
console.log(tag.toString()); // Symbol(name)

심벌타입은 숫자 문자 타입으로 암묵적 변환이 일어나지 않습니다.

다만 불리언타입으로는 변환 되죠.

다행히 지옥의 암묵적 변환은 없…

Symbol.for() / Symbol.keyFor()

Symbol.for()

Symbol.for 메서드는 인수로 받은 문자열을 키로 사용하여 키와 심벌 값들이 저장되어 있는 전역 심벌 레지스트리에서 해당 키와 일치하는 심벌값을 검색합니다.

• 검색에 실패하면 새로운 심벌 값을 생성하여 Symbol.for() 메서드의 인수로 전달된 키로 전역 심벌 레지스트리에 저장한 후 생성된 심벌값을 반환
• 검색에 성공하면 검색된 심벌 값을 반환.

const tag = Symbol.for("tag");
const tag2 = Symbol.for("tag");
console.log(tag === tag2); // true

Symbol 과 Stmbol.for의 차이는 전역 심벌 레지스트리에 저장되어 검색할 수 있는 지 없는 지입니다.

Symbol.keyFor()

Symbol.keyFor()를 사용하면 심볼의 키를 추출 할 수 있다.

const tag = Symbol.for("name");

Symbol.keyFor(tag); // "name"

그렇다면 심볼을 어떤식으로 사용할까?

값에 특별한 의미가 없고 상수 이름 자체에 의미가 있는 경우

const Direction = {
    UP: 1,
    DOWN: 2,
};

const myDirection = Direction.UP;

console.log(myDirection === Direction.UP);

위의 코드에서 Direction에 존재하는 UP, DOWN 프로퍼티의 값은 중요하지 않습니다.

그저 UP을 표시하는 지, DOWN을 표시하는 지가 궁금할 뿐이죠.

하지만 상수 값은 변경이 가능하고 중복될 가능성이 있기 때문에 Symbol 값으로 바꾸는 것이 좋습니다.

const Direction = {
    UP: Symbol("up"),
    DOWN: Symbol("down"),
};

const myDirection = Direction.UP;

console.log(myDirection === Direction.UP);

심벌과 프로퍼티 키

객체의 프로퍼티 키로 심볼을 이용할 수 있습니다.

const obj = {
    [Symbol.for("num")]: 1,
};

console.log(obj[Symbol.for("num")]); //1

이때 프로퍼티 키로 사용할 심벌 값에 대괄호를 사용해야 하고, 프로퍼티에 접근할 때도 마찬가지로 대괄호를 사용해야합니다.

프로퍼티 은닉

심벌 값을 프로퍼티 키로 사용하여 생성한 프로퍼티는 찾을 수 없습니다.

고로, 프로퍼티를 숨겨놓을 수 있겠네요..

이렇게 숨긴 프로퍼티는 for … of.. 와 같은 방법으로는 찾을 수 없습니다.

const obj = {
    [Symbol("num")]: 1,
};

console.log(obj[Symbol("num")]); //undefined

하지만 완전히 숨길 수 있는 것은 아닙니다.

ES6에 추가된 Object.getOwnPropertySymbols() 메서드를 이용하면 심벌 값을 프로퍼티 키로 사용하여 찾을 수 있죠.

const obj = {
    [Symbol("num")]: 1,
};

console.log(obj[Object.getOwnPropertySymbols(obj)[0]]); //1

Well-known Symbol

자바스크립트가 기본적으로 제공하는 빌트인 심벌 값이 있습니다.

이런 값들을 ECMAScript에서는 Well-known Symbol이라 칭합니다.

예를 들어 빌트인 이터러블은 Well-known Symbol인 Symbol.iterator를 키로 갖는 메서드를 가지며, Symbol.iterator 메서드를 호출하면 이터레이터를 반환하도록 ECMAScript 사양에 규정되어 있습니다.

🚪

오늘은 심벌에 대해 알아봤습니다.

처음에 만났을 때는 꽤 당황했는데… 쉽게 유일무이한 원시 값이라고 생각하고 접근하니 괜찮은 것 같습니다.

이제 두려움 떨치고 사용해 봅시다… 심벌…

이번에 next13이 어느정도 안정화되고… 여러 기능들을 읽어보니까 너무 사용하고 싶어서..

이거 저거 만져보고 지금 블로그도 13버전으로 마이그레이션 하다보니까.. 시간이 너무 부족했습니다.

새로운 환경이라 정보도 적고, 12버전에서 만들어 놓은 함수들과 페이지들을 전부 수정해야 하니 생각보다 시간이 많이 걸리더군요,…

+Typescript 를 추가했는데… ㅋㅋㅋ 타입 충돌이 많이 나더군요..

일단 만들어 놓은 북마크 기능을 보여드리도록 하죠

사용자가 mdx파일에 ~~url~~ 형식으로 작성하면 페이지의 og테그 내용을 가져와 북마크로 만들어 줍니다

시작!

og테그를 가져오기 위한 라이브러리는

https://www.npmjs.com/package/open-graph

를 사용했습니다.

하지만 이 라이브러리를 next.js 서버컴포넌트에서 사용하려하니 net 모듈이 필요하더군요…

최대한 라이브러리 작업을 하지 않기 위해 다음과 같은 방법을 사용했습니다.

1. api route를 만들어서 og태그를 받아오는 api를 만든다.
2. 서버컴포넌트에서 api를 호출한다.
3. 북마크를 랜더링한다.
4. MDXcomponents 에서 북마크 컴포넌트를 불러온다!

처음엔 nextjs의 rewrite기능을 이용해서 임의로 만든 api키를 숨기는 방식을 사용하려 했지만..

왜인지 vercel에 배포하면 rewrite로 불러올때 header를 가져오는 과정에서 이전 url의 파라미터를 가져올 수 가 없었습니다…

그래서 서버에서 api를 호출 하는 방식으로 apikey를 숨겼습니다.

코드를 보시죠!

api

//app/api/getOg

import { NextRequest, NextResponse } from "next/server";
import og from "open-graph";

const getOg = (url: string) =>
    new Promise((resolve, reject) => {
        og(url, function (err, meta) {
            if (err) {
                reject(err);
                return;
            }
            resolve(meta);
        });
    });

export async function GET(request: NextRequest) {
    const url = request.nextUrl.searchParams.get("url");
    const api_key = request.nextUrl.searchParams.get("api_key");

    if (api_key !== process.env.API_KEY) return NextResponse.json({ title: "NOT MATCH API KEY", api_key });
    if (!url) return NextResponse.json({ title: "NO URL" });
    try {
        const data = await getOg(encodeURI(url));
        return NextResponse.json(data);
    } catch (err) {
        return NextResponse.json({ err });
    }
}

api는 파라미터에 url과 api_key를 받아옵니다. api_key가 같은지 확인하고, 틀리다면 리턴합니다.

api키가 동일하다면, getOg함수를 이용하여 open-graph 태그를 가져옵니다.

가져온 태그를 json 형식으로 리턴합니다.

이렇게 받아온 코드를 bookmark 컴포넌트에서는 다음과 같은 방법으로 받아옵니다.

Bookmark

import Link from "next/link";
import { use } from "react";

interface data {
    title: string;
    image: {
        url: string;
    };
    description?: string;
}
const getOgData = async (url: string) => {
    const baseUrl = process.env.NODE_ENV === "development" ? `http://localhost:3000` : "https://tealslog.vercel.app";
    const data = await (await fetch(baseUrl + `/api/getOg?api_key=${process.env.NEXT_PUBLIC_API_KEY}&url=${url}`)).json();
    return data;
};

export default ({ url }: { url: string }) => {
    const data: data = use(getOgData(url));

    return (
        <>
            {data && (
                <Link href={url}>
                    <div className="shadowBottom my-10 flex h-[200px] hover:scale-105">
                        <div className="h-full w-[30%] relative">
                            <img
                                src={data.image?.url}
                                alt="Image"
                                className="h-full w-full object-cover "
                            />
                        </div>
                        <div className="w-[70%] h-full relative flex flex-col justify-between p-4">
                            <div className="overflow-hidden">
                                <h1 className="text-[24px] font-bold mb-2 ">{data.title}</h1>
                                <p className="text-[12px]">{data.description}</p>
                            </div>

                            <small className="text-end overflow-clip text-[gray]">{decodeURI(url)}</small>
                        </div>
                    </div>
                </Link>
            )}
        </>
    );
};

Next 13 버전부터는 최상단에 “use client”를 작성하지 않은 컴포넌트는 모두 서버컴포넌트입니다.

서버컴포넌트에서는 fetch를 이용해서 데이터를 가져오죠

가져온 데이터를 컴포넌트에서 사용할땐 use()함수를 사용합니다.

Bookmark 컴포넌트는 url을 props로 받아서 api를 호출하고 받은 데이터를 북마크로 만들어줍니다.

이렇게 만든 컴포넌트는 스켈레톤 ui를 포함합니다.

export const SkeletonBookmark = () => {
    return (
        <div className="shadowBottom my-10 flex h-[200px]">
            <div className="h-full w-[30%] bg-[gray] animate-pulse"></div>
            <div className="w-[70%] h-full relative flex flex-col justify-between p-4">
                <div>
                    <h1 className="w-[40%] text-[24px] font-bold mb-2 bg-[gray] h-[30px] animate-pulse"></h1>
                    <div className="w-[100%] text-[12px] h-[16px] animate-pulse flex items-center"></div>
                </div>
                <small className="text-end bg-[gray] h-[12px] animate-pulse"></small>
            </div>
        </div>
    );
};

mdx파일을 호출하면,

suspend에 fallback에 넘겨진 스켈레톤 ui를 먼저 보여준뒤,

데이터를 받으면 bookmark 컴포넌트를 렌더합니다.

🚪

이걸 만드는데 정말 많은 시행착오를 지난 것 같습니다..

막상 결과를 만들고 나니 정말 뿌듯하고 이쁜거 같네요 ㅎㅎㅎ

앞으로는 next 13을 사용해본 내용을 정리할거 같습니다

마지막으로 북마크를 만들면서 가장 많이 들었던 노래를 공유하면서 마치겠습니다!

https://www.youtube.com/watch?v=hHD2GGRIJ9k

앞으로 다룰 클로저의 동작방식, 호이스팅 발생 이유, 태스크 큐와 함께 동작하는 이벤트 핸들러와 비동기 처리방식을 쉽고, 확실하게 이해하려면 실행 컨텍스트를 확실하게 이해하고 넘어가야 합니다..

쉽지 않고 내용도 많지만, 한번 해치워 보죠!

소스코드의 타입

ECMAScript는 소스코드를 4가지타입으로 구분합니다.

• 전역 코드(Global code)

  전역에 존재하는 (전역에 정의된 함수, 클래스의 내부를 제외한)소스코드

• 함수 코드(Function code)

  함수 내부에 존재하는 (중첩된 함수, 클래스의 내부를 제외한) 소스코드

• eval코드 (Eval code)

  빌트인 전역 함수인 eval 함수에 인수로 전달되어 실행되는 소스코드

• 모듈 코드 (Module code)

  모듈 내부에 존재하는 (모듈 내부 함수, 클래스를 제외한) 소스코드

소스코드를 구분하는 이유는

각 소스코드 타입에 따라 실행 컨텍스트를 생성하고 관리하는 과정이 다르기 때문입니다.

각 코드는 평가 이후 실행 컨텍스트가 생성됩니다.

전역 코드

전역 코드는 전역 스코프를 생성해 전역변수를 관리합니다.

var키워드로 선언된 전역 변수와 함수 선언문으로 정의된 전역 함수를 전역 객체의 프로퍼티와 메서드로 바인딩 하고 참조하기 위해 전역 객체와 연결 되어야 합니다.

함수 코드

함수 코드는 지역 스코프를 생성하고, 지역 변수, 매개 변수, arguments객체를 관리해야합니다.

생성한 지역 스코프를 전역 스코프에서 시작하는 스코프 체인의 일원으로 연결해야합니다.

eval 코드

eval코드는 strict mode(엄격 모드)에서 자신만의 독자적인 스코프를 생성합니다.

모듈 코드

모듈 코드는 모듈별로 독립적인 모듈 스코프를 생성합니다.

소스코드의 평가와 실행

자바스크립트 엔진은 소스코드를 소스코드의 평가와 소스코드의 실행 2개의 과정으로 나누어 처리합니다.

소스코드 평가

실행 컨텍스트를 생성하고 변수, 함수 선언문이 먼저 실행하여 생성된 변수나 함수 식별자를 키로 실행 컨텍스트가 관리하는 스코프(렉시컬 환경의 환경 레코드)에 등록합니다.

소스코드 실행

소스코드 평가과정이 끝나면 선언문을 제외한 소스코드가 순차적으로 실행됩니다. (런타임)

이때 실행에 필요한 정보(변수, 함수의 참조)는 실행 컨텍스트가 관리하는 스코프에서 검색해서 취득합니다.

그리고 변수값의 변경과 같은 소스코드의 실행 결과는 다시 실행 컨텍스트가 관리하는 스코프에 등록됩니다.

const x = 1;
const y = 2;

function foo(a) {
    const x = 10;
    const y = 20;

    console.log(a + x + y);
}

foo(100);
console.log(x + y);

위에 있는 코드로 예시를 들겠습니다!

전역코드 평가

전역 코드 평가 과정을 거치며 선언문이 먼저 실행된다.

그결과 생성된 전역 변수와 전역 함수가 실행 컨텍스트가 관리하는 전역스코프에 등록된다.

전역 코드 평가 괒

전역코드 실행

평가가 끝나면 런타임이 시작되어 전역 변수에 값이 할당되고 함수가 호출된다.

함수코드 평가

함수 호출에 의해 코드 실행순서가 변경되어 함수 내부로 진입한다.

이때 함수 실행 이전에 함수코드를 평가하면서 매개변수와 지역 변수 선언문이 먼저 실행되고,

그 결과가 실행 컨텍스트가 관리하는 지역 스코프에 등록된다.

또한 함수 내부에서 지역 변수처럼 사용할 수 있는 arguments 객체가 생성되어 지역 스코프에 등록되고,

this 바인딩도 결정된다.

함수코드 실행

런타임이 시작되고, 매개변수와 지역변수에 순차적으로 값이 할당된다.

cosole.log 메서드를 호출하기 위해 console을 스코프 체인을 통해 검색한다.

이를 위해 함수코드의 지역 스코프는 상위스코프인 전역 스코프와 연결되어야 한다.

하지만 console 식별자는 스코프 체인에 등록되어 있지 않고 전역 객체에 프로퍼티로 존재한다.

다음으로 log메서드를 console 객체의 프로토타입 체인을 통해 검색한다.

다음 표현식 a+x+y를 평가한다.

코드가 실행되려면 다음과 같은 스코프, 식별자, 코드 실행순서 등의 관리가 필요합니다.

• 선언에 의해 생성된 모든 식별자를 스코프를 구분하여 등록하고 상태변화를 지속적으로 관리할 수 있어야 한다.
• 스코프는 중첩 관계에 의해 스코프 체인을 형성해야 한다. 즉, 스코프 체인을 통해 상위 스코프로 이동하여 식별자를 검색할 수 있어야 한다.
• 현재 실행중인 코드의 실행 순서를 변경할 수 있어야 하며 다시 되돌아갈 수도 있어야한다.

실행 컨텍스트가 바로 이 모든 것들을 관리합니다.

실행 컨텍스트 스택(Call Stack)

const x = 1;

function foo() {
    const y = 2;

    function bar() {
        const z = 3;
        console.log(x + y + z);
    }

    bar();
}

foo();

위 코드는 전역 코드와 함수 코드로 이루어져 있습니다.

자바스크립트 엔진은 전역 코드를 평가하고 전역 실행 컨텍스트를 생성하고,

함수코드를 평가하고 함수 실행 컨텍스트를 생성합니다.

이때 생성된 실행 컨텍스트는 스택 자료구조로 관리하고 이를 실행 컨텍스트 스택(또는 Call Stack)이라고 부른답니다.

렉시컬 환경

렉시컬 환경은 식별자와 식별자에 바인딩된 값, 상위 스코프에 대한 참조를 기록하는 자료구조이자,

실행 컨텍스트를 구성하는 컴포넌트입니다.

렉시컬 환경은 키와 값을 갖는 객체 형태의 스코프를 생성하여 식별자를 키로 등록하고 식별자에 바인딩 된 값을 관리합니다.

실행 컨텍스트는 Lexical Environment 컴포넌트와 Variable Environment 컴포넌트로 구성된다.

모딥다에서는 정적모드와 eval, try/catch와 같은 특수한 상황은 제외하고, Lexical Environment와 Variable Environment 컴포넌트도 구분하지 않고, 하나의 렉시컬 환경으로 통일해 설명한다.

렉시컬 환경은 두개의 컴포넌트로 구성됩니다.

환경 레코드(Environment Record)

스코프에 포함된 식별자를 등록하고 등록된 식별자에 바인딩 된 값을 관리하는 저장소,

환경 레코드는 소스코드의 타입에 따라 관리하는 내용에 차이가 있습니다.

외부 렉시컬 환경에 대한 참조(Outer Lexical Environment Reference)

외부 렉시컬 환경에 대한 참조는 상위 스코프를 가리킵니다.

이때 상위 스코프란 외부 렉시컬 환경, 즉 해당 실행 컨텍스트를 생성한 소스코드를 포함하는 상위 코드의 렉시컬 환경을 말합니다.

외부 렉시컬 환경에 대한 참조를 통해 단방향 링크드 리스트인 스코프 체인을 구현합니다.

실행 컨텍스트의 생성과 식별자 검색 과정

var x = 1;
const y = 2;

function foo(a) {
    var x = 3;
    const y = 4;

    function bar(b) {
        const z = 5;
        console.log(a + b + x + y + z);
    }

    bar(10);
}

foo(20);

이 코드를 이용해서 실행 컨테스트의 전체적인 흐름을 알아봅시다!!

전역 객체 생성

전역 객체는 전역 코드가 평가되기 이전에 생성됩니다.

이때 전역 객체에는 빌트인 전역 프로퍼티와 빌트인 전역함수, 표준 빌트인 객체가 추가되며 동작환경 또는 특정 환경을 위한 호스트 객체를 포함합니다.

전역 코드 평가

생성된 전역 실행 컨텍스트와 렉시컬 환경

1. 전역 실행 컨텍스트 생성

비어있는 전역 실행 컨텍스트를 생성하여 스택에 푸쉬합니다.

이때 전역 실행 컨텍스트는 스택의 최상위 (실행중인 실행 컨텍스트)가 됩니다.

2. 전역 렉시컬 환경 생성

전역 렉시컬 환경을 생성하고 전역 실행 컨텍스트에 바인딩합니다.

2-1 전역 환경 레코드 생성

전역 렉시컬 환경을 구성하는 컴포넌트인 전역 환경 레코드는 전역 변수를 관리하는 전역 스코프, 전역 객체의 빌트인 전역 프로퍼티와 빌트인 전역 함수, 표준 빌트인 객체를 제공합니다.

전역환경레코드는 객체 환경 레코드와 선언적 환경 레코드로 구성되어 있습니다.

2-1) 1. 객체 환경 레코드 생성

전역 코드 평가 과정에서 var 키워드로 선언한 전역 변수와 함수 선언문으로 정의돈 전역 함수는 전역 환경 레코드의 객체 환경 레코드에 연결된 BindingObject를 통해 전역 객체의 프로퍼티와 메서드가 됩니다.

이때 등록된 식별자를 전역 환경 레코드의 객체 환경 레코드에서 검색하면 전역 객체의 프로퍼티를 검색후 반환합니다.

이것이 var 키워드로 선언된 전역변수와 함수 선언문으로 정의된 전역 함수가 전역 객체의 프로퍼티와 메서드가 되고, 전역 객체를 가리키는 식별자(window)없이 객체의 프로퍼티를 참조 할 수 있는 메커니즘입니다.

호이스팅

var키워드로 선언한 변수와 var키워드로 선언한 변수에 할당한 함수 표현식은 코드 평가 단계에서 정의 및 초기화가 진행됩니다.

함수 선언문으로 정의한 함수가 평가되면 함수 이름과 동일한 이름의 식별자를 객체 환경 레코드에 바인딩 된

BindingObject를 통해 전역 객체에 키로 등록하고 생성된 함수 객체를 즉시 할당합니다.

(그래서 호이스팅으로 선언된 함수는 선언문 이전에도 호출할 수 있는 거랍니다..)

2-1) 2. 선언적 환경 레코드 생성

let, const로 선언한 전역 변수는 선언적 환경 레코드에 등록되고 관리됩니다.

(따라서 객체 환경 레코드에 선언된 다른 변수와는 다르게 window.y로 호출할 수 없습니다.)

일시적 사각지대

const와 let키워드로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행되기 때문에 소스코드 평가단계에서 선언적 환경 레코드에 해당 변수의 이름을 키값으로 한 프로퍼티가 등록되고, 초기화 되지 않아 아무런 값이 바인딩 되지 않았기 때문에 변수에 접근할 수 없습니다.

2-2. this 바인딩

전역 환경 레코드의 [[GlobalThisValue]] 내부 슬롯에 this가 바인딩 됩니다.

일반적으로 전역 코드에서 this는 전역 객체이므로 [[GlobalThisValue]] 내부 슬롯은 전역 객체가 바인딩됩니다.

2-3. 외부 렉시컬 환경에 대한 참조

외부 렉시컬 환경에 대한 참조는 현재 평가중인 소스코드를 포함하는 외부 소스코드의 렉시컬 환경 즉 상위 스코프를 가르킵니다.

하지만 전역코드를 포함하는 외부 소스코드는 없으므로 null이 할당됩니다.

전역코드 실행

이제 전역코드가 순차적으로 실행되기 시작합니다.

변수 할당문이 실행되어 전역 변수 x,y에 값이 할당된다. 그리고 foo함수가 호출됩니다.

변수 할당문, 함수 호출문을 실행하려면 먼저 변수, 또는 함수 이름이 선언된 식별자인지 확인해야 합니다.

또한 같은 이름의 식별자가 다른 스코프에 존재할 수 있으므로 참조할 식별자를 구분해야 합니다.

이것을 식별자 결정이라고 합니다.

현재 실행중인 실행 컨텍스트는 전역 실행 컨텍스트이므로 전역 렉시컬 환경에서 식별자 x, y, foo를 검색하기 시작한다. 만약 실행중인 실행 컨텍스트의 렉시컬 환경에서 식별자를 검색할 수 없으면 외부 렉시컬 환경에 대한 참조가 가리키는 렉시컬 환경(상위 스코프)으로 이동하여 식별자를 검색합니다.

아하! 이게 스코프체인의 동작 원리군요!

전역 렉시컬 환경은 스코프체인의 종점이므로 전역 렉시컬 환경에서 검색할 수 없는 식별자는 참조 에러를 발생시킵니다.

(그놈의 Reference Error…)

함수 코드 평가

var x = 1;
const y = 2;

function foo(a) {
    var x = 3;
    const y = 4;

    function bar(b) {
        const z = 5;
        console.log(a + b + x + y + z);
    }

    bar(10);
}

foo(20); <- 호출 직전

foo 함수가 호출되면 전역 코드의 실행을 일시 중단하고 foo함수 내부로 코드의 제어권이 이동하고, 함수 코드를 평가하기 시작합니다.

1. 함수 실행 컨텍스트 생성

함수 실행컨텍스트를 생성하여 렉시컬 환경을 만든 후 실행 컨텍스트에 푸쉬합니다.

2. 함수 렉시컬 환경 생성

foo 함수의 렉시컬 환경을 생성하고 실행 컨텍스트에 바인딩 합니다.

함수의 렉시컬 환경에서도 마찬가지로 환경 레코드와 외부 렉시컬 환경에대한 참조 2개의 컴포넌트로 구성됩니다.

2-1 함수 환경 레코드 생성

함수 환경 레코드는 매개변수, arguments객체, 함수 내부에서 선언한 지역 변수와 중첩 함수를 등록하고 관리합니다.

2-2) this 바인딩

함수 환경 레코드의 [[ThisValue]] 내부 슬롯에 this가 바인딩 된다. 이때 함수 호출 방식에 따라 결정됩니다.

여기서는 일반 함수를 호출 했으므로 전역 객체가 바인딩됩니다.

2-3) 외부 렉시컬 환경에 대한 참조 결정

해당 함수의 정의가 평가된 시점에 실행중인 실행 컨텍스트의 렉시컬 환경의 참조가 할당됩니다.

foo함수는 전역에 정의된 전역함수 이고, 전역 코드 평가 시점에 평가 되었기 때문에 평가 시점의 실행중인 실행 컨텍스트는 전역 실행 컨텍스트입니다.

자바스크립트는 함수를 어디서 호출 했는지가 아닌 어디서 정의 했는지에 따라 상위 스코프를 결정한다. 그리고 함수 객체는 자신이 정의된 스코프, 즉 상위 스코프를 기억한다.

자바스크립트는 함수의 상위 스코프를 객체의 내부 슬롯 [[Environment]]에 저장합니다.

함수 렉시컬 환경의 외부 렉시컬 환경에 대한 참조에 할당되는 것은

바로 상위 스코프를 가리키는 함수 객체의 내부 슬롯 [[Environment]]에 저장된 렉시컬 환경의 참조입니다.

함수 코드의 실행

함수 코드 평가가 끝나면 런타임이 실행되어 순차적으로 모든 코드가 실행됩니다.

1. console 식별자 검색

cosole.log 메서드를 호출하기 위해 console을 스코프 체인을 통해 검색합니다.

console 식별자는 객체 환경 레코드의 BingObject를 통해 전역 객체에서 찾을 수 있습니다.

2. log 메서드 검색

이제 console식별자에 바인딩 된 객체에서 log메서드를 검색합니다.

3. 표현식 a + b + x + y + z의 평가

각 변수들을 스코프체인을 통해 검색하고, 참조합니다.

a는 foo 함수 렉시컬 환경에서,

b와 z는 bar함수 렉시컬 환경에서,

x와 y는 foo 함수 렉시컬 환경에서 검색됩니다.

함수 코드 실행 종료

더 이상 실행할 코드가 없다면 함수 코드의 실행이 종료됩니다.

이때 스택에서 해당 함수 실행 컨텍스트가 팝되어 제거되고 그 다음 스택에 최상위 실행 컨텍스트가 실행중인 실행 컨텍스트가 됩니다.

실행 컨텍스트가 스택에서 제거되었다고, 바로 함수 렉시컬 환경까지 소멸되는 것은 아닙니다.

렉시컬 환경은 실행 컨텍스트에 의해 참조 되지만 독립적인 객체이기 때문에 함수 렉시컬 환경이 더이상 참조되지 않을 때 까지 소멸하지 않습니다.

전역 코드 실행 종료

모든 전역 코드의 실행이 종료된 후 전역 실행 컨텍스트도 종료되어 실행 컨텍스트 스택에서 팝되어 실행 컨텍스트 스택에는 아무것도 남지 않게 됩니다.

실행 컨텍스트와 블록 레벨 스코프

let, const 키워드로 선언한 변수는 모든 코드 블록을 지역 스코프로 인정하는 블록레벨 스코프를 따릅니다.

let x = 1;

if (true) {
  let x = 10;
  console.log(x); // 10
}

console.log(x); // 1

위 코드에서 조건문이 실행되면 선언적 환경 레코드를 갖는 렉시컬 환경을 새롭게 생성하여 기존의 전역 렉시컬 환경을 교체합니다.

코드 블록의 실행이 종료되면 원래의 렉시컬 환경으로 되돌립니다.

이는 모든 블록문에 적용됩니다.

for문의 변수 선언문에 let키워드를 사용하면, 반복해서 실행될 때마다 코드 블록을 위한 새로운 렉시컬 환경을 만듭니다.

만약 for문의 코드 블록 내에서 정의된 함수가 있다면 이 함수의 상위 스코프는 for문의 코드 블록이 생성한 렉시컬 환경입니다.

이때 함수의 상위 스코프는 for문의 코드블록이 반복해서 실행될 때마다 식별자의 값을 유지해야합니다.

이를 위해 for문의 코드 블록이 반복해서 실행될 때마다 독립적인 렉시컬 환경을 생성하여 식별자의 값을 유지합니다.

이는 나중에 나오는 클로져에서 더 다루어 보도록 하죠!

🧹정리하기

후… 너무 어렵습니다…. 실행 컨텍스트

그래도 글을 쓰려고 3회독하고, 여러가지 강의도 보다 보니 어느정도 이해가 가네요.

이제 실행 컨텍스트 단어가 나와도 두렵지 않습니다!

그럼이만…

React를 어찌저찌 클론해보고, next.js에 혹한 뒤에 블로그 개발에 흥미가 생긴 나는 아무런 지식 없이 블로그를 만들기로 했다.

다른 분들의 블로그 코드를 참조하고, 기본적인 페이지 생성은 next.js 블로그 라고 검색 했을 때 가장 먼저 발견한 Next.js로 나만의 블로그 만들기 with 정적 생성 을 토대로 시작했다.

이대로 포스트를 만들다 보니 여타 다른 블로그나 벨로그에도 있는 시리즈 별로 글을 나누는 것이 너무 부러웠다.

글을 개발, 코딩테스트 연습, 일상, 회고 등등 나중에 확장하다 보면 분명 글을 파일별로 나누고 싶어질 것이기 때문에 미리 만들어 놓고 싶어졌다.

(이걸 하면서, 버그가 너무 많이 생겼다.....)

과정

시리즈를 나눈 코드는 bepyan님의 코드를 참고했다!

우리는 마크다운 파일을 contentlayer를 이용해서 html파일에 빌드한다.

이때 contentlayer에서 파일을 가져오는 방법은 config에서 설정한 디랙토리의 mdx파일을 불러오는 방식인데,

각 파일은 contentlayer에 의해 allPosts 배열에 json형식으로 저장되고, 해당 json파일에는 폴더 디랙토리가 나타나 있어 동적라우팅을 적용하기 편리했다.

내 블로그의 포스트를 나타내는 파일 경로는 다음과 같다.

pages
|
|-> posts
    |-> [...slugs].jsx
    |->[slug].jsx
    |->index.jsx

index.js

posts 폴더의 가장 기본 경로이다. 이 페이지에는 모든 시리즈를 보여주는 페이지를 만들 것이다.

[slug].jsx

그렇다 동적라우팅 나는 이녀석 때매 애를 무지하게 먹었다.... 이 파일에는 각 시리즈에 있는 글 목록을 나타내는 페이지를 만들 것이다.

[...slugs].jsx

이 파일은 각각 글에 대한 페이지이다.

자자 나도 [slug]와 **[...slugs] **때매 애를 무지하게 먹었다. (버그의 대부분이 이 부분)

여기서 나는 블로그 웹사이트 답게 서버에서 페이지를 정적으로 만들 것이다. (그 유명한 ssg)

시리즈의 라우트 경로 -> posts/시리즈 이름 포스트의 라우트 경로 -> posts/시리즈 이름/포스트 이름 이런 형식으로 정적 페이지가 미리 생성되고 랜더링 될텐데...

여기서 문제는 [...slugs]에 있다. 이 친구를 이용해서 slugs를 "/"단위로 분리해서 배열에 저장해서 포스트를 정적 페이지로 만들텐데, 이렇게 되면 "posts/시리즈 이름" 페이지는 [slug].jsx에서도 생성되고 [...slugs].jsx에서도 생성되어 빌드시 오류가 난다... (그래서 나는 [...slugs].jsx에서 index.mdx파일을 제외하는 방식을 이용했다.)

시작!

글을 html페이지에 불러오는 건 참고자료에 나와있는 블로그와 구글에 검색하면 여러 포스트 들이 많으니 생략 하겠다.

[...slugs].jsx

export default ({ post }) => {
    return (
        <>
            <article className="post">
                <div className="log">
                    <MarkdownPost post={post.body.code} />
                </div>
            </article>
        </>
    );
};

export const getStaticPaths = async () => {
    return {
        paths: allPosts.filter((i) => !i._raw.sourceFilePath.includes("/index.mdx")).map((p) => ({ params: { slugs: p._raw.flattenedPath.split("/") } })),
        fallback: "blocking",
    };
};

export const getStaticProps = async ({ params }) => {
    const post = allPosts.find((p) => p._raw.flattenedPath === params.slugs.join("/"));
    return {
        props: {
            post,
        },
    };
};

(import와 같은 코드는 생략하도록 하자!)

I

먼저 개시글 파일을 보면, getStaticPaths를 이용해서 route path를 빌드시점에 만들어준다. 이때, 아까 말한 두 파일에서 동일한 라우팅이 발생하는 index.mdx파일을 제외하고 만들어 주기 위해서, allPosts배열에서 index.mdx를 포함하는 파일을 제거해 주었다.

제거해 준 각 아이템들은 params로 getStaticProps에 넘겨주었다.

II

그 이후 getStaticProps을 이용해서 getStaticPaths에게 받은 파라미터와 동일한 path를 가진 파일을 찾아서 컴포넌트에 post prop을 보내주었다.

이때 slugs는 각 파라미터를 "/"기준으로 나누어 저장해둔 배열이기 때문에 "/"로 묶은 문자열로 치환해준다.

[slug].jsx

이제 각 시리즈를 페이지를 만들어보자

export default ({ collection }) => {
    console.log(collection);
    return (
        <div>
            {collection.map((item) => {
                return (
                    <Link href={`/posts/${item._raw.flattenedPath}`}>
                        <h1>{item.title}</h1>
                        <h1>{item.description}</h1>
                        <h1>{item.date}</h1>
                        <br />
                    </Link>
                );
            })}
        </div>
    );
};

export const getStaticPaths = async () => {
    return {
        paths: allPosts.map((p) => ({ params: { slug: p._raw.flattenedPath.split("/")[0] } })),
        fallback: false,
    };
};

export const getStaticProps = async ({ params }) => {
    // const collection = getCollactionItem(params.slug);
    const collection = allPosts.filter((i) => !i._raw.sourceFilePath.includes("/index.mdx")).filter((i) => i._raw.flattenedPath.includes(params.slug));
    return {
        props: {
            collection,
        },
    };
};

여기서 getStaticPaths를 보면 아까 그녀석과 조금 다를 것이다. [slug]는 [...slug]와는 다르게 배열이 아닌 문자열 하나만 받는다.

따라서 파일에 있는 경로는 "시리즈 이름 / 게시물 이름"이므로 경로를 "/"로 분리한 배열 중 첫번째가 시리즈의 route가 된다.

getStaticPaths에게 받은 params를 getStaticProps는 각 시리즈의 정보 저장 파일인 index.mdx를 제외하고 collection prop을 컴포넌트에 보내준다.

index.jsx

export default ({ posts }) => {
    return (
        <>
            <div className="p-[2em]">
                {posts.map((post) => {
                    return (
                        <BlogPost
                            key={post._id}
                            date={post.date}
                            title={post.title}
                            des={post.description}
                            slug={post._raw.flattenedPath}
                        />
                    );
                })}
            </div>
        </>
    );
};

export const getStaticProps = async () => {
    //allPosts => 해당 경로의 mdx파일을 배열에 담아서 전송해줌!
    const posts = allPosts.filter((i) => i._raw.sourceFilePath.includes("/index.mdx"));

    return {
        props: {
            posts,
        },
    };
};

자 이제 시리즈 리스트를 보여주는 posts의 가장 메인 페이지이다.

여기는 쉽다. 페이지가 하나이기 때문에 getStaticPaths를 이용할 필요없고, getStaticProps는 아까 [slug].jsx에서는 index.mdx파일만 분리해줬다면, 여기서는 index.mdx파일만 불러와 주면된다!

완성!

나는 이를 시도하는 도중에 갖은 버그를 만났다. 아까 언급한 동일한 페이지가 라우팅이 2번 되는 버그라던지, 빌드한 뒤에 페이지가 클라이언트 사이트 에러가 난다던지....

역시 부족한 지식덕분에 두들겨 맞으면서 만드는 중이다. css도 없고 허접한 코드지만, 함수화 하고 컴포넌트를 분리해서 수정하고, 만들 생각이다.

그래도 시리즈를 나누어 놓으니 너무 뿌듯하고 행복하다!

다음에는 목차와 스크롤을 만들어 보고 싶은데..... 이거도 시도해 보니 쉽지 않다! 완성하면 공유해 보도록 하겠다...

참고 자료

Next.js로 나만의 블로그 만들기 with 정적 생성 - miryang.dev

bepyan

후... 우당탕탕 작업을 완료했다..

아직 css도 없고 그냥 텅 빈 글쪼가리 전달하는 웹페이지이지만

또.. 물론 계속 작업하면서 오류가 계속 나겠지만,,,,,,,,

버그를 수정하면서 성장하고 배우자 시작한 next.js이니까 공부하는셈 치자!

계속해서 업데이트한 내용들과 오류난 부분들에 대해서 velog와 내블로그에 공유할 예정이다.

이건 또 뭔가... 클라이언트 사이드에서 문제가 발생했단다... 일단 황급히 찾아보자

나는 정말 빌드 했을 때 버그나는게 끔찍한거 같다... (내컴퓨터는 잘돌아가는데 왜! 왜?!!1!!!!!!!!!!!)

해결?

는 해결 못했다... 오류는 서버에서 프리랜더링 한 결과랑 클라이언트 랜더링 결과가 다르다곤 하는데... 제대로 공부안 하고 그냥 무작정 시작한 결과니까 받아들여야지...

그래서 test파일에 이전 커밋으로 복귀한 다음 함수나 컴포넌트 분리 없이 새로만들어서 빌드하니 해결되었다... (해결이라기 보다는 회피....)

여기에서 조금 씩 커밋하면서 문제점을 찾아보자!

2023 - 05 - 14

오늘 다시 같은 오류가 나서 봤더니,, 대충 느낌이 왔다. 내가 getStaticProps를 사용한 페이지에 다른 변수를 이용해서 데이터를 랜더링 할때 생기는 문제 같은데...

역시 공부가 부족하다 더욱 공부해서 다음과 같은 실수를 줄이자!

2023 - 05 - 15

인고의 시간과 검색 끝에 알게 되었다. 나의 경우에는 클라이언트 오류가 json.parse에러였는데, next.js가 자체적으로 코드를 줄이던 중 파일이깨져서 오류가 나는 거였나보다...

next.config.js 에서 swcMinifty를 false로 하니까 눈물나게도 성공이다...

[18:38:25.322] error - Conflicting paths returned from getStaticPaths, paths must be unique per page.
[18:38:25.323] See more info here: https://nextjs.org/docs/messages/conflicting-ssg-paths
[18:38:25.323] 
[18:38:25.324] path: "/posts/JS" from page: "/posts/[...slugs]" conflicts with path: "/posts/JS" from page: "/posts/[slug]" 
[18:38:25.324] path: "/posts/life" from page: "/posts/[...slugs]" conflicts with path: "/posts/life" from page: "/posts/[slug]" 
[18:38:25.324] 
[18:38:25.361] Error: Command "next build" exited with 1
[18:38:26.034] Deployment completed
[18:38:25.648] BUILD_UTILS_SPAWN_1: Command "next build" exited with 1

자 버그 내용을 보자면, 내가 작성한 동적라우팅 두 곳에서 동일한 주소를 호출하는게 문제였다.

해결

https://nextjs.org/docs/messages/conflicting-ssg-paths

앞이 까마득 했지만 역시 갓갓 공식문서의 도움으로

현제 내 폴더의 구조는 posts | | ->[slug] |-> [...slugs]

요로코롬이라 /posts/a라고 하면 두 폴더 동시에 라우팅?이 되는 문제였다.

그래서 두번째 폴더에서 해당되는 파일을 제거해 줬다!

The React Framework for the Web 일부 세계 최대 기업에서 사용하는 Next.js를 사용하면 최신 React 기능을 확장하고 가장 빠른 빌드를 위한 강력한 Rust 기반 JavaScript 도구를 통합하여 전체 스택 웹 애플리케이션을 만들 수 있습니다.

Next JS는 프론트와 백엔드를 쉽게 설계해주는(?) 웹 프레임워크 입니다.

사실 저도 next.js 잘모르고... 심지어 react에 발을 들인지도 얼마 되지 않았습니다.

그냥 막연하게 최신기술을 사용해서 나만의 프로젝트를 만들고 싶었는데, 그런 저의 향수를 자극한 것이 next.js와 블로그 만들기 였습니다.

여러가지 아티클도 많이 존재하고, 차근차근 따라쳐보고 배우면서 익숙해질 생각입니다!

어느정도 블로그의 틀이 잡히면, velog뿐 아니라 저만의 블로그에도 글을 올리겠습니다!

👋

너무 재밌었습니다!

코코아톡 클론코딩

처음에 html, css 기초강의를 들을땐, "이미 알고 있는 내용을 내가 유료로 들을 필요가 있을까?"라는 생각을 했습니다.

하지만 오산이였습니다. 니코쌤이 작성하는 코드를 보면서, 어떻게 코드를 관리하고 classname을 관리하는지 알 수 있었고, 지금까지 제가 얼마나 스파게티 코드를 짜는지 실감했습니다.

결과물을 완성하고 니코쌤이 주시는 숙제들을 하나씩 해가면서, 기본적인 css 레이아웃과 html, css파일을 어떻게 분리해서 작성하는지 배울 수 있는 좋은 시간이었습니다.

바닐라 JS로 크롬 앱 만들기

일단 저에겐 꽤 쉬웠습니다. 워낙 Javascript를 많이 접하기도 했고, 기본적인 지식이 어느정도 있는 상태여서 이론은 어렵지 않았습니다.

이 강의에서는 니코쌤이 html, css, js를 어떤 식으로 동작시키는지, querySelector를 사용해서 class를 이용해 css타입을 바꾸는 방식이나. Date.now()를 이용해 li에 id를 주는 방식을 알게 되었습니다.

끝으로

역시 안다고 생각하는 게 가장 위험 한 것 같습니다. 다시 볼수록 새로운 걸 얻어가는 유익한 시간이었고, 다음 강의가 너무 기대됩니다. 저는 그럼 다음강의 들으러 이만.... 🤣

멋쟁이 사자처럼 11기

멋쟁이 사자처럼 11기에 붙었습니다.

휴학생이라 학교 동아리 참여에 고민이 많았는데, 기왕 학교쉬면서 프론트엔드 공부에 전념하는 김에 테크관련 연합동아리 중에서 웹에 가장 중심을 둔 멋쟁이 사자처럼에 지원하게 되었습니다.

아기사자가 된 김에 열심히 세션도 듣고, 오프라인 행사도 참여하고, 빨리 중앙 해커톤도 하고 싶네요!