Footer 안 스터디 신청 URL 정정

[DaleSeo]

PR #186 에서 제가 스터디 2기 모집을 위해서 Steps 섹션에 있는 스터디 신청 URL을 수정했었는데요. 알고보니 Footer에도 스터디 신청 링크가 있었는데 제가 실수록 수정을 빼먹었더라고요. 2기 신청자 분께서 알려주셔서 뒤늦게 발견하게 되었습니다.

예전에 디스코드 URL도 그렇고 저는 비슷한 문제가 계속 반복되고 있는 이유가 HTML 마크업 안에 데이터를 하드코딩해놔서 그런 것 같습니다. 근본적인 해결책은 이렇게 여러 곳에 위치하는데 주기적으로 갱신이 되야하는 데이터는 한 곳에서 관리하는 것(Single Source of Truth)이라고 생각합니다.

우리 프로젝트는 백앤드나 데이터베이스가 없기 때문에 data.js 파일에 스터디 신청 URL을 저장해놓고 import를 하려고 했는데요. 뜻밖에 걸림돌에 부딪히게 되었습니다. 다음 두 개의 컴포넌트의 API 설계가 일관적이지 않기 때문입니다.

• <ds-steps-section> 요소는 slot을 통해서 외부에서 내용을 넘기도록 되어 있습니다.
• <footer-link-list> 요소는 slot을 받지 않고 내부적으로 내용을 랜더링하도록 되어 있습니다.

<footer-link-list> 요소의 내용은 자바스크립트 파일(footer-link-list.js)에 있기 때문에, 스터디 신청 URL을 import하는데 아무 문제가 없었습니다. 하지만 <ds-steps-section> 요소는 내용은 index.html 파일에 있기 때문에, 스터디 신청 URL을 어떻게 주입해야 할지 고민이 되었습니다.

그래서 임시 방편으로 index.html 파일에 있는 <ds-steps-section> 요소는 내용을 step-section.js 파일로 옮겨서 이 문제를 해결하였는데, 이러한 설계 변경에 대해서 어떻게 생각하시는지 다른 분들의 의견을 듣고 싶습니다.

디스코드 URL도 같이 data.js 파일에 저장하려고 했더니, 비슷한 문제에 부딪히게 되었습니다. <ds-header> 요소는 내주적으로 내용을 랜더링하는데, <ds-intro-section> 요소는 index.html에서 내용을 작성하여 slot을 통해 넘기도록 설계되어 있습니다.

우리 예전에 이 부분에 대해서 잠깐 논의했던 것 같은데, 컴포넌트 API를 설계할 때 언제 slot을 써야하고, 언제 쓰지 말아야 할지에 대해서 좀 더 깊이 생각해보면 어떨까요? 웹 컴포넌트가 아니라 React 컴포넌트였더라도 동일하게 API 설계을 하셨을지 생각해보시면 좋을 것 같습니다.

Checklist before merging

• Link an issue with the pull request
• Ensure no errors or warnings on the browser console
• Avoid additional major pushes after approval (if necessary, request a new review)

[SamTheKorean]

저도 말씀주신 부분에서 컴포넌트 설계 일관성이 떨어지고 장단점에 대해서 계속 고민했었는데 수면위로 올려주셔서 감사합니다.

기본적으로 slot을 사용하는 장점에 대해서 생각해보면, 컴포넌트 사용자가 더 많은 자유를 가져갈 수 있고 동적인 기능을 넣기에 용이하다는 것이라고 생각합니다. 하지만 아직 차후 개발 방향성이 불분명한 상황에서 내주를 하지 않고 slot을 사용하는 것이 과연 개발자 경험을 향상 시키거나 본질적으로 필요한 지에 대한 의문이 들어 over engineering일수도 있다는 생각이 들었습니다. 장기적으로 보더라도, 필요나 비즈니스적 요구사항에 따라 컴포넌트 자유도를 조금씩 늘려나가는게 이미 부여한 자유도를 줄이는 것보다 더 유지보수 비용이 적다고 생각하기 때문에 저는 꼭 필요한 이유가 없다면 현재는 Slot을 사용하지 않는게 경제적인 선택이라고 생각합니다.

아직 경험과 지식이 부족하여 제가 놓치고 있는게 많을 거라 생각하기 때문에 이에 대해 다른 분들의 생각이 궁금합니다!

[yolophg]

앞으로의 방향성까지 고려했을 때, 말씀해주신대로 html에서 넘겨받은 하드코딩된 데이터를 관리하는 것은 유지보수 관점에서도 비효율적이라고 생각합니다.
그런 면에서, ds-steps-section에서 외부에서 넘겨받던 url을 내부에서 받도록 변경한 임시 방편은 현 상황에서 적절한 대응이라고 생각하고, 근본적인 해결책으로 컴포넌트 API 설계를 통일성 있게 하기 위해서는 slot을 최소화 하는 것이 좋다고 생각합니다!

[sounmind]

여러 곳에서 쓰이는 데이터(여기서는 URL)를 쉽게 통제 하기 위한 변경(URL 전달 방식을 JS로 옮겨 통일하기)이라고 생각해서 동의합니다.

[DaleSeo]

@SamTheKorean @yolophg @sounmind 의견 감사합니다. 일관적인 컴포넌트 API 설계를 위해서 불필요한 slot 사용을 피하는 방향으로 합의가 된 것 같네요. 반복되는 다른 URL도 data.js 파일로 빼는 후속 PR로 올리도록 하겠습니다.