Dog foot print

태그는 모든 컴포넌트가 인스턴스되었을 때 실행되는 것이 아닌 처음 script를 읽혔을 때 실행 됩니다. 보통의 script태그와 마찬가지로 변수를 선언 가능합니다. context="module" 속성을 가진 script 내부에서 export 키워드를 통하여, 모듈을 방출 할 수 있으며 컴파일 되었을 때, 모듈화 됩니다. export default는 사용 할 수 없습니다. 이유는 해당 파일에서 기본 방출 되는 것은 스벨트 컴포넌트이기 때문입니다. Note : 에서는 반응성을 구현 할 수 없습니다. 만약 다양한 컴포넌트에서 반응성을 필요로 한다면 store를 생성하는 것을 고려하세요 .

Store contract store = { subscribe: (subscription: (value: any) => void) => (() => void), set?: (value: any) => void }개발자는 svelte/store의 도움 없이, store contract를 구현 할 수 있습니다. 다음은 커스텀 스토어를 생성하기 위한 규칙입니다. 스토어는 반드시 subscription 정의에 맞는 첫번째 전달인자를 가진 .subscribe메서드를 가지고 있어야 합니다. subscription콜백은 신속하고 동기적으로 현재 값을 전달해주어야 합니다. .subscribe메서드는 반드시 unsubscribe메서드를 반환해야 합니다. unsubscribe메서드를 호출 하게되면, 더 이상 store의 ..

Mock 함수는 테스트에서 사용 할 수 없는 함수(window.replace)와 함수에 어떤 파라메터가 전달되었는지, 인스턴스가 new 키워드로 생성되었을 때 생성자 함수를 캡쳐링 하는 것을 가능하게 도와준다. Mock 함수를 사용하는 방법은 두개가 존재한다. 이 두 방법은 test code에서 직접 Mock 함수를 생성하거나, 의존성 모듈에 직접 mock함수를 작성하는 방법이다. Using a mock function 다음과 같이 forEach 함수를 통해서 배열을 순회하며, 전달 된 callback으로 배열 내부에 아이템을 전달한다고 생각해보자. function forEach(items, callback) { for (let index = 0; index < items.length; index++) ..

Note : 제스트는 matcher를 사용하여, 사용자가 다양한 방식으로 값을 테스트 하게 도와줍니다. 이 문서는 주로 사용되는 matcher에 대해서 소개 하며, 모든 Mathcer에 대한 list는 다음의 링크를 참조하세요. 일반적인 Matcher들 다음 예제는 아주 간단한 방법으로 값이 예상하는 값과 일치하는지 확인 하는 방법입니다. test('two plus two is four',()=>{ expect(2 + 2).toBe(4); }) 이 코드에서, expect(2+2) 함수 호출은 ”expectation” 객체를 반환합니다. 일반적으로 이러한 expectation 객체에서 call matcher를 제외하고는 많은 작업을 수행하지 않습니다. 이 코드에서는.toBe(4) 가 Matcher 입니다...

서론 Jest 시작하기 시리즈 문서들은 TEST 도구인 JEST의 공식 홈페이지 문서를 번역하고 설명을 덧 붙인 문서입니다. 설치 * Yarn 을 이용한 설치 * $ Yarn add —dev jest * Npm 을 이용한 설치 * $ npm install —save-dev jest Note : 이 문서는 yarn command를 사용하지만, npm 또한 동일하게 동작합니다. JEST 실행하기 ./sum.js function sum(a,b){ return a + b; } ./sum.test.js const sum = require("./sum"); test("adds 1 + 2 to equal 3",()=>{ expect(sum(1,2)).toBe(3); }) ./package.json { ... "scr..

서론 지난 포스팅에 이어 마지막 DIP 에 대해서 포스팅 하겠습니다. DIP :(Dependency Inversion Principle) 의존관계 역전 원칙 의존성 역전 원칙에서 말하는 "유연성이 극대화된 시스템"이란 소스코드가 추상에 의존하며 구체에는 의존하지 않는 시스템을 의미한다. 추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다. 반대로 구체적인 구현체에 변경이 생기더라도 그 구현체가 구현하는 인터페이스는 항상 변경될 필요가 없다. 따라서 인터페이스는 구현체보다 변동성이 낮다. 즉 안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다. 이 원칙을 구체적인 코딩 실천법으로 요약 하면 다음과 같다...

서론 지난 포스팅에 이어 오늘은 [i]에 대해서 포스팅 하도록 하겠습니다. ISP (Interface Segregation Principal) : 인터페이스 분리 원칙 인터페이스 분리 원칙은 어떤 인터페이스로부터 상속받아 클래스를 정의 할 때, 사용하지 않는 메서드까지 상속 받지 말고 새로운 인터페이스를 생성하여 기존 상속하려던 인터페이스를 새롭게 확장하여 상속 받아야 한다는 분리원칙이다. 다음의 클래스다이어그램을 보도록 하자 . 위의 클래스 다이어그램에서 파리,벌,사슴벌레 클래스는 곤충 인터페이스를 상속받는다. 이 경우 파리 클래스에서는 독을 뿜다. 라는 메서드가 필요없으며, 벌 클래스와 사슴벌레 클래스에서는 각각 뿔을 움직인다, 독을 뿜다라는 메서드가 필요없음에도 곤충인터페이스를 상속 받았기 때문에 ..

책 소개 애자일 마스터는 2012년 조너선 라스무슨에 의해 작성된 책이다. 책의 진행 방식은 챕터별로 분류되어 있는 목록을 풀이하고, 중간 중간 애자일 마스터와 제자가 해당 챕터에서 다루고 있는 문제를 변형하여, 질문과 대답을 주고 받는 것으로 한 챕터가 종료된다. 독자는 충분히 의구심을 품을 수 있는 내용을 애자일 마스터와 제자가 대신 질문하고 답변 해주기 때문에, 쉽게 이해 할 수 있다. 책을 읽은 계기 올해 5월 부터 근무하게 된 Hitit 회사에서 첫 날 OT때 이사님으로부터, "Agile 방식으로 팀을 운영합니다. 매일 Stand up을 실천하고, 스프린트가 종료되는 날에는 retro spective를 진행 합니다. 또한 CICD를 통해서 테스트 자동화와 지속적인 배포를 하고 있습니다." 라고 ..