What does classnames/bind get us over treating the imported styles like normal classes (which they are)?
클래스 이름/바인드가 가져온 스타일을 일반 클래스처럼 취급하면 도움이 되는 것은 무엇입니까?
Could write
// component.tsx
-import classNames from 'classnames/bind';
import styles from './component.module.css';
-const cx = classNames.bind(styles);
function Component() {
- <div classNames={cx('some-class')} />
+ <div className={styles['some-class']} />
}
TypeScript
복사
저는 https://github.com/gajus/babel-plugin-react-css-modules.에 대해 잘 모릅니다. readme를 잠깐 훑어보니 styleName 특성이 추가된 것 같습니까? className과 같은 표준 React API를 사용하는 것이 낫습니다.
Less magic = More better.
Also, I'd encourage the use of camel case class names. For example
.someClass {
property: value;
}
Scss
복사
// component.tsx
import styles from './component.module.css';
function Component() {
return <div classNames={styles.someClass} />
}
TypeScript
복사
Slightly less typing.
The main reason for not using camel case was to implement some form of BEM so we write our classes like this block__element--modifier but since the files should remain mostly minimal, I'm open to avoiding that. The other factor is that classnames handles the concatenation for us and allows us to do checks without dealing with ternaries etc.
For the styleName piece, I'm pretty solidly against it at this point. Having used both now, I can confidently say the added syntactic sugar isn't worth the real added complexity.
camel case를 사용하지 않는 주된 이유는 어떤 형태의 BEM을 구현하기 위해서 우리는 block__element--modifier와 같이 클래스를 작성한다.
하지만 파일은 대부분 최소로 유지되어야 하기 때문에, 그것을 피하는 것은 열려 있다.
또 다른 요인은 classnames이 우리를 위해 연결을 처리하며 삼항 연산자 등을 다루지 않고 우리가 검사를 할 수 있게 한다는 것이다.
styleName piece의 경우, 저는 현 시점에서 확실히 반대합니다. 지금 두 가지를 모두 사용해 보니, 추가한 syntactic sugar가 실제로 추가된 복잡성만큼의 가치가 없다고 자신 있게 말할 수 있습니다.
Regarding ternary operator(ternaries), I'm completely on board with using classnames.
삼항 연산자에 관해서는, 저는 classnames을 사용하는 것에 전적으로 찬성합니다.
This totally makes sense
className={cz(styles.foo, active && styles.active, enabled && styles.enabled)}
TypeScript
복사
What's not clear is whether .bind is worth the extra step.
확실하지 않은 것은 '.bind'의 추가적인 단계를 밟을 가치가 있는지 여부이다.
Summarizing offline discussion outcomes:
•
will merge initial changes as is with the bem styling
•
will remove the prefixes and will use the following patterns in styles (for button)
◦
.button will stay the same
◦
.button--variant-outline will become .variantInfo
◦
.button--size-large will become .sizeLarge
◦
more complex components we can add prefixes (e.g. .modal__header--color-info will become .headerColorInfo
Follow up question: Is this sufficient when considering pages in the app if we want to follow the same style there?
초기 변경사항을 bem 스타일링과 있는 그대로 병합합니다.
접두사를 제거하고 스타일에 다음 패턴을 사용합니다(단추에).
- '.button'은 그대로 유지됩니다.
- '.button--button-discute'가 .button이 됩니다.정보
- '.button-size-large'가 '.sizeLarge'가 됩니다.
접두사를 추가할 수 있는 더 복잡한 구성 요소(예: '.modal__header--color-Info')는 '.headerColorInfo'가 됩니다.
후속 질문: 같은 스타일로 하려면 앱의 페이지를 고려할 때 이 정도면 충분한가요?
나는 이슈를 업데이트했지만, 적어도 보간 카멜 케이스가 이것을 훨씬 더 악화시킨다는 것을 알리고 싶었다(옵션 4).
이렇게 하면 옵션 1, 2, 3이 남습니다. 저는 여전히 옵션 1을 좋아하지만, 팀의 선호가 있다면 옵션 3을 선택하는 것이 좋습니다.
// 무슨 옵션을 말하는지? 위에 4개 목록을 뜻하는 것 같음
I also think any of options 1-3 could work fine 
for option 2 traject has enough 2+ word classNames that I think the overhead of writing styles[] each time is not trivial you know what I tried this out and I eat my words, it doesn't seem like a big deal lol
for option 2 traject has enough 2+ word classNames that I think the overhead of writing styles[] each time is not trivial you know what I tried this out and I eat my words, it doesn't seem like a big deal lol또한 옵션 1-3 중 어느 옵션도 잘 작동할 수 있습니다 옵션 2의 경우 단어 클래스가 2개 이상이면 충분하다고 생각합니다.[] 스타일 작성에 드는 오버헤드가 사소하지 않다고 생각합니다. 제가 시도했던 단어를 그대로 읽어보니까 별거 아닌 것 같습니다. lol
옵션 2의 경우 단어 클래스가 2개 이상이면 충분하다고 생각합니다.[] 스타일 작성에 드는 오버헤드가 사소하지 않다고 생각합니다. 제가 시도했던 단어를 그대로 읽어보니까 별거 아닌 것 같습니다. lolsome other things I thought of:
Does '.bind' make it harder to support CSS modules and global CSS in the same file?
(since we may need to import both/somehow differentiate them)
If so, this may be a nonstarter for now.
1 trade-off of interpolation is it works well for us for these atomic components (b/c they have to handle a lot of variation -- this is esp. apparent in the typography component), but is less important to larger components / in apps. So option 3 might feel annoying now but be much less annoying soon
another trade-off is interpolation is easier to write, but I actually think option 3 is slightly easier to read.
If the type component in refactor(classnames): move to camelcase classnames is the worst it gets in terms of repetitiveness,
I think we can live with option 3 --
and there's probably some chunking we can do of sub-pieces to make it better (e.g. I also think any of options 1-3 could work fine for option 2 traject has enough 2+ word 'classNames'
that I think the overhead of writing 'styles[]' each time is not trivial
you know what I tried this out and I eat my words,
it doesn't seem like a big deal lol
for option 2 traject has enough 2+ word 'classNames'
that I think the overhead of writing 'styles[]' each time is not trivial
you know what I tried this out and I eat my words,
it doesn't seem like a big deal lol내가 생각한 다른 것들:
'.bind'가 CSS 모듈과 글로벌 CSS를 같은 파일로 지원하는 것을 더 어렵게 하나요?
(둘 다/다양한 차별화를 가져와야 할 수 있으므로)
만약 그렇다면, 이것은 현재로서는 별로 중요하지 않을 수도 있습니다.
보간법의 첫 번째 트레이드오프는 이러한 원자 구성 요소(b/c는 많은 변동을 처리해야 하는데, 이것은 특히 타이포그래피 구성 요소에서 명백하다)에 대해 잘 작동하지만 앱에서 더 큰 구성 요소에는 덜 중요하다. 그래서 지금 3번 옵션이 짜증날 수도 있지만 금방 덜 짜증날 수도 있다.
또 다른 트레이드오프는 보간법이 쓰기 쉽다는 것이지만, 사실 옵션 3이 읽기가 조금 더 쉽다고 생각한다.
refactor(classnames): camelcase 클래스 이름으로 이동하는 형식 구성 요소가 반복성 측면에서 최악의 경우,
제 생각엔 3번 옵션만 가지고 살 수 있을 것 같아요.
또한 더 나은 성능을 위해 하위 조각을 청킹할 수 있습니다(예: 옵션 1-3 중 어느 것이든 잘 작동할 수 있을 것 같습니다 옵션 2의 경우 'classNames'라는 단어가 2개 이상 있습니다).
옵션 2의 경우 'classNames'라는 단어가 2개 이상 있습니다).매번 '스타일[스타일]'을 쓰는 데 드는 오버헤드가 사소하지 않다고 생각한다는 것
내가 뭘 시도해봤는지 알잖아 그리고 난 내 말을 지웠어
별일 아닌 것 같아 ㅋㅋ
Option 3 looks clearer, more explicit, and more obviously correct to me. But that could just be personal preference.
To answer one of your questions, Annie(바로 위 글):
Does '.bind' make it harder to support CSS modules and global CSS in the same file (since we may need to import both/somehow differentiate them)?
I don't believe it makes it harder (correct me if that's wrong). More that it's not clear (to me) that we get a lot of benefit from it.
옵션 3이 더 분명하고 명확하고 분명히 맞는 것 같아. 하지만 그건 개인적인 취향일 수도 있어요.당신의 질문들 중 하나에 답하자면, Annie(애니)
'.bind'가 CSS 모듈과 글로벌 CSS를 동일한 파일에서 지원하는 것을 더 어렵게 합니까(둘 다 가져오기/어느 정도 차별화해야 할 수 있기 때문에)?
저는 그것이 더 어렵게 만든다고 생각하지 않습니다. 더군다나 그것으로부터 우리가 많은 이익을 얻는다는 것은 나에게 명확하지 않다.
I don't think it would be an issue except in the case of collisions between global and local in a given JS/CSS module pair. classnames.bind AFAICT defaults to the identity mapping if there is no hashed mapping.
주어진 JS/CSS 모듈 쌍에서 글로벌과 로컬이 충돌하는 경우를 제외하고는 문제가 되지 않을 것 같습니다. 학급명해시 매핑이 없는 경우 Bind AFAICT는 기본적으로 ID 매핑을 사용합니다.
The PR is merged, and it seems we've come to an agreement around Option 3. Thanks for reviewing everyone!
