pub/sub 패턴을 사용하여 리팩토링

[sososimsim]

개요

pub/sub 패턴을 사용해서

• 좌우 이동을 담당하는 navigator,
• 하단의 전체 페이지를 표시하는 indicator(pagination?)
• 실제 슬라이드들을 이동시키는 container

각각이 Controller가 발행하는 이벤트를 수신해서 동작하도록 고쳐보았습니다.

상세

• 캐러셀 수만큼의 Controller를 만든다.
• Controller 하나당 Event, Container, Navigator, Indicator가 만들어진다.
• Container는 사용자가 캐러셀로 지정한 selector를 기준으로 가지고 온 dom의 clientSize를 기준으로 계산하여 만든다. (옵션값 지정 X)
• 각 Controller 당 하나의 Event 맵이 공유되어, Navigator, Indicator가 보내는 이벤트를 Container에서 받을 수 있다.

pub/sub 적용에 대한 생각

• 복잡한 상속 관계 등이 없을 때에 컴포넌트간에 결합도를 낮출 수 있는 패턴이라고 생각했습니다.
• 보통 라이브러리를 사용할 때, 해당 라이브러리의 커스텀 이벤트들이 발생하는 시점에 추가 동작을 끼워넣을 수 있도록 하기 위한 것도 있습니다.

• 패턴 자체적으로 이벤트를 발행하는 입장에서 이 이벤트를 어디에서 수신해서 어떤 일이 일어날 지를 예측하기 어려워질 수 있다는 문제가 있지만, Carousel은 규모가 큰 프로젝트가 아니라 문제되지 않을 정도라고 생각했어요.

  TODO & 생각거리(?)

• [ ] event를 주입해주고 있는 식으로 구현했는데, 이런방식이 아니라 전역 객체로 관리해야 하는 게 나을까??
  • 이런 용도의 전역 객체를 효율적으로 만드는/관리하는 방법이 따로 있을까?

• [ ] Navigator에서 '다음' 화살표를 클릭했을 때

  • Container 이동
  • Indicator도 해당 페이지가 활성화되도록 싱크 맞추기
  • 만약 마지막 페이지라면 Navigator에서 '다음' 화살표 비활성화

  같이 함께 일어나야하는 동작들을 함께 처리하는 부분을 추가하고, 이렇게 여러 컴포넌트가 동일한 이벤트를 수신해서 각각에서 필요한 처리를 할 때에도 pub/sub으로 잘 관리가 되는 지 확인해본다.

[hyeonmi]

코드를 보면서 고민 됐던 포인트를 주절주절 해보면.. Container가 없다면 Navigator, Indicator 독립적으로 의미가 있나? 없다면 Container가 Navigator, Indicator 인스턴스를 생성하고 가지고 있는 구조가 되어야하지 않나? 하지만 지금 구조처럼 같은 따로 분리하면 재사용은 가능하겠다. 그런데 다른 곳에서 재사용이 가능한가?

그리고 (개발)사용자의 입장에서 이 라이브러리를 쓸때 필요하다고 생각되는 부분.

• 특정 메소드를 호출해서 특정 페이지로 이동하고 싶다.
• 내부에서 moveTo 같은 발생 했을때 이벤트를 받고 싶다.

[hyeonmi]

Events Class는 우리 event라 얼핏 보면 헷갈릴수 있어서 이름 변경하면 좋을거 같아요. 코드 가독성이 좋고 객체의 응집도가 좋은것 같아요! :)

[sososimsim]

슬라이드 3개 중에서 3페이지로 이동한다고 하면

• Container : 3번째 슬라이드가 노출되는 위치로 이동
• Navigator : next 버튼 비활성화
• Indicator : 3번째 dot를 활성화

요런식으로 각각의 동작이 동시에 일어나는 것을 생각하고 있었는데요. 지금 다시 보니 Navigator, Indicator에서 일어나는 동작을 추가로 구현하지 않았었네요..^_ㅠ 지금 상태로는 trigger만 하고 있어서 굳이 나눌 필요가 있나...? 하는 생각이 더 들게 되는 것 같아요.

따로 분리하면서 원래 생각했던 것들은 이런 것들이었어요.

• 화살표/dot 말고 다른 모양, 다른 위치로 Navigator,Indicator UI를 커스터마이징 할 수 있도록 (-> 근데 이건 지금 보니 딱히 pub/sub이나 모듈이랑은 관계가 없는 것 같기도...?)
• 같은 moveTo(3) 상황에서 Container, Navigator, Indicator 각각이 동작하는 로직을 따로 관리하는 것이 유지보수하기에도 훨씬 편할 것 같다.
• Controller에서 모든게 일어난다면 스터디원들이 모두 파일 하나를 수정하게 되면서 대혼란이 생길 것 같다...!

추가 컴포넌트가 붙는 식으로 확장될 일이 거의 없을 거라는 전제라면, 오히려 아예 직접적으로 인스턴스들을 가지고 관리하는 것이 나을 수도 있다는 부분은 다시 고민해봐야할 것 같아요.🤒 (재사용의 단위가 Indicator, Navigator 요 단위가 아니라 그냥 캐러셀 한덩어리 단위여야 맞나 싶기도 하고...)

---

사실 나 이외의 개발자가 사용할 수 있는 라이브러리를 개발해본 경험이 거의 없어서,

• 사용자에게 노출할 인터페이스를 먼저 정하고 그걸 기준으로 개발을 진행하는 게 맞을까?
• 기능들을 모두 개발한 다음에 사용자에게 그 중에서 어느정도 지점을 열어줄 지를 결정하는 게 맞을까?

요것도 지금 좀 고민이 되는 것 같아요. 이건 스터디원들과도 추가로 논의해보아야겠습니다.
처음 시작할 때는 (저는) 어떤 이벤트들을 열어둘까? 는 따로 정해보지 않고, 같이

var carousel = new SP({
  selector : ".some-selector",
  navigator : "arrow",
  indicator : "dots",
  autoslide : false,
  infinite : false
});

요런식으로 생성할 때 주는 옵션들만 생각해보았거든요.