유어슈 슬랙 아카이브

Feca [Web FE] 3월 1일, 오후 11:43

멘션봇 멤버 관리 스펙 관련 스레드
cc. @Juun [Web FE Lead]

76개의 댓글

Feca [Web FE] 3월 26일, 오후 11:55

husky로 깃모지 편하게 쓰기
아주 맛있습니다 ㅋㅋ

(zx 설치해주고)
• .husky/commit-msg.mts

import { fs } from 'zx'

const commitMessagePath = process.argv[2]

if (commitMessagePath) {
  const commitMessage = fs.readFileSync(commitMessagePath, 'utf-8').trim()
  // <https://gitmoji.dev/>
  const newCommitMessage = commitMessage
    // 🐛 Fix a bug.
    .replace(/^b /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f41b@2x.png|:bug:: ')
    // 🎨 Improve Structure / format of the codes.
    .replace(/^a /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f3a8@2x.png|:art:: ')
    // 🔥 Remove code or files.
    .replace(/^f /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f525@2x.png|:fire:: ')
    // ✨ Introduce new features.
    .replace(/^s /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/2728@2x.png|:sparkles:: ')
    // 💄 Update UI and style files.
    .replace(/^l /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f484@2x.png|:lipstick:: ')
    // ♻️ Refactor code.
    .replace(/^r /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/267b-fe0f@2x.png|:recycle:: ')
    // 💩 Write bad code that needs to be improved.
    .replace(/^pp /, ':poop: ')
    // 📦 Update compiled files or packages.
    .replace(/^p /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f4e6@2x.png|:package:: ')
    // 🔧 Write configuration file.
    .replace(/^w /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f527@2x.png|:wrench:: ')
    // 🚚 Move file or directory.
    .replace(/^t /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f69a@2x.png|:truck:: ')

  fs.writeFileSync(commitMessagePath, newCommitMessage)
}

import { fs } from 'zx'

const commitMessagePath = process.argv[2]

if (commitMessagePath) {
  const commitMessage = fs.readFileSync(commitMessagePath, 'utf-8').trim()
  // <https://gitmoji.dev/>
  const newCommitMessage = commitMessage
    // 🐛 Fix a bug.
    .replace(/^b /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f41b@2x.png|:bug:: ')
    // 🎨 Improve Structure / format of the codes.
    .replace(/^a /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f3a8@2x.png|:art:: ')
    // 🔥 Remove code or files.
    .replace(/^f /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f525@2x.png|:fire:: ')
    // ✨ Introduce new features.
    .replace(/^s /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/2728@2x.png|:sparkles:: ')
    // 💄 Update UI and style files.
    .replace(/^l /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f484@2x.png|:lipstick:: ')
    // ♻️ Refactor code.
    .replace(/^r /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/267b-fe0f@2x.png|:recycle:: ')
    // 💩 Write bad code that needs to be improved.
    .replace(/^pp /, ':poop: ')
    // 📦 Update compiled files or packages.
    .replace(/^p /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f4e6@2x.png|:package:: ')
    // 🔧 Write configuration file.
    .replace(/^w /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f527@2x.png|:wrench:: ')
    // 🚚 Move file or directory.
    .replace(/^t /, ':https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-large/1f69a@2x.png|:truck:: ')

  fs.writeFileSync(commitMessagePath, newCommitMessage)
}

깃모지 풀로 작성안해도 굉장히 편하게 쓸 수 있습니다 (편집됨)

스크린샷 2025-03-26 23.55.19.png

23개의 댓글

https://github.com/cloudflare/next-on-pages/issues/952

Feca [Web FE] 3월 31일, 오전 11:33

진짜 레전드....
cloudflare pages가 next15 (엣지 런타임) 지원 안하네요...

클플 페이지에서 nextjs dynamic route 쓰려면 해당 페이지들은 엣지 런타임으로 돌려야되는데
지원을 안함 ㅋㅋㅋㅋㅋㅋㅋ

호환성 때문에 14로 내려야되나
진짜 어지럽네요...

122개의 댓글

Feca [Web FE] 2월 28일, 오후 9:24

멘션봇 스펙 관련 스레드 cc. @EATSTEAK [Web FE] (편집됨)

132개의 댓글

EATSTEAK [Web FE] 4월 6일, 오후 6:03

https://www.chromium.org/developers/design-documents/
메모용

48개의 댓글

EATSTEAK [Web FE] 4월 6일, 오후 2:51

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

@radix-ui/react-slot 이 참 좋아서 애용하고 있긴 한데, asChild를 쓸 경우 children까지 신경써야 하는 경우가 있어서 as prop같은 스타일도 같이 사용할까 생각 중이에요(<= 근데 라이브러리 뭐 쓸지 못찾아서 고민).

여기에 더해서 ComplexButtonGroup 같은 컴포넌트를 만든다고 할 때, query parameter를 조작할 일이 있으면(singular ButtonGroup의 selection 상태를 query parameter로 컨트롤) 당연히 Link 컴포넌트를 사용해서 시멘틱 맥락을 노출하는 것이 좋은데, 이걸 깔끔하게 할 방법이 떠오르지 않더라고요 (일반 ButtonGroup이면 onClick과 이벤트 핸들링으로 전파가 가능한데, query params를 사용하면 Item의 각 value마다 query params를 가진 url을 렌더해줘야 하니까 동작이 크게 달라짐).

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

TL;DR
1. asChild 처럼 시멘틱 태그 변경할 때 어떤 방식이 좋을까
2. 화면에 보이는 요소(스타일, 내부 태그들)은 동일한데 인터렉션 동작만 크게 다르다면 이걸 어떻게 일반화 해야 할까(예: Button <-> Link) (편집됨)

50개의 댓글

Juun [Web FE Lead] 3월 26일, 오후 8:43

pnpm v10과 ESLint Flat Compat 을 같이 사용할 때 VSCode ESLint 플러그인 서버가 제대로 동작하지 않는 버그가 있네요.

pnpm v10에서 ESLint, Prettier 플러그인들을 node_modules 하위로 호이스팅 시키지 않는 변경이 있었는데 VSCode ESLint 플러그인 서버가 호이스팅 되지 않는 ESLint 플러그인을 찾지 못해서 발생하는 문제인 것 같습니다. (ESLint CLI 환경에서는 문제 없음) (관련 이슈)

해결 방법: 프로젝트 루트 디렉토리에 .npmrc 파일을 만들고 아래 내용 추가

public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*

(편집됨)

60개의 댓글

https://opencollective.com/styled-components/updates/thank-you

MJ [Web FE] 3월 27일, 오후 8:41

스컴 사망

opencollective.com

Thank you - styled-components

First and foremost, thank you to everyone who has contributed to styled-components over the years. Open Source is hard work, and many of the larger feature and/or refactoring drives probably would never have shipped without your support! As...

41개의 댓글

Feca [Web FE] 3월 27일, 오전 8:29

next turbopack 빨리 플러그인 지원해줬으면 좋겠네요...
https://github.com/tatethurston/nextjs-routes
이런거 쓰고싶단말이야 엉엉

7개의 댓글

스레드

4월 17일, 오후 10:32 에 아카이브됨

EATSTEAK [Web FE] 4월 6일, 오후 2:51

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

50개의 댓글

Feca [Web FE] 4월 6일, 오후 3:17

일단 1번만 적어둠 2번은 고민좀 해봐야함

1.
저는 개인적으로 이렇게 polymorhic한 컴포넌트 렌더링을 수행해야하는 경우 asChild 패턴으로 위임하려고 노력해요.
이유는 간단한데, ComplexButton 자체가 가지는 책임이 많아질 수록, 본래 프로퍼티의 출처가 애매해지기 때문이에요. (종종 추상화 된 컴포넌트가 거대해질수록 ComplexButton의 프로퍼티인지, Link의 프로퍼티인지 중첩 현상이 발생)

저는 딱 이정도까지만 고민해봤었던 것 같아요. 굳이 직관적으로 위임할 수 있는 asChild 를 두고 as로 갈 이유는 없다고 생각하긴 해요. (편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 3:20

저도 매우동의하는데 한가지 궁금한게

function ButtonWithContent({ asChild }: ComponentProps) {
  const Comp = asChild ? 'button' : Slot;
  return (
    <Comp>
      <Icon> hello
    </Comp>
  );
}

function ButtonAsLinkPage() {
  return (
    <ButtonWithContent asChild>
      <Link to="hello" />
    </ButtonWithContent>
  );
}

15:20

요런식으로 하면 <Icon> Hello가 그대로 전달되는 거죠? 사실 해보면 되긴 한데.. 이렇게 쓰는게 좋은 방법인가 궁금하기도 해서 물어봅니다

Feca [Web FE] 4월 6일, 오후 3:23

넹 그렇겠져? 아무래도 children 자체가 buttonwithcontent에 선언되어있으니까여

15:23

const Comp = asChild ? 'button' : Slot; 이거 바뀐거맞죠?

15:23

ㅋㅋㅋㅋ

EATSTEAK [Web FE] 4월 6일, 오후 3:23

아 걍 기억나는대로 막써서 걍 뇌이징부탁

15:23

ㅋㅋㅋ

Feca [Web FE] 4월 6일, 오후 3:24

애초에 저게 Slot delegation best practice로 알고있긴해요

EATSTEAK [Web FE] 4월 6일, 오후 3:24

솔직히 사용성 측면에서도 asChild가

인건 확실한듯요

Feca [Web FE] 4월 6일, 오후 3:30

흐으음 근데 2번은 뭔가 사례 자체가 감이 잘안오네요
어떤 group 컴포넌트에 value를 넣어주고 그걸로 자식들을 뭔가 슉슉하는거 같은데
추가 예시 가능?

15:31

아 value랑 매칭되는거만 렌더링한다는건가?

EATSTEAK [Web FE] 4월 6일, 오후 3:36

만약 RadioGroup 처럼 특정 버튼을 선택할 수 있는 ButtonGroup 컴포넌트를 만든다고 할 때, 해당 선택을 query parameter에 노출하고 싶을 때가 있겠죠(* sorting options 처럼).
그러면 Group의 선택된 value를 query parameter를 통해 관리하게 될 텐데 이런 경우 onClick을 통해 programmatic하게 관리하기 보다는 미리 해당 query parameter를 렌더해주는게 더 접근성 측면에서 좋겠죠.

-> 이렇게 Link를 바로 렌더링해주는 기능을 직접 구현하려는데 두가지 방법 다 지원하는 컴포넌트를 만드는 방법이 뭐가 있을까 고민

Juun [Web FE Lead] 4월 6일, 오후 4:31

https://kciter.so/posts/render-delegation-react-component/ 글에 댓글로 이런 의견이 있네요

polymorphic (as prop)

polymorhpic은 단순하고 투명하다라는 점이 좋았어요.

런타임에서 해결시키는 기능들이 적고, 주로 props(i.e.As Props)로 소통 해요. 그래서 코드가 단순해지고 투명해져요. 작업자 누구나 as props가 어떤식으로 흘러가는지 쉽게 확인할 수 있는게 큰 장점이었어요.

만약 다른 프로젝트에서 도입을 해본다면 아래 내용들을 고려해볼 것 같아요.

• 컴포넌트의 껍데기에 다형적인 기능을 추가하는 것 외의 용도로 사용하려고 하면 코드관리가 어렵고, 특유의 순수성도 많이 헤치는 것 같아요. 그래서 atomic(예: header, button) 레벨의 요소에 적용해두는게 가장 적합해요.

• typescript를 사용한다면 컴포넌트 정의부에서 복잡한 타입을 정의해놔야해요. 작업자마다 타입에 대한 이해수준이 다를 수 있어서 거부감을 느낄 수 있어요. 저희팀은 MUI의 다형타입 유틸타입을 참고하여 다형타입을 정의해주는 유틸타입을 만들었어요.

Rendering Delegation (asChild)

rendering delegation은 런타임 기능들이 많아서 컴포넌트의 조합을 유연하고 우아하게 처리할 수 있는게 좋았어요.

만약 다른 프로젝트에서 도입을 해본다면 아래 내용들을 고려해볼 것 같아요.

• 컴포넌트의 기능이 완전히 정의된 상태에서는 이 방법이 유용해요. 하지만, 만약 기능 정의가 안된 컴포넌트에 무작정 asChild를 열어두면 혼란함을 야기할 것 같아요. 코드가 어떻게 적용되는지 불투명하다보니 '기준 기능 명세'가 없으면 불안해요.

• slottable한 시스템이 꼭 필요할지? : 생각보다 컴포넌트의 기능을 정의해두고 만드는 케이스가 많지 않아요 (팀마다, 디자인시스템 정책마다 다를 수 있어요). 그렇다면 굳이 공통화된 slottable한 시스템을 구축하기보단, 위 글에서 언급해주신 방법론들을 적절히 조합해서 사용하는게 더 유리할 수 있어요.

(편집됨)

Feca [Web FE] 4월 6일, 오후 4:36

쪼매 어렵네요 이거 ㅋㅋ

결국 문제 상황을 정리하자면, 서로 다른 외부의 스펙들에 따라 현재 렌더링되는 주체들의 내부 스펙이 그에 맞춰서 달라져야하는 상황이네용
그렇기 때문에 외부 스펙에 맞춰서 ComplexButton의 역할을 Link로 지정(asChild를 통해)하려고 했지만 Link를 감싸줘야하니 좀 짜치기도하고...

아무튼 이런 상황에 대해 다형성(일반화)을 갖는 방법에 대해 고민한걸로 이해할게요.

저도 좀 길게 고민해봤는데
저렇게 인터랙션에 대한 인터페이스가 완전히 다른 경우라면 (Link: href를 통함, Button: onClick 이벤트를 통함)

• 하신대로 props를 통해 어떤 인터페이스인지 간접적으로 명시하고, 내부에서 조건부로 인터페이스를 바꿔치기한다.
• 인터페이스의 주체를 children으로 빼버린다 (말씀하셨던 Link를 감싸버리기)
• 새로운 컴포넌트로 만들어버린다
• (최후의 수단) 인터페이스 통일시켜버리기
이거 말고는 딱히 깔끔하게 할 방법은 없을 거 같긴해요
여기서부터 선택이 굉장히 어려워지는데, 저는 이렇게 인터페이스가 완전히 다른 경우라면 아예 컴포넌트를 분리해버릴 거 같아요. (다형성을 가지기는 어렵다는 생각)

일단 제시해주신 방법이 깔끔하게 떨어지도록 마크업을 구성하는 방법에서는 어떻게보면 최선같기는 한데, 애초에 props로 내부에 인터페이스 자체를 바꿔치기 하는게 좋은 패턴은 아닌거 같다고 생각해요. (차라리 다른 인터페이스를 가지는 컴포넌트를 자식으로 넘겨주는게 더 낫다는 생각)

그렇다고 children으로 인터페이스를 넘겨주자니 value를 통한 다형성 렌더링의 책임을 어떻게 가져갈건지에 대한 문제가 남는데,
결국 부모에서 조건부 처리를 해줘야하는 건 똑같다고 생각함

그래서 저는 차라리 새로운 컴포넌트를 만들거 같아용 SelectableLinkGroup 같은거... (편집됨)

16:37

만약 제가 저런 상황이라면 전 웬만하면 걍 저런 경우는 일반화하기 너무 힘든 유형이라고 생각해서 (일반화해도 내부 동작을 이해하기도 어려움)
걍 query들의 선택 가능한 배열 하나 만들어두고 map으로 렌더링할듯 ㅋㅋㅋ (편집됨)

16:38

[1,2,3].map(v => {
  const isSelected = query === v
  return <Link href={`/url?query=${value}`} {...뭐 여기서 이제 isSelected로 스타일 바꾸든 뭐하든} />
})

Juun [Web FE Lead] 4월 6일, 오후 4:57

2. 같은 경우에 Radix Ui Button 컴포넌트의 asChild 로 렌더링할 컴포넌트를 <Link/> 컴포넌트로 변경해서 해결할 수 있지 않을까요?

위 댓글에서 asChild 를 통한 다형성 구현 방식의 단점으로 지적한 코드가 어떻게 적용되는지 불투명하다보니 '기준 기능 명세'가 없으면 불안해요. 를 해소하기 위해서는 asChild 다형성을 지원하는 컴포넌트를 직접 구현하는 것보다 일관적인 동작을 보장하는 Radix UI 컴포넌트를 적극적으로 사용하는 것이 예측 가능성과 디버깅 난이도 면에서 좋을 것 같아요!

export function ComplexButtonGroupExample() {
  const [search] = useSearchParams();
  const query = useMemo(() => search.get("query") ?? "1", [search]);

  return (
    <ComplexButtonGroup>
      <Button asChild value="1">
        <Link to="/url?value=1"/>
      <Button/>
      <Button asChild value="2">
        <Link to="/url?value=2"/>
      <Button/>
      <Button asChild value="3">
        <Link to="/url?value=3"/>
      <Button/>
    </ComplexButtonGroup>
  );
}

(편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 5:08

이거 올리고 고민해 보니까 LinkButton이 맞겠다 싶은게 HTML Controlled/Uncontrolled input 생각해 보면 지금 문제 상황이 컴포넌트의 상태 관리를 외부(searchParams)에 위임한거니 그룹 컴포넌트가 자식의 상태 변경 여부를 알면 안되겠다 싶었음.

그래서 ButtonGroup 내부의 버튼들에 대한 상태 감시를 그룹은 포기하고 각각의 children에게 위임하는게 제일 명확한 솔루션이지 않나 싶네요.

17:10

또 제 상황에서 좀 복잡한 쿼리 파라메터 핸들링 로직도 공통으로 재사용해야해서 Link를 감싸기로 함

17:10

감사합니다

Feca [Web FE] 4월 6일, 오후 5:10

난이도 개높네 ㄹㅇ

17:25

외부(searchParams)에 위임한거니 그룹 컴포넌트가 자식의 상태 변경 여부를 알면 안되겠다 싶었음.

ㄹㅇㅋㅋ
개인적으로 이게 허용되는 시점은 디자인시스템 급의 공통화가 아닌 이상 지양해야한다는 생각 (편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 5:43

!아카이브

멘션봇앱 4월 6일, 오후 5:43

아카이빙을 완료했어요. [아카이브 링크] (편집됨)

EATSTEAK [Web FE]

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

TL;DR
1. asChild 처럼 시멘틱 태그 변경할 때 어떤 방식이 좋을까
2. 화면에 보이는 요소(스타일, 내부 태그들)은 동일한데 인터렉션 동작만 크게 다르다면 이걸 어떻게 일반화 해야 할까(예: Button <-> Link)

4월 6일, 오후 2:51

useStorageState | Slash libraries

Feca [Web FE] 4월 7일, 오후 12:57

아 이거 다시보니까 생각났넹

그래서 내가 개인적으로 제일 싫어하는 패턴이 저런 uncontrolled 한 브라우저 스펙을 가져다 쓰는건데
그래서 몇가지 고민한 결과로 이런게 있었던 거 같음

• useSearchParamsState
https://gist.github.com/fecapark/72fd269f2aa6ba908b077b823abece88

react-router-dom searchParams를 리액트 상태로 관리하게 만들어줌.
상태 관리 흐름 단일화 목적(살짝 약함) + 동시성 처리 목적으로 그냥 얘만 썼음 ㅇㅇ
걍 상태처럼 쓰면 알아서 동기화 해줌
=> 그래서 굳이 Link 쓸 필요없이 그냥 상태 변경 액션처럼 처리해서 쿼리스트링 동기화 시켜버림

• 다른 예로는 toss slash의 useStorateState
https://www.slash.page/ko/libraries/react/react/src/hooks/useStorageState.i18n (편집됨)

slash.page

useStorageState 는 브라우저의 스토리지에 영속적으로 저장되는 상태를 React에서 편리하게 다룰 수 있도록 도와주는 Hook입니다.

EATSTEAK [Web FE] 4월 7일, 오후 12:59

=> 그래서 굳이 Link 쓸 필요없이 그냥 상태 변경 액션처럼 처리해서 쿼리스트링 동기화 시켜버림

결국 이걸 채택 안한 가장 큰 이유는 사용자가 query params를 변경하는 액션을 할 때 programmatic routing이 아닌 link navigation을 통해 하도록 하기 위해서였음

예) Pagination 하는데 Ctrl+클릭으로 다음 페이지를 새 탭으로 열 수 없다면?

Feca [Web FE] 4월 7일, 오후 1:00

애초에 selectable한 input들 리스트에서 새탭으로 열필요가 없다는 생각
=> 다시보니 굳이 programmatic routing 을 사용해도 괜찮은 스펙이라고 느꼈음 (편집됨)

13:00

단순히 여기서 쿼리스트링을 도입한 이유는 선택한 인풋들에 대한 데이터 저장 목적이 크다고 느꼈음

EATSTEAK [Web FE] 4월 7일, 오후 1:05

일반적인 버튼 selection이라면 해당 어프로치가 맞다고 생각(이 경우에는 쿼리스트링을 안쓰는 게 더 나을수도)

그런데 버튼 클릭이 페이지의 주요 컨텐츠를 바꿔버리는(페이지네이션처럼) 동작이라면 사용자에게 "이건 다른 페이지로 가는 하이퍼링크야" 라는 메시지를 명확히 주는게 맞다고 생각함

Feca [Web FE] 4월 7일, 오후 1:10

그런데 굳이 하이퍼링크를 표시해줄 필요가 있을까 싶은게
저 버튼 자체가 컨텐츠가 바뀐다는 표시를 해줄거라고 예상하고 있었음

ex) 클릭하면 드롭다운 나오고 선택으로 필터링 가능한 목록 나오고, 선택하면 쿼리스트링 바뀌면서 컨텐츠 바뀌는거

위 일련의 과정속에서 사용자에게 굳이 하이퍼링크라고 표시해줄 이유는 없다고 생각함.
이미 필터 선택으로 컨텐츠가 바뀌는걸 사용자에게 인지시켜줄 수 있고, 쿼리스트링이 바뀐다고 사용자에게 알려줄 필요는 없다고 생각함 (목적은 컨텐츠의 변경이므로)

13:11

그래서 충분히 마크업상으로 컨텐츠의 변경을 예상시켜줄 수 있다면 programmatic routing을 도입해도 큰 문제는 없을거 같다는 생각인데

13:11

잇스테이크 말도 납득이 되긴됨

EATSTEAK [Web FE] 4월 7일, 오후 1:11

스크린리더등 접근성 고려하면 베스트 프랙티스는 아니라고 생각

Feca [Web FE] 4월 7일, 오후 1:11

글킨하지

EATSTEAK [Web FE] 4월 7일, 오후 1:12

애초에 항상 페이지 브라우징 하면서 링크인척 하면서 아닌 버튼들에 빡친적이 너무 많아서 더 편집증적이긴 한건 ㅇㅈ

Feca [Web FE] 4월 7일, 오후 1:12

ㅋㅋㅋㅋㅋㅋ

EATSTEAK [Web FE] 4월 7일, 오후 1:12

근데 대부분 링크로 동작하는 사이트들은 잘 만든 사이트였음 (예: GitHub)

13:12

이걸 어떻게 링크로 만들었지? 라는 생각이 들 정도

Feca [Web FE] 4월 7일, 오후 1:13

시맨틱 HTML의 정수 그 자체

13:13

뭔가 SPA를 너무 많이봐서 그런가

13:13

저런 searchParams 자체에 굳이 Link를 시맨틱하게 달 필요가 있을까라는 생각이 지배적임
=> 이걸로 인해 코드가 더러워지기 시작하는 경우와 저울질 해봤을 때 안달거 같다는 생각? (편집됨)

13:14

근데 챙길수있다면 챙겨주는게 좋다는 생각이 한편으로는 또 강하게 듬

EATSTEAK [Web FE] 4월 7일, 오후 1:15

근데 구현 난이도와 관계 없이 최종 사용자 동작 측면으로 봤을 때에는 전혀 단점이 없는 구현이라고 생각해서... 페카가 말한대로 이걸 복잡하지 않도록 잘 구현할 수 없는게 가장 큰 문제인듯

Feca [Web FE] 4월 7일, 오후 1:15

최종 사용자 동작 측면으로 봤을 때에는 전혀 단점이 없는 구현

고건 ㅇㅈ

EATSTEAK [Web FE] 4월 7일, 오후 1:15

라이브러리를 만들어봐야하나

Feca [Web FE] 4월 7일, 오후 1:21

만들어서 opencollective에서 돈받기 ㄱㄱ

13:21

ㅋㅋ

Feca [Web FE] 4월 7일, 오후 2:02

!아카이브

멘션봇앱 4월 7일, 오후 2:02

스레드 아카이빙 중 오류가 발생했어요.

Error / 값이 비어 있어요.: Error: 값이 비어 있어요.
    at assertNonNullish (/home/feca_urssu/mention-bot/src/utils/assertion.ts:16:27)
    at parseAttachment (/home/feca_urssu/mention-bot/src/utils/archive.ts:270:3)
    at Array.map (<anonymous>)
    at transformToPreArchivedMessage (/home/feca_urssu/mention-bot/src/utils/archive.ts:359:31)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 26)
    at handleArchiveMessage (/home/feca_urssu/mention-bot/src/events/message.ts:195:33)
    at Array.<anonymous> (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:238:5)
    at Array.<anonymous> (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:288:5)
    at Array.onlyEvents (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:108:5)

(편집됨)

EATSTEAK [Web FE]

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

4월 6일, 오후 2:51

스레드

4월 17일, 오후 10:32 에 아카이브됨

EATSTEAK [Web FE] 4월 6일, 오후 2:51

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

50개의 댓글

Feca [Web FE] 4월 6일, 오후 3:17

일단 1번만 적어둠 2번은 고민좀 해봐야함

저는 딱 이정도까지만 고민해봤었던 것 같아요. 굳이 직관적으로 위임할 수 있는 asChild 를 두고 as로 갈 이유는 없다고 생각하긴 해요. (편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 3:20

저도 매우동의하는데 한가지 궁금한게

function ButtonWithContent({ asChild }: ComponentProps) {
  const Comp = asChild ? 'button' : Slot;
  return (
    <Comp>
      <Icon> hello
    </Comp>
  );
}

function ButtonAsLinkPage() {
  return (
    <ButtonWithContent asChild>
      <Link to="hello" />
    </ButtonWithContent>
  );
}

15:20

요런식으로 하면 <Icon> Hello가 그대로 전달되는 거죠? 사실 해보면 되긴 한데.. 이렇게 쓰는게 좋은 방법인가 궁금하기도 해서 물어봅니다

Feca [Web FE] 4월 6일, 오후 3:23

넹 그렇겠져? 아무래도 children 자체가 buttonwithcontent에 선언되어있으니까여

15:23

const Comp = asChild ? 'button' : Slot; 이거 바뀐거맞죠?

15:23

ㅋㅋㅋㅋ

EATSTEAK [Web FE] 4월 6일, 오후 3:23

아 걍 기억나는대로 막써서 걍 뇌이징부탁

15:23

ㅋㅋㅋ

Feca [Web FE] 4월 6일, 오후 3:24

애초에 저게 Slot delegation best practice로 알고있긴해요

EATSTEAK [Web FE] 4월 6일, 오후 3:24

솔직히 사용성 측면에서도 asChild가

인건 확실한듯요

Feca [Web FE] 4월 6일, 오후 3:30

흐으음 근데 2번은 뭔가 사례 자체가 감이 잘안오네요
어떤 group 컴포넌트에 value를 넣어주고 그걸로 자식들을 뭔가 슉슉하는거 같은데
추가 예시 가능?

15:31

아 value랑 매칭되는거만 렌더링한다는건가?

EATSTEAK [Web FE] 4월 6일, 오후 3:36

-> 이렇게 Link를 바로 렌더링해주는 기능을 직접 구현하려는데 두가지 방법 다 지원하는 컴포넌트를 만드는 방법이 뭐가 있을까 고민

Juun [Web FE Lead] 4월 6일, 오후 4:31

https://kciter.so/posts/render-delegation-react-component/ 글에 댓글로 이런 의견이 있네요

polymorphic (as prop)

polymorhpic은 단순하고 투명하다라는 점이 좋았어요.

런타임에서 해결시키는 기능들이 적고, 주로 props(i.e.As Props)로 소통 해요. 그래서 코드가 단순해지고 투명해져요. 작업자 누구나 as props가 어떤식으로 흘러가는지 쉽게 확인할 수 있는게 큰 장점이었어요.

만약 다른 프로젝트에서 도입을 해본다면 아래 내용들을 고려해볼 것 같아요.

• 컴포넌트의 껍데기에 다형적인 기능을 추가하는 것 외의 용도로 사용하려고 하면 코드관리가 어렵고, 특유의 순수성도 많이 헤치는 것 같아요. 그래서 atomic(예: header, button) 레벨의 요소에 적용해두는게 가장 적합해요.

• typescript를 사용한다면 컴포넌트 정의부에서 복잡한 타입을 정의해놔야해요. 작업자마다 타입에 대한 이해수준이 다를 수 있어서 거부감을 느낄 수 있어요. 저희팀은 MUI의 다형타입 유틸타입을 참고하여 다형타입을 정의해주는 유틸타입을 만들었어요.

Rendering Delegation (asChild)

rendering delegation은 런타임 기능들이 많아서 컴포넌트의 조합을 유연하고 우아하게 처리할 수 있는게 좋았어요.

만약 다른 프로젝트에서 도입을 해본다면 아래 내용들을 고려해볼 것 같아요.

• 컴포넌트의 기능이 완전히 정의된 상태에서는 이 방법이 유용해요. 하지만, 만약 기능 정의가 안된 컴포넌트에 무작정 asChild를 열어두면 혼란함을 야기할 것 같아요. 코드가 어떻게 적용되는지 불투명하다보니 '기준 기능 명세'가 없으면 불안해요.

• slottable한 시스템이 꼭 필요할지? : 생각보다 컴포넌트의 기능을 정의해두고 만드는 케이스가 많지 않아요 (팀마다, 디자인시스템 정책마다 다를 수 있어요). 그렇다면 굳이 공통화된 slottable한 시스템을 구축하기보단, 위 글에서 언급해주신 방법론들을 적절히 조합해서 사용하는게 더 유리할 수 있어요.

(편집됨)

Feca [Web FE] 4월 6일, 오후 4:36

쪼매 어렵네요 이거 ㅋㅋ

아무튼 이런 상황에 대해 다형성(일반화)을 갖는 방법에 대해 고민한걸로 이해할게요.

저도 좀 길게 고민해봤는데
저렇게 인터랙션에 대한 인터페이스가 완전히 다른 경우라면 (Link: href를 통함, Button: onClick 이벤트를 통함)

그래서 저는 차라리 새로운 컴포넌트를 만들거 같아용 SelectableLinkGroup 같은거... (편집됨)

16:37

16:38

[1,2,3].map(v => {
  const isSelected = query === v
  return <Link href={`/url?query=${value}`} {...뭐 여기서 이제 isSelected로 스타일 바꾸든 뭐하든} />
})

Juun [Web FE Lead] 4월 6일, 오후 4:57

2. 같은 경우에 Radix Ui Button 컴포넌트의 asChild 로 렌더링할 컴포넌트를 <Link/> 컴포넌트로 변경해서 해결할 수 있지 않을까요?

export function ComplexButtonGroupExample() {
  const [search] = useSearchParams();
  const query = useMemo(() => search.get("query") ?? "1", [search]);

  return (
    <ComplexButtonGroup>
      <Button asChild value="1">
        <Link to="/url?value=1"/>
      <Button/>
      <Button asChild value="2">
        <Link to="/url?value=2"/>
      <Button/>
      <Button asChild value="3">
        <Link to="/url?value=3"/>
      <Button/>
    </ComplexButtonGroup>
  );
}

(편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 5:08

그래서 ButtonGroup 내부의 버튼들에 대한 상태 감시를 그룹은 포기하고 각각의 children에게 위임하는게 제일 명확한 솔루션이지 않나 싶네요.

17:10

또 제 상황에서 좀 복잡한 쿼리 파라메터 핸들링 로직도 공통으로 재사용해야해서 Link를 감싸기로 함

17:10

감사합니다

Feca [Web FE] 4월 6일, 오후 5:10

난이도 개높네 ㄹㅇ

17:25

외부(searchParams)에 위임한거니 그룹 컴포넌트가 자식의 상태 변경 여부를 알면 안되겠다 싶었음.

ㄹㅇㅋㅋ
개인적으로 이게 허용되는 시점은 디자인시스템 급의 공통화가 아닌 이상 지양해야한다는 생각 (편집됨)

EATSTEAK [Web FE] 4월 6일, 오후 5:43

!아카이브

멘션봇앱 4월 6일, 오후 5:43

아카이빙을 완료했어요. [아카이브 링크] (편집됨)

EATSTEAK [Web FE]

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

4월 6일, 오후 2:51

useStorageState | Slash libraries

Feca [Web FE] 4월 7일, 오후 12:57

아 이거 다시보니까 생각났넹

• useSearchParamsState
https://gist.github.com/fecapark/72fd269f2aa6ba908b077b823abece88

• 다른 예로는 toss slash의 useStorateState
https://www.slash.page/ko/libraries/react/react/src/hooks/useStorageState.i18n (편집됨)

slash.page

useStorageState 는 브라우저의 스토리지에 영속적으로 저장되는 상태를 React에서 편리하게 다룰 수 있도록 도와주는 Hook입니다.

EATSTEAK [Web FE] 4월 7일, 오후 12:59

=> 그래서 굳이 Link 쓸 필요없이 그냥 상태 변경 액션처럼 처리해서 쿼리스트링 동기화 시켜버림

결국 이걸 채택 안한 가장 큰 이유는 사용자가 query params를 변경하는 액션을 할 때 programmatic routing이 아닌 link navigation을 통해 하도록 하기 위해서였음

예) Pagination 하는데 Ctrl+클릭으로 다음 페이지를 새 탭으로 열 수 없다면?

Feca [Web FE] 4월 7일, 오후 1:00

애초에 selectable한 input들 리스트에서 새탭으로 열필요가 없다는 생각
=> 다시보니 굳이 programmatic routing 을 사용해도 괜찮은 스펙이라고 느꼈음 (편집됨)

13:00

단순히 여기서 쿼리스트링을 도입한 이유는 선택한 인풋들에 대한 데이터 저장 목적이 크다고 느꼈음

EATSTEAK [Web FE] 4월 7일, 오후 1:05

일반적인 버튼 selection이라면 해당 어프로치가 맞다고 생각(이 경우에는 쿼리스트링을 안쓰는 게 더 나을수도)

Feca [Web FE] 4월 7일, 오후 1:10

그런데 굳이 하이퍼링크를 표시해줄 필요가 있을까 싶은게
저 버튼 자체가 컨텐츠가 바뀐다는 표시를 해줄거라고 예상하고 있었음

ex) 클릭하면 드롭다운 나오고 선택으로 필터링 가능한 목록 나오고, 선택하면 쿼리스트링 바뀌면서 컨텐츠 바뀌는거

13:11

그래서 충분히 마크업상으로 컨텐츠의 변경을 예상시켜줄 수 있다면 programmatic routing을 도입해도 큰 문제는 없을거 같다는 생각인데

13:11

잇스테이크 말도 납득이 되긴됨

EATSTEAK [Web FE] 4월 7일, 오후 1:11

스크린리더등 접근성 고려하면 베스트 프랙티스는 아니라고 생각

Feca [Web FE] 4월 7일, 오후 1:11

글킨하지

EATSTEAK [Web FE] 4월 7일, 오후 1:12

애초에 항상 페이지 브라우징 하면서 링크인척 하면서 아닌 버튼들에 빡친적이 너무 많아서 더 편집증적이긴 한건 ㅇㅈ

Feca [Web FE] 4월 7일, 오후 1:12

ㅋㅋㅋㅋㅋㅋ

EATSTEAK [Web FE] 4월 7일, 오후 1:12

근데 대부분 링크로 동작하는 사이트들은 잘 만든 사이트였음 (예: GitHub)

13:12

이걸 어떻게 링크로 만들었지? 라는 생각이 들 정도

Feca [Web FE] 4월 7일, 오후 1:13

시맨틱 HTML의 정수 그 자체

13:13

뭔가 SPA를 너무 많이봐서 그런가

13:13

13:14

근데 챙길수있다면 챙겨주는게 좋다는 생각이 한편으로는 또 강하게 듬

EATSTEAK [Web FE] 4월 7일, 오후 1:15

Feca [Web FE] 4월 7일, 오후 1:15

최종 사용자 동작 측면으로 봤을 때에는 전혀 단점이 없는 구현

고건 ㅇㅈ

EATSTEAK [Web FE] 4월 7일, 오후 1:15

라이브러리를 만들어봐야하나

Feca [Web FE] 4월 7일, 오후 1:21

만들어서 opencollective에서 돈받기 ㄱㄱ

13:21

ㅋㅋ

Feca [Web FE] 4월 7일, 오후 2:02

!아카이브

멘션봇앱 4월 7일, 오후 2:02

스레드 아카이빙 중 오류가 발생했어요.

Error / 값이 비어 있어요.: Error: 값이 비어 있어요.
    at assertNonNullish (/home/feca_urssu/mention-bot/src/utils/assertion.ts:16:27)
    at parseAttachment (/home/feca_urssu/mention-bot/src/utils/archive.ts:270:3)
    at Array.map (<anonymous>)
    at transformToPreArchivedMessage (/home/feca_urssu/mention-bot/src/utils/archive.ts:359:31)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Promise.all (index 26)
    at handleArchiveMessage (/home/feca_urssu/mention-bot/src/events/message.ts:195:33)
    at Array.<anonymous> (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:238:5)
    at Array.<anonymous> (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:288:5)
    at Array.onlyEvents (/home/feca_urssu/mention-bot/node_modules/.pnpm/@slack+bolt@4.2.1_@types+express@5.0.0/node_modules/@slack/bolt/src/middleware/builtin.ts:108:5)

(편집됨)

EATSTEAK [Web FE]

다들 Component Composition 어떻게 하시나요.

예) 같은 디자인, 내부 요소를 가진 컴포넌트이지만 사용처에 따라 시멘틱 의미가 달라지거나 다른 태그를 사용해야 할 때

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

이걸 일반화 하려면 어떤 식으로 사용하는 게 좋을까요?

제가 생각하는 to-be 는 아래랑 비슷한데, 이걸 구현하는 좋은 방법이나 아이디어 있으면 의견 부탁드려요.

import { ComplexButton } from "complex-button";
import { Link } from "react-router";

export function ButtonAsLink() {
  return (<>
    {/* radix style */}
    <ComplexButton asChild>
      <Link to="/link">
        Hello
      </Link>
    </ComplexButton>
    {/* `as` Style */}
    <ComplexButton as={Link} />
  </>);
}

4월 6일, 오후 2:51