Property와 Attribute
HTML
attribute란, html 문서에서 elements에 추가적인 정보를 넣을 때 사용되는 요소로 밑의 코드에서 div는 element(요소)이고 class는 attribute(속성)이 되며 'my-class'는 class attribute의 value(값)이 됨
<div class="my-class"></div>property란, html DOM 안에서 attribute를 가리키는 표현
차이점은?
attribute는 정적으로 변하지 않고 property는 동적으로 그 값이 변할 수 있다는 것을 내포하고 있음.
=> attribute는 html 문서 안에서의 정적인(바뀌지 않는) 속성 그 자체를 의미하고, property는 html DOM 안에서 동적인(바뀌는) 속성(또는 그 값)을 의미함.
JavaScript
자바스크립트에서 프로퍼티란 키와 값으로 구성된 객체 내부의 속성을 의미함
자바스크립트 엔진은 프로퍼티를 생성할 때 프로퍼티 어트리뷰트를 기본값으로 자동 정의함.
프로퍼티 어트리뷰트를 이해하기 위해 먼저 내부 슬롯과 내부 메서드의 개념에 대해 알아야 함. 둘은 자바스크립트 엔진의 구현 알고리즘을 설명하기 위해 ECMAScript 사양에서 사용하는 의사 프로퍼티와 의사 메서드다.
모든 객체는 [Prototype]]라는 내부 슬롯을 가짐. 원칙적으로 직접 접근할 수 없지만 _proto__ 통해 간접적으로 접근할 수 있음
const o = {};
o.[[Prototype]] // -> Uncaught SyntaxError
o.__proto__ // -> Object.prototype프로퍼티의 상태란
- 프로퍼티의 값
[[Value]] - 값의 갱신 가능 여부
[[Writable]] - 열거 가능 여부
[[Enumerable]] - 재정의 가능 여부
[[Configurable]]
를 말함
React.FC
전에도 한 번 본 적이 있는데 굳이 사용하지 않아도 된다고 봐서 넘어갔다. 근데 이번에 다른 사람이 작성한 코드에 저 키워드?가 있길래 궁금해서 다시 찾아봤는데 18버전 이상에서 없어졌다고 한다..ㅋ 그래도 대충 다른 블로그들 참고해서 정리하면
리액트는 타입스크립트로 작성되어 있지 않아서 커뮤니티에서 @types/react 패키지를 제공해 타이핑을 지원한다. 여기엔 FC라는 제네릭 타입이 존재하고 이를 활용해 아래와 같이 타이핑할 수 있게 도와줌
import { FC } from 'react'
type GreetingProps = {
name: string
}
const Greeting: FC<GreetingProps> = ({ name }) => {
return <h1>Hello {name}</h1>
}React TypeScript에서 FC는 그다지 best practice가 아님.
- 항상 children을 암시적으로 가지고 있음 (안티 패턴)
- defaultProps를 쓰지 못함
- 제네릭을 지원하지 않음
- 코드가 더 길어짐
깃커밋메시지
거의 대부분이 혼자 만든 프로젝트라 커밋도 제대로 안 하고 이름도 ㅇㅇ이나 끝. 이렇게.. 대충 짓거나 그래서 구글링으로 커밋컨벤션 참고해서 지킨지는 얼마 되지 않았다. 근데 취향이나 회사마다 컨벤션이 다르고.. 나도 개발하면서 이 정도로 코드 수정한 걸 rafactor 했다고 할 수 있는지 또는 컴포넌트 분리하는 부분도 어쨌든 새로운 컴포넌트를 추가한 거지만 깔끔하게 정리하고 코드질을 향상? 한 거라 add, feature, improve? 중 뭐를 써야 할지 모르겠다고 생각했다.
답은 자신이 속한 팀에 맞춰야 하는 거지만 일단 나는 취준생이니 프로젝트를 하기 전에 제대로 나만의 커밋 메시지 컨벤션을 정해야겠다고 느꼈다. 그래서 많은 글들 중에서 괜찮아 보이는 블로그를 발견했는데 참고해서 앞으로 프로젝트를 진행하면서 어떻게 커밋 메시지를 작성할지 대충 정리해 보려고 한다.
커밋 메시지 규칙
- 제목과 본문을 빈 행으로 구분
- 제목을 50글자 내로 제한
- 제목 첫 글자는 대문자로 작성
- 제목 끝에 마침표 넣지 않기
- 제목은 과겨형을 사용하지 않고 명령문을 사용
- 어떻게보다는 무엇과 왜를 설명
- 동명사보다 명사를 사용
- 관사는 사용하지 않기 (a, an, the)
- 부정문 Don't를 사용
- 오타 수정은 그냥 Fix typo
좋은 커밋 메시지를 위한 영어 단어 목록
- FEAT : 새로운 기능 추가
- DOCS : 문서 수정
- TEST : 테스트 코드 수정
- BUILD : 빌드 관련 파일 수정
- CHORE : 자잘한 수정. 빌드 업무 수정, 패키지 매니저 수정 (.gitignore)
- STYLE : 스타일 관련 기능. 코드 포맷팅 등 코드 자체의 변경이 없는 경우
- FIX : 버그 수정. 올바르지 않은 동작을 고친 경우에 사용
- ADD : 코드나 테스트, 예제, 문서 등의 추가가 있을 때 사용
- REMOVE : 코드의 삭제가 있을 때 사용
- USE : 특별히 무언가를 사용해 구현을 하는 경우
- REFACTOR : 전면 수정이 있을 때 사용
- SIMPLIFY : 복잡한 코드를 단순화할 때 사용. Refactor의 성격이 강하나 이보단 약한 수저으이 경우 이용
- UPDATE : 개정이나 버전 업데이트가 있을 때 사용. Fix와 달리 잘못된 것을 바로잡는 것이 아니라는 점에 주의하기. 원래도 정상 동작했지만 수정 추가 보완을 한다는 개념 (코드보단 문서, 리소스, 라이브러리)
- IMPROVE : 향상이 있을 때 사용함. 호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등 다양한 것들이 목적이 될 수 있음
- MAKE : 주로 기존 동작의 변경을 명시함
- IMPLEMENT : 코드가 추가된 정도보다 더 주목할 만한 구현체를 완성시켰을 때 사용
- REVISE : Update와 비슷하나 문서의 개정이 있을 때 주로 사용
- ENSURE : 무엇이 확실하게 보장받는다는 것을 명시
- PREVENT : 특정한 처리를 못하게 막음
- AVOID : 회피. if 구문으로 특정한 동작을 제외하는 경우에도 사용할 수 있음
- MOVE : 코드의 이동이 있을 때 사용
- RENAME : 이름 변경이 있을 때 사용
- ALLOW : Make와 비슷하지만 허용을 표현할 때 사용
- VERIFY : 검증 코드를 넣을 때 주로 사용
- SET : 변수 값을 변경하는 등의 작은 수정에 주로 사용
- PASS : 파라미터를 넘기는 처리에 주로 사용
헉 머이리많음.
참고
[Git] 깃 커밋 메시지 작성법(git commit message) - 1
좋은 git commit 메시지를 위한 영어 사전
