-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add step component #76
Conversation
components/step.js
Outdated
get requiredAttributes() { | ||
return ["link"]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이 getter는 어디에서 사용되는 걸까요??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
오 여기에서 사용되고 있군요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
만약 attribute로 들어온 link가 유효한 형식인지 확인하려면 즉, 해당 컴포넌트에 특별한 추가 검증 논리가 필요하다면,
여기서 어떻게 구현하면 되나요?
아니면 단순히 attribute가 들어왔는지 안 들어왔는지만 검사하는 용도의 구현일까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
네, 후자의 용도로 구현하였습니다. 내부 컴포넌트가 하나 더 생기면서 아래와 같이 attribute가 있는지 없는지 검사하는 로직이 반복되어서 하나의 validateAttributes에서 처리해줄 수 있는 용도로 구현해보았습니다.
if (!this.hasAttribute("link")) {
throw new Error('The "link" attribute is required.');
}
들어온 link가 유효한 형식인지 검증해주는 부분까지는 사실 깊게 생각을 못했는데, 필요하다면 link 유효성 검증 로직을 새로 추가하여 구현할 수 있을 것 같아요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
아 기억나네요. 문서화해두진 않았었나요? #44
BaseClass가 전부에게 익숙하지 않으면 이해하는데 시간이 꽤 걸린다는 게 단점이긴 하네요.
@yolophg 지금 한 PR에 16개의 커밋이 있고 그 중에 Merge commit은 3개나 되는데 제가 느끼기에는 좀 과한 것 같습니다. 혹시 commit들을 정리해주실 수 있을까요? 최소한 Merge commit만 정리해도 될 것 같습니다~!! 정리할 수 없다면 말씀해주세요. |
@@ -0,0 +1,132 @@ | |||
import { css, html } from "../html-css-utils.js"; | |||
|
|||
class BaseStepElement extends HTMLElement { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
섣부른 추상화가 될까봐 경계하기는 하는데, 조금씩 논의해보면 좋을 것 같아요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sounmind 역시 우리 테크리드의 깊은 고찰에 감탄합니다 👍
components/step.js
Outdated
<article class="step"> | ||
<section class="step-title"> | ||
<h3>Step ${step}</h3> | ||
</section> | ||
<img class="step-icon" src="${iconSrc}" alt="Step icon" /> | ||
<section class="step-content"> | ||
<slot name="content"></slot> | ||
</section> | ||
</article> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저희가 논의한 컴포넌트 API 디자인과 잘 부합하는 구현인 것 같습니다! 💯
3df61d5
to
1afb4c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
사소한 추가 코멘트가 있지만 전반적으로 완성이 된 것 같아서 승인합니다. @sounmind 님께서, #76 (comment) 에서 피드백 드렸던 것처럼, PR의 커밋 이력을 좀 더 깔끔하게 관리하시면 팀원 간에 코드 리뷰 경험을 개선하는데 큰 도움이 될 거라 생각합니다.
Step section, list 컴포넌트 포함
|
넵, 코드 리뷰 경험을 개선하는데에 커밋이력을 깔끔히 관리하면 좋은 점 동의합니다. merge 커밋들의 경우, 제가 conflict를 해결하려고 했었는데 이 부분은 혼선을 드린 것 같아 다음 작업부터는 제외시키도록 하겠습니다! 저의 경우에는, 평소에 작업할 때 최대한 작은 단위로 쪼개서 그 커밋에는 그 내용(사소한 리네이밍과 같은 리팩토링도)만 포함되는걸 선호해왔고, 이번 컴포넌트에서도 아주 작은 단위부터 쪼개다보니 merge 커밋을 제외하고도 내용이 꽤 되었던 것 같습니다. ex)
따라서, 저희의 논의로 명확하게 방식을 정할 수 있는 영역인지는 모르겠으나, 최대한 제가 묶을 수 있는 것들끼리는 묶어서 커밋할 수 있도록 신경을 써보겠습니다 :) |
@yolophg 네, 저는 다 같이 논의하는 거는 좋습니다. 그런데 한 가지 생각해볼 부분은 이러한 세세한 컨벤션에 대한 논의가 때때로 오히려 프로젝트의 진행을 느리게 할 수 있다는 것입니다. 이미 예상하시고 계신 것처럼 깔끔한 커밋 이력에 대한 판단은 상당히 주관적일 수 있는 부분이라서, 저도 여러 프로젝트에서 관련된 논의를 해봤지만 한 번도 모든 팀원이 만족할 만한 합의를 이끌어 낸 적이 거의 없었습니다. 오히려 억지 같은 규칙을 만들고 실천이 안 됐던 기억이 있습니다. @sounmind 님만 불편하지 않으시다면 저는 @yolophg 님의 잘게 쪼개시는 커밋 취향을 존중하고 싶습니다. 지금 이대로 머지하셔도 크게 개의치는 않고요. 단, 말씀하셨던 것처럼 merge 커밋만 정리해주셔도 나중에 기억을 되살리기 위해서 이 PR을 참조할 때 큰 도움이 될 것 같습니다. 모임 때 보면 항상 시간이 부족했던 것 같아서, 꼭 중요한 논의에 시간을 쓰고 싶어서 제 생각을 남겨봅니다. |
7786000
to
155639d
Compare
style: format StepTextLink HTML for better readability fix: restore accidentally removed text in ds-review-item style: Remove unused style code from index.html style: add large media query in Step component
155639d
to
789461e
Compare
Checklist before merging