<h1>ARIA</h1><ul class="tight" data-tight="true"><li>Accessbile Rich Internet Applications 의 약자</li><li>몸이 불편한 분들이 웹 서비스 이용이 수월하도록 여러 방식을 정의해놓은 role과 attribute의 집합</li><li>자바스크립트로 만든 웹 서비스에 최적</li><li>MDN 문서에 따르면 1백만개 웹사이트를 조사한 결과 34.2%가 ARIA를 잘못 사용하여 에러가 발생. ARIA는 웹 접근성을 향상시키기 위해 존재하지만 이렇게 에러를 내뿜는 경우에는 오히려 안쓰는 것보다 더 구림<ul class="tight" data-tight="true"><li><a target="_blank" rel="noopener noreferrer nofollow" href="https://webaim.org/projects/million/#aria">https://webaim.org/projects/million/#aria</a></li></ul></li></ul><h2>role</h2><pre spellcheck="false"><code>&lt;div
 id="percent-loaded"
 role="progressbar"
 aria-valuenow="75"
 aria-valuemin="0"
 aria-valuemax="100"&gt;&lt;/div&gt;</code></pre><ul class="tight" data-tight="true"><li>위 코드에서 <code spellcheck="false">div</code> 태그는 아무런 의미를 가지지 않음</li><li><code spellcheck="false">role</code> 을 이용하여 해당 태그가 웹페이지에서 어떤 기능을 하는지 알려줌</li><li><code spellcheck="false">role</code> 을 배웠으니 주석쓰는 대신 이 <code spellcheck="false">role</code> 로 웹페이지 코드 가독성을 향상시킬 수 있지 않겠나 싶음</li></ul><h2>aria-*</h2><pre spellcheck="false"><code>&lt;div
 id="percent-loaded"
 role="progressbar"
 aria-valuenow="75"
 aria-valuemin="0"
 aria-valuemax="100"&gt;&lt;/div&gt;</code></pre><ul class="tight" data-tight="true"><li><code spellcheck="false">aria</code> 어트리뷰트는 동적으로 설정 가능</li></ul><pre spellcheck="false"><code>const progressBar = document.getElementById("percent-loaded");
progressBar.setAttribute("role", "progressbar");
progressBar.setAttribute("aria-valuemin", 0);
progressBar.setAttribute("aria-valuemax", 100);function updateProgress(percentComplete) {
progressBar.setAttribute("aria-valuenow", percentComplete);
}</code></pre><ul class="tight" data-tight="true"><li>위 코드는 동적으로 설정하는 것을 순수 자바스크립트 코드로 구현해놓은 것인데 리액트나 넥스트로 구현하면 <code spellcheck="false">useRef</code> 훅을 사용하면 되지 않을까 싶음</li><li>MDN에서는 웹접근성 구현에 대해 assistive technology의 지원을 받아야하는 사람이든 아닌 사람이든 모두 동등하게 웹 페이지를 이용할 수 있어야 한다고 적혀있음</li></ul><pre spellcheck="false"><code class="language-markdown">&lt;progress id="percent-loaded" value="75" max="100"&gt;
75%
&lt;/progress&gt;</code></pre><ul class="tight" data-tight="true"><li><code spellcheck="false">progress</code> 라는 요소가 이미 존재하고 있으므로 <code spellcheck="false">div</code> 를 사용하여 <code spellcheck="false">role</code> 을 설정하기 보다 그냥 <code spellcheck="false">progress</code> 를 사용하는게 훨씬 간단</li><li><code spellcheck="false">min</code> 이 없는 이유는 항상 0이기 때문</li></ul><h2>시맨틱 요소</h2><ul class="tight" data-tight="true"><li>몸이 불편한 분들은 자신이 이용하는 assistive technology나 관련된 것들을 업데이트 하기를 두려워하는 경향이 있다고 함</li><li>이유는 업데이트 했을 경우에 지원되던 게 안될 수도 있기 때문</li><li>그래서 강조되는 게 가능하면 시맨틱 요소를 이용하여 웹페이지를 구성하라고 함</li><li>웹접근성은 실제 assistive technology를 통해 테스트할 것을 강조</li><li>브라우저를 통한 테스트는 불완전하기 때문</li></ul><h2>ESLint</h2><ul class="tight" data-tight="true"><li>eslint-plugin-jsx-a11y: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.npmjs.com/package/eslint-plugin-jsx-a11y">https://www.npmjs.com/package/eslint-plugin-jsx-a11y</a></li><li>리액트 앱의 JSX의 웹 접근성을 정적 평가하는 플러그인</li><li><code spellcheck="false">aria-*</code> , <code spellcheck="false">role</code> 혹은 <code spellcheck="false">img</code> 태그의 <code spellcheck="false">alt</code> 값을 검사</li><li>실제 assistive technology를 통한 테스트를 한게 아니기 때문에 이 플러그인을 사용해도 실제 assistive technology 를 통해 테스트하라고 함</li></ul><h2>웹 접근성 관련 자료</h2><ul class="tight" data-tight="true"><li>WCAG: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.w3.org/TR/WCAG22/">https://www.w3.org/TR/WCAG22/</a></li><li>WebAIM: <a target="_blank" rel="noopener noreferrer nofollow" href="https://webaim.org/standards/wcag/checklist">https://webaim.org/standards/wcag/checklist</a></li><li>a11y: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.a11yproject.com/">https://www.a11yproject.com/</a></li></ul>

ARIAAccessbile Rich Internet Applications 의 약자몸이 불편한 분들이 웹 서비스 이용이 수월하도록 여러 방식을 정의해놓은 role과 attribute의 집합자바스크립트로 만든 웹 서비스에 최적MDN 문서에 따르면 1백만개 웹사이트를 조사한 결과 34.2%가 ARIA를 잘못 사용하여 에러가 발생. ARIA는 웹 접근성을 향상시

NEXT 공식문서 읽기 D2

팬텀 타입(Phantom Type)은 Haskell, Rust와 같은 언어에서 사용하는 기술이다. 팬텀 타입은 타입 매개변수(Generics)의 역할을 하는데, 실제 런타임에는 사용되지 않는 타입을 의미한다. 코드에서 타입 안전성을 강화하기 위해 사용된다......위와 같은 내용의 글들을 많이 읽었다. Typescript 사용자로써, 팬텀 타입에 대해 공부하려고 할 때마다 이게 무슨 뜻인지 이해가 잘 안 갔었는데, 공부하고 정리해본 내용을 이해하기 쉽게 예시와 함께 소개해보려고 한다.<h1>TypeScript는 구조적 타이핑을 하는 언어다</h1>구조적 타이핑이 무엇인지 알지 못하는 타 언어 사용자를 위해 짧은 설명을 하고 넘어가자. 구조적 타이핑은 클래스의 이름 따위가 아니라, '객체의 형태와 구조'를 타입의 중요한 요소로 여기는 방식을 의미한다.<pre spellcheck="false"><code class="language-typescript">class Human {
 name: string;
 age: number;
}

class Animal {
 name: string;
 age: number;
}

const member = {
 name: "Octoping",
 age: 25,
};

// 이 세 가지 객체 or 클래스의 타입은 사실상 전부 같다

function sayName(x: Human) {
 console.log(x.name);
}

// 전부 타입 문제 없이 작동한다
sayName(new Human("Octoping", 25));
sayName(new Animal("Pig", 3));
sayName(member);</code></pre>다음은 자바 같은 언어라면 생각도 못할 일이다. Human 클래스도, Animal 클래스도, member라는 변수도 <code spellcheck="false">string</code> 타입의 name과 <code spellcheck="false">number</code> 타입의 age를 가지므로 전부 같은 타입으로 인지하는 것이다.물론 객체를 클래스를 사용하지 않고도 바로 만들 수 있다는 자바스크립트의 특징 때문에 어쩌면 당연할 수 밖에 없다. 그리고 이 특성으로 인해 Typescript는 큰 생산성을 얻게 되면서 동시에 한 가지 단점을 얻게 되는데.<h2>문제 제기</h2>구조적 타이핑으로 인해 조금 불편을 겪을 수 있는 에피소드를 소개해보고자 한다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number;
type Won = number;

// 십만원을 가진 나
const octopingMoney: Won = 100000;
const friendMoney: Won = 50000;

// 달러를 더하는 함수
function addDollar(a: Dollar, b: Dollar): Dollar {
 return a + b;
}

// 🥵
const result = addDollar(octopingMoney, friendMoney);</code></pre><code spellcheck="false">Dollar</code> 와 <code spellcheck="false">Won</code>은 둘 다 숫자지만, 단위가 다르므로 서로 더하면 안된다. 하지만 구조적 타이핑 덕분에 이런 놀라운 일이 가능해진다.이런 불편함을 어떻게 하면 좋을까?도메인 주도 개발에서 이야기하는 값 객체라는 걸 이용해보면 좋을 것 같다.<h2>값 객체를 다루기 어렵다</h2><pre spellcheck="false"><code class="language-java">class Member {
 private Email email;
 private Password password;
 // ...
}

class Email {
 private String value;

 public Email(String value) {
 if (!value.contains("@")) {
 throw new IllegalArgumentException("이메일 주소가 올바르지 않아요");
 }
 
 this.value = value;
 }
}

class Password {
 private String value;

 public Password(String value) {
 if (value.length() &lt; 8) {
 throw new IllegalArgumentException("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}</code></pre>다음은 Java를 이용해서 값 객체 (VO)를 사용한 예제다. <code spellcheck="false">Member</code>에 이메일과 비밀번호를 그냥 String으로 저장하는 대신, 각각을 클래스로 묶어서 자기 자신이 값을 지님과 동시에 유효성 검사를 할 수 있도록 했다. 자신이 자기 자신을 그 자체로 소개할 수 있도록 하는 것. 그것이 도메인 주도 개발에서 이야기하는 값 객체이다.<pre spellcheck="false"><code class="language-typescript">class Member {
 constructor(
 private readonly email: Email,
 private readonly password: Password
 ) {}
}

class Email {
 value: string;

 constructor(value: string) {
 if (!value.includes("@")) {
 throw new Error("이메일 주소가 올바르지 않아요");
 }

 this.value = value;
 }
}

class Password {
 value: string;

 constructor(value: string) {
 if (value.length &lt; 8) {
 throw new Error("비밀번호가 너무 짧아요");
 }

 this.value = value;
 }
}

// 순서가 틀렸지만 당연히 에러가 나지 않는다!
const member = new Member(new Password("email"), new Email("password"));</code></pre>그런데 아뿔싸! 다음과 같은 코드를 Typescript에서 작성한다면 조금의 문제가 생겨버린다. 바로 <code spellcheck="false">Email</code>과 <code spellcheck="false">Password</code>의 시그니처가 똑같다는 것. 멤버 변수 타입 똑같고.. 메소드가 없는 것도 똑같은 것 같다. 당연히 에러가 나지 않겠지?<blockquote>이 문제에 대해서 진지하게 이야기해보면. 일단 첫 번째: 두 객체의 멤버 변수 값을 다르게 하면 된다. 그것이 구조적 타이핑이니까.. 하지만 서로 다른 두 클래스가 각자의 멤버 변수 이름에 강결합되는 프로그래밍을 유도하게 되는 것 같다. 두 번째: value를 private으로 만들면 된다.</blockquote><h2>문제 갈무리</h2>정리해보자. <code spellcheck="false">Dollar</code>와 <code spellcheck="false">Won</code>을 그냥 number로써 동일하게 표현하면 타입스크립트는 이 둘을 완전히 같은 타입으로 인지하여 똑같이 다뤄버리게 된다.이를 위해 값 객체를 사용해보려 하니 이 또한 멤버 변수의 이름을 신경써야 하니 나름의 어려움이 있다.마지막으로, 그냥 타입을 number로 쓸 때에 비해 객체를 생성해야 하니 메모리도 더 잡아먹게 된다. 객체지향이 원래 그런 것이다만은..<img src="https://image.until.blog/octoping/article/1723552083845" alt="until-1228">이런 상황을 어떻게 하면 좋을까?<h1>Phantom Type</h1>서론이 길었다. 팬텀 타입을 이용해보면 이런 문제를 해결해볼만한 실마리를 잡을 수 있을지도 모른다. 팬텀 타입을 내 나름대로 간단히 설명해보면 이렇다.<blockquote>형태는 같지만 실제로는 서로 다른 타입을 구분하기 위해, 실제로는 존재하지 않는 타입을 이용하는 것</blockquote><h2>코드로 살펴보기</h2><pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };

const myDollar = 2 as Dollar;
const myWon = 1000 as Won;</code></pre>달러와 원을 그냥 number가 아니라, <code spellcheck="false">number</code>이면서 <code spellcheck="false">{ __unit: string }</code> 인 녀석으로 정의하는 것이다.물론 이 뒷 부분은 실제 런타임에는 전혀 존재하지 않는 녀석이다. (타입스크립트에서 타입은 컴파일 단계에서 사라지므로 런타임에는 더더욱 존재하지 않게 된다)하지만 타입스크립트에게 억지로 이것이 존재한다고 함으로써 이 둘을 마냥 서로 같은 <code spellcheck="false">number</code>가 아니도록 만드는 것이다.<pre spellcheck="false"><code class="language-typescript">type Dollar = number &amp; { __unit: "Dollar" };
type Won = number &amp; { __unit: "Won" };


function addDollar(a: Dollar, b: Dollar): Dollar {
 return (a + b) as Dollar;
}

function dollarToWon(dollar: Dollar): Won {
 return (dollar * 1300) as Won;
}


const myDollar = 2 as Dollar;
const myWon = 1000 as Won;


const addedDollar = addDollar(myDollar, myDollar);
const convertedWon = dollarToWon(myDollar);

// 에러!
addedDollar(myWon, myWon);

// 에러!
convertedWon(myDollar);</code></pre>그렇다면 이렇게, 사실은 서로 같은 number를 서로 다른 타입처럼 사용할 수 있다.<h2>실생활 예제</h2>그럼 이걸 실생활에 어디다 어떻게 쓰라고? 팬텀 타입에 대해 다부지게 설명해주신 이 글에서 소개해준 예제를 조금 가공해서 빌려와볼까 싶다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9">https://dev.to/busypeoples/notes-on-typescript-phantom-types-kg9</a><pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload: MemberJoinPayload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 };
 
 // validate를 해야 하지만 깜빡했다~~!!!!

 callApi(payload);
};

function validateData(data: MemberJoinPayload) {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }
}

async function callApi(data: MemberJoinPayload) {
 // 대충 api 호출하는 코드
}
</code></pre>회원가입 폼에서 입력 받은 내용을 validate를 거친 후, 성공했다면 회원가입 api 호출 함수를 쏘는 로직을 떠올려보자.여기서 validate를 까먹어서 검증을 안 거치고 api를 호출하도록 코드를 작성하더라도 타입 상으로는 아무~ 문제가 없이 작동하기 때문에 내가 뭘 잘못했는지 생각 못하고 넘어갈 수 있다.여기서 팬텀 타입을 적용해보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = MemberJoinPayload &amp; { _type: "Unvalidated" };
type ValidatedData = MemberJoinPayload &amp; { _type: "Validated" };


export const onSubmit = (e: FormEvent&lt;HTMLFormElement&gt;) =&gt; {
 const payload = {
 name: e.currentTarget.name,
 age: e.currentTarget.age,
 } as UnvalidatedData;

 const validatedData: ValidatedData = validateData(payload);
 
 callApi(validatedData);
};

function validateData(data: UnvalidatedData): ValidatedData {
 if (data.age &lt; 0) {
 throw new Error("나이가 음수에요");
 }

 return { name: data.name, age: data.age } as ValidatedData;
 // return data as unknown as ValidatedData; 사실 이게 더 깔끔할지도
}

async function callApi(data: ValidatedData) {
 // 대충 api 호출하는 코드
}</code></pre>폼을 입력 받아 실행되는 <code spellcheck="false">onSubmit</code>에서 <code spellcheck="false">UnvalidatedData</code> 타입의 payload를 생성한다. 물론 이 변수로는 <code spellcheck="false">callApi</code> 함수를 실행할 수 없다.따라서 그 후 validate를 실행하면 <code spellcheck="false">ValidatedData</code> 타입의 결과를 받게 되니 이제서야 api를 호출할 수 있게 되는 것이다.실제 객체의 값은 전혀 변하지 않았고, <code spellcheck="false">__type</code>이니 뭐니 하는 것은 그 어디에도 존재하지 않았지만, 있는 타입이라고 타입스크립트에게 공갈을 하여 똑같은 타입의 서브 타입을 두 개를 만들어낸 것이다.<h2>팬텀 타입 추상화하기</h2>이 쯤 봤으면 팬텀 타입을 공용적으로 쓸 수 있게 추상화해볼 수 있겠다는 생각이 들 것이다. <code spellcheck="false">type Data = OriginalType &amp; { __value: string }</code> 대충 이런 형태이니..<pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };</code></pre>짜잔!그럼 이걸 이용해서 다양한 팬텀 타입을 원하는 대로 만들어보자.<pre spellcheck="false"><code class="language-typescript">type MemberJoinPayload = {
 name: string;
 age: number;
};

type UnvalidatedData = PhantomType&lt;MemberJoinPayload, "Unvalidated"&gt;;
type ValidatedData = PhantomType&lt;MemberJoinPayload, "Validated"&gt;;</code></pre><pre spellcheck="false"><code class="language-typescript">type Dollar = PhantomType&lt;number, "Dollar"&gt;;
type Euro = PhantomType&lt;number, "Euro"&gt;;
type Won = PhantomType&lt;number, "Won"&gt;;</code></pre><h2>ChatGPT가 추천하는 팬텀 타입 유망 직종</h2>다음은 ChatGPT에게 직접 팬텀 타입을 어디에 써보면 좋겠을지 물어보아 나온 결과인데 공유해본다.<ul><li>데이터베이스 ID 타입 구분<ul><li>서로 다른 테이블에서 사용되는 ID 값을 혼동하지 않도록 팬텀 타입을 사용할 수 있습니다</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type UserId = PhantomType&lt;number, "User"&gt;;
type OrderId = PhantomType&lt;number, "Order"&gt;;

function getUserById(userId: UserId) {
 // 사용자 조회 로직
}

function getOrderById(orderId: OrderId) {
 // 주문 조회 로직
}

const userId: UserId = 1 as UserId;
const orderId: OrderId = 1 as OrderId;

// 올바른 사용
getUserById(userId);
getOrderById(orderId);

// 잘못된 사용 방지
// getUserById(orderId);</code></pre><ul><li>도메인 모델의 상태 구분<ul><li>상태 변화에 따른 도메인 모델의 상태를 팬텀 타입으로 구분하여, 잘못된 상태에서 발생할 수 있는 동작을 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type Draft = { __status: 'Draft' };
type Published = { __status: 'Published' };

type Document&lt;Status&gt; = {
 content: string;
 status: Status;
};

function publish(doc: Document&lt;Draft&gt;): Document&lt;Published&gt; {
 return { ...doc, status: { __status: 'Published' } };
}

const draftDoc: Document&lt;Draft&gt; = {
 content: 'Draft content',
 status: { __status: 'Draft' }
};

// 올바른 상태 전환
const publishedDoc = publish(draftDoc);

// 잘못된 상태 전환 방지
// publish(publishedDoc); // 이미 게시된 문서는 다시 게시할 수 없음</code></pre>개인적으로 이건 비즈니스 로직에 관련된 건데 그냥 진짜 타입으로 관리해야 좋을 것 같다는 생각이다.<ul><li>서로 다른 API 엔드포인트에 안전하게 호출<ul><li>API 요청 시, 서로 다른 API 엔드포인트에 같은 데이터 타입을 사용하더라도, 요청 경로를 팬텀 타입으로 구분하여 잘못된 경로로 요청을 보내는 실수를 방지할 수 있습니다.</li></ul></li></ul><pre spellcheck="false"><code class="language-typescript">type PhantomType&lt;Data, Type = never&gt; = Data &amp; { _type: Type };

type ApiUri = string;
type OrderServerUri = PhantomType&lt;ApiUri, "주문"&gt;;
type UserServerUri = PhantomType&lt;ApiUri, "유저"&gt;;

async function fetchOrderList(uri: OrderServerUri, payload: any) {
 return fetch(uri, payload);
}

fetchOrderList("/api/order" as OrderServerUri, { userId: 1 });
fetchOrderList("/api/order" as UserServerUri, { userId: 1 }); // Error</code></pre>