yarn add -D react-app-rewired customize-cra
// package.json
"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test"
},
// .babelrc
{
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "legacy" }],
    ["@babel/plugin-proposal-class-properties", { "loose": true }]
  ]
}

useBabelRc() 가 CRA 의 babel 설정 대신 .babelrc 를 쓰게 한다.1

// config-overrides.js
const { useBabelRc, override } = require('customize-cra')

module.exports = override(useBabelRc())

CRACO로 구성하는게 지금은 맞는 것 같다.

Footnotes

  1. customize-cra api.md — useBabelRc(): “Causes your .babelrc (or .babelrc.js) file to be used, this is especially useful if you’d rather override the CRA babel configuration…” ↩

#create-react-app#deprecated
#228
interface PaginationProps {
  /** 현재 페이지 번호 */
  currentPage: number;
  /** 전체 페이지 수 */
  totalPages: number;
  /** 페이지 변경 시 호출되는 콜백 함수 */
  onPageChange: (pageNumber: number) => void;
  /** 이전/다음 페이지 링크 표시 여부 (선택적) */
  showPreviousNext?: boolean;
  /** 페이지 번호 링크 표시 여부 (선택적) */
  showPageNumbers?: boolean;
  /** 페이지당 항목 수 (선택적) */
  pageSize?: number;
}

하지만 너무 많은 기능이 필요없기 때문에 최대한 단순한 컴포넌트를 만들었다.

#pagination
#227
📎

Web Vitals

web.dev

Core Web Vitals & Performance Metrics

LCP 최적화

이미지 및 리소스 로딩 최적화

사이트 속도 및 성능 최적화

CSS 기반 성능 최적화

서드파티 스크립트 및 자원 관리

Partytown 및 서드파티 스크립트 성능 개선

케이스 스터디: 웹 성능 개선 사례

메모리 및 성능 이슈 해결

#performance#speculation
#224
- 프로젝트에 새롭고 반짝이는 기술보다는 지루한 기술을 선택하는 것이 좋습니다.
- 흥미로운 기술은 프로젝트에 불필요한 위험을 초래할 수 있습니다.
- 이미 확립되고 입증된 기술이 성공적인 결과로 이어질 가능성이 더 높습니다.
- 신기술을 둘러싼 과대 광고는 오해의 소지가 있습니다.
- 신기술의 수명을 예측하기는 어렵습니다.
- 지루한 기술은 화려하지 않을 수 있지만 안정적이고 신뢰할 수 있으며 예측 가능합니다.
- 최신 기술 유행보다는 비즈니스 문제 해결에 집중하세요.
- 사람과 프로세스에 투자하면 더 나은 결과를 얻을 수 있습니다.
- 지루한 기술을 선택하는 것은 보수적이거나 위험을 피하기 위한 것이 아니라 프로젝트의 장기적인 성공을 우선시하는 정보에 입각한 결정을 내리기 위한 것입니다.

Footnotes

  1. Dan McKinley :: Choose Boring Technology ↩

  2. 항상 최신의 최첨단 솔루션을 쫓기보다는 확립되고 신뢰할 수 있는 기술을 사용하는 것을 지지하는 글. 특히 장기 프로젝트의 경우 기술 선택에서 안정성과 예측 가능성의 중요성을 강조. ↩

#222

Footnotes

  1. Feedback Ladder: ⛰ 산(Mountain) / 차단 및 즉각적인 조치 필요, 🧗‍♀️ 볼더(Boulder) / 블로킹, ⚪️ 자갈(Pebble) / 비차단하지만 향후 조치가 필요함, ⏳ 모래(Sand) / 논블로킹이지만 향후 고려 필요, 🌫 먼지(Dust) / 비차단, “받거나 놔두세요” ↩

  2. 다른 사람들의 상황이 자신에게 적용되는지 자문해볼 필요가 있다. ↩

#code-review
#221
#state-machine
#219
📎

BDD with Cucumber

school.cucumber.io

BDD는 무엇을 의미합니까?

BDD는 시스템의 원하는 동작을 협력적으로 지정하는 접근 방식입니다. 행동의 일부가 합의될 때마다 우리는 그 행동을 구현할 코드의 개발을 “추진”하기 위해 해당 사양을 사용합니다.

BDD의 세 가지 관행은 무엇이며 스토리에 어떤 순서로 적용합니까?

우리는 스토리에 필요한 행동의 범위를 공동으로 발견 하는 것으로 시작합니다. 일단 우리가 행동에 동의하면 우리는 비즈니스가 읽을 수 있는 언어로 사양을 공식화 합니다. 마지막으로 공식화된 사양을 자동화 하여 시스템이 실제로 예상대로 작동하는지 확인합니다.

Cucumber와 BDD는 어떤 관련이 있습니까?

Cucumber는 문서를 이해하고 자동화된 테스트로 변환하는 도구입니다.

BDD는 세 가지 방식으로 구성된 협업적 접근 방식입니다. BDD 실무자는 Cucumber를 사용하여 문서를 자동화할 수 있습니다.

“살아있는 문서”의 특별한 점은 무엇입니까?

문서가 애플리케이션의 동작과 동기화되지 않을 때 자동으로 알려 주기 때문에 “살아있는 문서”라고 부릅니다. 그것이 특별한 점입니다.

완료에 대한 정의의 일부로 이를 검토할 수 있지만 자동으로 유효성이 검사되지 않더라도 작성한 모든 사양 문서에 대해서도 마찬가지입니다.

그것은 자동화된 테스트에 의해 생성 되지 않습니다 - 여전히 작성해야 합니다! 자동화된 테스트는 귀하가 작성한 내용이 사실인지 아닌지를 알려줍니다.

이를 위한 변경 제어 프로세스가 있을 수 있습니다. 설명하는 코드와 함께 소스 제어에 유지하는 것이 좋습니다. 그러나 다시 말해서 특별한 것은 아닙니다. Word 문서에 대해 놀랍도록 투명한 변경 제어 프로세스를 가질 수 있지만 여전히 완전히 구식이고 잘못된 것일 수 있습니다.

#bdd#test
#218

Footnotes

  1. Jotai 의 atom((get) => …) 이 async/await 와 같은 모양인 건 우연이 아니다 — atom 과 Promise 가 둘 다 모나드라 같은 do-notation 을 쓴다. 모나드는 of·map·join 셋을 구현할 수 있는 구조. ↩

  2. 타입·범주론 없이 모나드를 “발명”해 보는 글. null 체크 조건문을 없애려고 whenExists 체이너를 만들다가, 체이너를 돌려주는 함수끼리 이으려니 중첩이 생기고 그걸 펴는 과정에서 모나드가 나온다. ↩

  3. 2013년 콜백 지옥에서 출발해 Promise·배열의 공통 패턴을 뽑아 Functor → Monad 로 가는 TypeScript 글. async/await 가 모나드 위에 지은 문법이라는 데까지 간다(보너스로 Monoid). ↩

  4. Studying With Alex 채널의 모나드 입문 영상. ↩

  5. pipe(x, a, b) 를 2,560번 쓴 회고. b(a(x)) 를 왼쪽에서 오른쪽으로 읽게 하는 함수(reduce 한 줄)이고, 함수를 합성만 하는 compose 보다 고차 함수로 생각할 필요가 없어 읽기 쉽다 — 메서드 체이닝을 네이티브 메서드 밖으로 넓힌 것. ↩

  6. 파이프 연산자 |> 제안에 4년 관여한 저자가 F# 파이프 지지에서 Hack 파이프(플레이스홀더)로 돌아선 이유. Hack 파이프가 커링 없이도 쓸 수 있어 함수형 라이브러리와 일반 JS 사이를 잇는다는 주장. ↩

  7. pipe 는 함수 n 개를 왼쪽→오른쪽으로, compose 는 오른쪽→왼쪽으로 잇는다는 입문 (freeCodeCamp 로 옮겨진 글). ↩

  8. 고차 함수 입문. 함수가 값(일급 시민)이라 인자로 넘기고 돌려줄 수 있고, 그게 DOM 조작 같은 실무 코드에서 왜 쓸모 있는지 예제로 보인다. ↩

#fp
#215

커스텀 폰트 사용 시, 배포 중 Provided Edge Function is too large 에러가 발생할 경우 로컬 파일로 사용하지말고 fetch로 해당 폰트를 가져온다.12

Footnotes

  1. https://github.com/cbcruk/oz/commit/0cb90b558cca8bf97bfcc0b36914447845131ab7#diff-ea54c769db531913b015e15682e5b3f4364de740cc7d6c1cb2c8ee2a9ce77379L9-R14 ↩

  2. https://vercel.com/docs/concepts/functions/edge-functions/limitations#code-size-limit ↩

#image
#214
// 현재 실행된 stage 값을 참조하기
// 하지만 스크립트를 따로 작성하는게 더 효율적으로 보인다.

{
  "scripts": {
    "dev:hello": "echo ${npm_lifecycle_event#dev:}"
  }
}

Footnotes

  1. npm 스크립트의 이름을 얻는 방법에 대한 질문과 npm_lifecycle_event 환경 변수를 사용하는 방법으로 제안 ↩

  2. package.json 파일에서 스크립트를 사용하는 방법에 대한 개요, 기본 제공 환경 변수 목록도 포함 — “the npm_lifecycle_event environment variable is set to whichever stage of the cycle is being executed.” 스크립트는 sh 로 돌아서 bash 전용 ${var//a/b} 대신 POSIX ${var#prefix} 를 쓴다 — “Scripts are run by passing the line as a script argument to sh.” ↩

#package#shell#npm#node
#213
33 중 21페이지
이전 페이지다음 페이지