Django app code, Angular app code / unit test code 작성하여 어제 repository의 todo_solution branch에 push 했습니다.
PR 을 작성하서야 출석을 인정해드리니 꼭 해주시기 바랍니다.
어제 Frontend code에 대한 부연 설명입니다.
이전 실습에서 다루었던 Hero App은 여러 component에서 HeroService를 참조하는 형태였습니다. 하지만 이번 Todo App은 App Component만 TodoService를 dependency로 가집니다. App Component의 Child Component들에서 발생한 Event들은 전부 App Component로 (EventEmitter를 사용하여) propagate 되어 Event에 대한 처리를 App Component에서 실행합니다.
이러한 디자인은 모든 state와 state transition을 한 common ancestor component에서 처리하기 때문에 좋습니다. Child Component는 Dumb (do change state by its own, is only changed by parent component)하기 때문에 1. Testing이 복잡한 Frontend도 TDD를 하기 쉬워지고, 2. 보다 효율적인 Change Detection Strategy를 사용할 수 있으며, 3. 보다 modular한 구현이 가능하고, 4. child component들이 스스로의 property를 관리할 필요가 없습니다.(App Component가 state transition을 하고, transition된 state-todos 는 알아서 @input property에게 반영이 되기 때문이지요)
Angular Service가 여러 component에서 동시에 사용할 수 있게 만들어진 것은 맞지만, sibling 관계가 아니라 지금처럼 한 component가 다른 component의 dependency일 경우 코드가 복잡해집니다. EventEmitter를 사용하지 않고 지금과 같은 component hierarchy에서 TodoService로 모든 것을 처리 하는 코드를 작성하시면, 1. 개별 component의 test와 2. 각 child component에서 todos의 관리 가 불편한 것을 확인하실 수 있습니다.
예시 solution의 Angular Test code는 단순하게 함수만 call하는 테스트이지만, 실제 project나 hw3에서는 실제 html로 render가 잘 되는지, property/event binding은 잘 되는지 확인하는 테스트를 권장합니다. 그리고 이러한 테스트들은 Component가 Dumb 할 수록 작성하기 편하기에 이러한 예제를 준비했습니다 :)
Django app code, Angular app code / unit test code 작성하여 어제 repository의
todo_solutionbranch에 push 했습니다.어제 Frontend code에 대한 부연 설명입니다.
이전 실습에서 다루었던 Hero App은 여러 component에서 HeroService를 참조하는 형태였습니다. 하지만 이번 Todo App은 App Component만 TodoService를 dependency로 가집니다. App Component의 Child Component들에서 발생한 Event들은 전부 App Component로 (EventEmitter를 사용하여) propagate 되어 Event에 대한 처리를 App Component에서 실행합니다.
이러한 디자인은 모든 state와 state transition을 한 common ancestor component에서 처리하기 때문에 좋습니다. Child Component는 Dumb (do change state by its own, is only changed by parent component)하기 때문에 1. Testing이 복잡한 Frontend도 TDD를 하기 쉬워지고, 2. 보다 효율적인 Change Detection Strategy를 사용할 수 있으며, 3. 보다 modular한 구현이 가능하고, 4. child component들이 스스로의 property를 관리할 필요가 없습니다.(App Component가 state transition을 하고, transition된 state-todos 는 알아서 @input property에게 반영이 되기 때문이지요)
Angular Service가 여러 component에서 동시에 사용할 수 있게 만들어진 것은 맞지만, sibling 관계가 아니라 지금처럼 한 component가 다른 component의 dependency일 경우 코드가 복잡해집니다. EventEmitter를 사용하지 않고 지금과 같은 component hierarchy에서 TodoService로 모든 것을 처리 하는 코드를 작성하시면, 1. 개별 component의 test와 2. 각 child component에서 todos의 관리 가 불편한 것을 확인하실 수 있습니다.
예시 solution의 Angular Test code는 단순하게 함수만 call하는 테스트이지만, 실제 project나 hw3에서는 실제 html로 render가 잘 되는지, property/event binding은 잘 되는지 확인하는 테스트를 권장합니다. 그리고 이러한 테스트들은 Component가 Dumb 할 수록 작성하기 편하기에 이러한 예제를 준비했습니다 :)