- 공통 컴포넌트
Tabs만들면서 이건 어렵다는 결론
- 대안
좋은 시스템일수록 실제 서비스에 적용하기는 더 어렵다는 문제가 발생. 결국 필요한건 headless 인데 생각보다 많지 않고 어떤 선택이 좋은 선택인가에 대한 조심스러운 부분이 있다.
Footnotes
Footnotes
version: 1
applications:
- frontend:
phases:
preBuild:
commands:
# AWS Amplify 에서 모노레포 구조를 사용 할 경우 root 레벨로 올라가서 install
- cd ../../
- echo "$PWD"
- yarn install
build:
commands:
- echo "$PWD"
# 현재 root로 이동한 상태이므로 $AMPLIFY_MONOREPO_APP_ROOT를 바로 참조하도록 설정
- if [ $NODE_ENV_VARIABLES = ".env.development" ]; then cat "./$AMPLIFY_MONOREPO_APP_ROOT/$NODE_ENV_VARIABLES" > "./$AMPLIFY_MONOREPO_APP_ROOT/.env.production"; fi
- yarn run "build:$AMPLIFY_MONOREPO_APP"
artifacts:
baseDirectory: build
files:
- '**/*'
cache:
paths:
- node_modules/**/*
appRoot: apps/app
# .env
REACT_APP_VERSION=0.0.0-${TURBO_HASH}
REACT_APP_VERSION을 자동으로 입력할 방법을 찾다가 결국 hash값을 추가했다.
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 }]
]
}
// config-overrides.js
const { useBabelRc, override } = require('customize-cra')
module.exports = override(useBabelRc())
CRACO로 구성하는게 지금은 맞는 것 같다.
interface PaginationProps {
/** 현재 페이지 번호 */
currentPage: number;
/** 전체 페이지 수 */
totalPages: number;
/** 페이지 변경 시 호출되는 콜백 함수 */
onPageChange: (pageNumber: number) => void;
/** 이전/다음 페이지 링크 표시 여부 (선택적) */
showPreviousNext?: boolean;
/** 페이지 번호 링크 표시 여부 (선택적) */
showPageNumbers?: boolean;
/** 페이지당 항목 수 (선택적) */
pageSize?: number;
}
- cbcruk/react-flat-pagination
- mayankshubham/react-pagination
- react-component/pagination
- wwwaiser/react-js-pagination
- material-ui/react-pagination/
- Pagination - NuxtLabs UI
- AdeleD/react-paginate
하지만 너무 많은 기능이 필요없기 때문에 최대한 단순한 컴포넌트를 만들었다.
- 프로젝트에 새롭고 반짝이는 기술보다는 지루한 기술을 선택하는 것이 좋습니다.
- 흥미로운 기술은 프로젝트에 불필요한 위험을 초래할 수 있습니다.
- 이미 확립되고 입증된 기술이 성공적인 결과로 이어질 가능성이 더 높습니다.
- 신기술을 둘러싼 과대 광고는 오해의 소지가 있습니다.
- 신기술의 수명을 예측하기는 어렵습니다.
- 지루한 기술은 화려하지 않을 수 있지만 안정적이고 신뢰할 수 있으며 예측 가능합니다.
- 최신 기술 유행보다는 비즈니스 문제 해결에 집중하세요.
- 사람과 프로세스에 투자하면 더 나은 결과를 얻을 수 있습니다.
- 지루한 기술을 선택하는 것은 보수적이거나 위험을 피하기 위한 것이 아니라 프로젝트의 장기적인 성공을 우선시하는 정보에 입각한 결정을 내리기 위한 것입니다.
Footnotes
-
항상 최신의 최첨단 솔루션을 쫓기보다는 확립되고 신뢰할 수 있는 기술을 사용하는 것을 지지하는 글. 특히 장기 프로젝트의 경우 기술 선택에서 안정성과 예측 가능성의 중요성을 강조. ↩
Footnotes
-
코드 리뷰는 비동기식 커뮤니케이션의 한 형태이므로 많은 컨텍스트(바디랭귀지 및 주고받을 기회 등)가 손실됩니다. 이것은 대부분의 원격회사인 우리에게 특히 중요하므로 피드백에 약간의 뉘앙스를 추가할 방법을 원했습니다. ↩
-
Feedback Ladder: ⛰ 산(Mountain) / 차단 및 즉각적인 조치 필요, 🧗♀️ 볼더(Boulder) / 블로킹, ⚪️ 자갈(Pebble) / 비차단하지만 향후 조치가 필요함, ⏳ 모래(Sand) / 논블로킹이지만 향후 고려 필요, 🌫 먼지(Dust) / 비차단, “받거나 놔두세요” ↩
-
코드 리뷰 없이 신뢰를 기반으로 엔지니어링 문화를 구축한 방법. 다른 사람들의 상황이 자신에게 적용되는지 자문해볼 필요가 있다. ↩
BDD는 무엇을 의미합니까?
BDD는 시스템의 원하는 동작을 협력적으로 지정하는 접근 방식입니다. 행동의 일부가 합의될 때마다 우리는 그 행동을 구현할 코드의 개발을 “추진”하기 위해 해당 사양을 사용합니다.
BDD의 세 가지 관행은 무엇이며 스토리에 어떤 순서로 적용합니까?
우리는 스토리에 필요한 행동의 범위를 공동으로 발견 하는 것으로 시작합니다. 일단 우리가 행동에 동의하면 우리는 비즈니스가 읽을 수 있는 언어로 사양을 공식화 합니다. 마지막으로 공식화된 사양을 자동화 하여 시스템이 실제로 예상대로 작동하는지 확인합니다.
Cucumber와 BDD는 어떤 관련이 있습니까?
Cucumber는 문서를 이해하고 자동화된 테스트로 변환하는 도구입니다.
BDD는 세 가지 방식으로 구성된 협업적 접근 방식입니다. BDD 실무자는 Cucumber를 사용하여 문서를 자동화할 수 있습니다.
“살아있는 문서”의 특별한 점은 무엇입니까?
문서가 애플리케이션의 동작과 동기화되지 않을 때 자동으로 알려 주기 때문에 “살아있는 문서”라고 부릅니다. 그것이 특별한 점입니다.
완료에 대한 정의의 일부로 이를 검토할 수 있지만 자동으로 유효성이 검사되지 않더라도 작성한 모든 사양 문서에 대해서도 마찬가지입니다.
그것은 자동화된 테스트에 의해 생성 되지 않습니다 - 여전히 작성해야 합니다! 자동화된 테스트는 귀하가 작성한 내용이 사실인지 아닌지를 알려줍니다.
이를 위한 변경 제어 프로세스가 있을 수 있습니다. 설명하는 코드와 함께 소스 제어에 유지하는 것이 좋습니다. 그러나 다시 말해서 특별한 것은 아닙니다. Word 문서에 대해 놀랍도록 투명한 변경 제어 프로세스를 가질 수 있지만 여전히 완전히 구식이고 잘못된 것일 수 있습니다.
커스텀 폰트 사용 시, 배포 중 Provided Edge Function is too large 에러가 발생할 경우 로컬 파일로 사용하지말고 fetch로 해당 폰트를 가져온다.12