JamieYoung891
commented
5 years ago [ENG] I've looked through articles regarding styling consistency and found about the Styled Components which I'd also heard in one of my study group session earlier, and it seems really great.
I've seen anonymous class name used on various websites, I don't sure whether this concept of anonymous name to target elements is its original or not, yet, on the sense of modulization which is the key concept of component based js libraries, this feels rational, and definitely is wide spread.
I am thinking about implementing this on my on-going project, yet, one thing bothers me. All the job opportunity I've looked at, not so much Styled Components mentioned, but SASS I've seen many. If it would affect on my job securing on this very moment, I should take the one with more popular demand, right? Not so rational for the sake of optimizing application, yet, reasonable as we all need food on our table 🤔.
I'd go for the SASS, for now. Styled Components for later. I hope that's not too late, though. After this project, which means in 2 weeks, I'd go for it in my new project, hopefully with React Native, too, yay 😂!
[KOR] 스타일링 일관성에 관한 기사들을 찾아보며 Styled Components에 대해 찾았습니다. Styled Components에 대해서는 일전에 스터디 그룹 모임에서 들어본 적이 있었고, 이번 검색을 통해 매우 괜찮은 기술인 것으로 보았습니다.
익명의 클래스명을 사용한 많은 웹사이트들을 봐왔습니다. 이 익명 클래스를 사용해 엘리먼트를 지정하는 것이 Styled Components 고유의 콘셉트인지는 모르겠어서, 그 사이트들이 이 기술을 사용한 건진 모르겠어요. 그러나 React 등 컴포넌트 기반 JavaScript 라이브러리에서 주요 콘셉트이기도 한, (그리고 모든 프로그램 최적화의 주요 콘셉트이기도 한,) 모듈화라는 측면에서, 합리적으로 느껴지고, 상기한 경험을 토대로 보았을 때 적어도 콘셉트 측면에선 널리 사용되는 것 같습니다.
Styled Components를 진행중인 프로젝트에 도입해볼까 생각하고 있습니다. 다만 걸리는 점이, 제가 확인해본 채용 공고에서 Styled Component가 언급되는 일이 적다는 겁니다. 반면에 SASS는 많이 봤습니다. 새로운 기술을 배우는 것이 지금 이 순간의 취업에 영향을 준다면, 더 대중적인 요구가 있는 기술을 배우는 것이 맞다고 생각합니다, 그렇지 않습니까? 이 생각이 애플리케이션 최적화 측면에서는 크게 합리적인 것은 아닙니다만, 식탁에 음식을 올려야 하는 우리 모두의 입장에선 최소한 이성적인 결정인 거 같습니다🤔.
SASS를 배우려고 합니다, 지금 당장은 말입니다. Styled Components는 다음에 해야겠습니다. 그렇다고 너무 늦어지지 않기를 바랍니다. 이 프로젝트가 끝나고, 즉 2주 정도 뒤엔, 새 프로젝트에서 도입하고자 합니다. React Native도 도입해볼 수 있으면 좋겠습니다😂!
[ENG] By the hasty development without much of consideration, the application has serious consistency problem with its styling.
Color scheme is the major thing. On some property, plain hash color code have been used as its value, but some, HSL function, some, RGB function. Even with the variety of methods, if these colors are the same, it might be okay, but it's not.
HSL function was implemented after much development had been done. It was to give a bit of a color hue and saturation on gray color scheme. Since it was later implemented, some gray colors used are without hue and saturation, some with HSL with 'em.
I had think about this consistency matter of color scheme, beforehand, and had considered CSS variable, but that doesn't cover the notorious IE, so not that one. Maybe, SASS would fix it easily or other CSS extensions. I'd look into it and fix it. Yay, more things to learn!
[KOR] 충분한 고려가 들어가지 못한 급한 개발로 인해 이 애플리케이션은 스타일링에 관한 심각한 일관성 문제를 갖고 있습니다.
특히 주요한 문제가 색상 스킴입니다. 몇몇 속성에서는 그 값으로 해쉬코드 색상이 사용되었으나, 몇몇에서는 HSL 함수가, 또, 몇몇은 RGB 함수가 사용되었습니다. 메소드의 다양성에도 이들 코드가 같은 색상을 표시한다면 괜찮을 수도 있겠습니다만, 이 애플리케이션에서는 그렇지 않습니다.
HSL 함수는 개발이 상당히 진행된 상태에서 도입되었습니다. 이는 무채색 계열 색상에 미세한 색조와 채도를 부여하기 위함이었는데, 뒤늦은 도입 때문에, 몇몇 사용된 무채색 색상들은 여전히 색조와 채도가 부여되어 있지 않습니다.
개발 이전에, 이 색상 스킴과 그 일관성의 문제에 대하여 생각해 보았고, 또, CSS 변수의 적용을 고려해 보았으나, IE 호환성의 문제로 반려하였습니다. SASS나 다른 CSS 확장을 사용해 이 문제를 쉽게 해결할 수 있지 않을까 싶습니다. 탐구하여 수정해보려 합니다. 배울 것이 늘어나는 것에 기쁩니다.