오늘 한 일:

• 배민찬 step2(메뉴 레이어) PR
• event loop

내일 할 일:

• 배민찬 리뷰
• mySQL설치
• 하루 한시간 git
• 러버덕 스터디: how browser works

회고

시나리오를 작성하니 설계단계에서 시간을 단축할 수 있었다. 다만 시나리오를 어느 깊이까지 고려해야 되는지 잘 모르겠다. 오늘은 주어진 기능이 단순했기 때문에 시나리오 단계에서 메소드의 흐름까지 고려했다. 아마 기능이 커지면 자연스럽게 구분될 문제일 것 같다.

배민찬

css

하위 엘리먼트가 자주 변하는 경우 wrap 엘리먼트의 크기를 하위 엘리먼트가 정하도록 하는 것이 좋다

• header의 높이
• 너비가 유동적인 가로형 list
• 등등

/* bad */
header {
    height: 200px;
}
header > div {
    height: 100%;
}

/* good */
header {}
header > div {
    height: 200px
}

메뉴 레이어

마우스가 오버되면 레이어가 펼쳐진다

scenario

마우스를 올렸을 때

1. 마우스를 올린다
2. 어떤 엘리먼트인지 파악한다*
3. 해당 엘리먼트의 데이터를 가져온다*
   • text
   • url
4. 가져온 데이터로 templating한다
5. 엘리먼트 위에 표시한다

마우스가 지나갔을 때

1. 마우스가 떠남
2. 해당 레이어 삭제

고민

마우스가 엘리먼트 위에 오버될 때마다 데이터를 가져오고 새로 엘리먼트 만드는건 비효율적이라고 생각.

어딘가에 만들어진 메뉴 레이어 엘리먼트를 보관하면 좋겠다고 생각이 듦.

하지만 일단 templating을 구현해보기로 결정

설계

flow

1. controller 생성
   • 자신의 메소드 바인딩
   • nav에서 이벤트 등록
2. 마우스 오버*
3. nav > 해당 엘리먼트 정보 > controller
4. controller > 해당 엘리먼트 정보 > model
5. model > text, url > controller
6. controller > text, url > nav.render

class MenuNavigation {
    bindMouseOver() {}
    renderMenuLayer({index, menuLayerData})
}

class Controller {
    mouseOverMenuNavigation(index) {}
}

class Model {
    getMenuLayerData(index) {}
}

구현

templating 방법으로 구현하니..

• 장점: 소스코드가 단순해 가독성이 좋음
• 장점2: 각 클래스마다 역활이 명확해짐. 특히 view가 엘리먼트를 보관하지 않아서
• 단점: 매번 렌더링하기 때문에 퍼포먼스가 저하됨

결론

가독성이 좋아졌긴 했지만 여전히 퍼포먼스가 걸린다. 렌더링된 메뉴 레이어를 view에 보관하는 방법밖에 없을까?

• 렌더링된 엘리먼트를 html에 보관했다가 스타일만 변경해서(display: none등으로) 퍼포먼스 개선할 수 있지 않을까?