Props에서 익명 함수 사용을 중단하세요!-JS 튜토리얼-php.cn

Quit Using Anonymous Functions in Props!

글쎄요, 제목이 좀 클릭 미끼 같군요. 익명 함수를 props로 사용해야 할 때가 있지만 아마도 그 양은 훨씬 적을 것입니다. 하지만 먼저 문제를 설명해 보겠습니다.

소품으로서의 익명 함수

Svelte 및 React와 같은 구성 요소 라이브러리에서 구성 요소 props로 사용되는 익명 함수는 더 큰 규모로 부풀려질 위험이 있는 일종의 게으른 기능이 되었습니다.

많은 개발자가 이렇게 하는 것을 봅니다.

<button onclick={() => handleSubmit()}>Submit</button>

로그인 후 복사

대신:

<button onclick={handleSubmit}>Submit</button>

로그인 후 복사

이러한 각 코드 블록은 말 그대로 정확히 동일한 결과를 달성합니다. 유일한 차이점은 첫 번째 예에서는 익명 함수가 삽입되었으며 이 함수가 수행하는 작업은 인수 없이 명명된 함수를 호출하는 것뿐입니다.

익명 접근 방식을 사용하는 것이 왜 문제가 될 수 있는지 아시나요? 이 버튼이 렌더링될 때마다 새로운 익명 기능이 생성되어 메모리에 보관됩니다. 동일한 페이지에 10개의 이러한 함수가 렌더링되면 메모리에 10개의 고유한 익명 함수가 유지됩니다.

이제 "그럼 페이지에 10~20개 이상의 대화형 요소가 표시되는 경우가 얼마나 자주 있을까요?"라고 생각할 수 있습니다. 그리고 대답은 "이것이 극단적인 경우라고 생각할 수도 있지만 생각보다 많은 문제가 발생합니다. 그리고 좋은 습관을 가지고 위기에 대비할 수도 있습니다!"입니다.

이 문제가 발생할 수 있는 대표적인 예는 행이나 항목 삭제 또는 편집과 같은 대화형 기능이 있는 대규모 테이블이나 목록에서입니다. 예를 들어 페이지에 데이터 그리드 유형의 구성 요소가 있고 이에 대한 페이지 매김이 페이지당 100개 행이라고 가정하면 각 행에서 생성되는 익명 함수는 100번 존재하게 됩니다. 편집 및 삭제 버튼과 함께 모든 행에 작업을 수행하는 확인란이 있는 경우 이제 이름을 지정하고 선언한 원래 3개의 함수와 함께 익명 함수에 의해 호출되는 300개의 익명 함수가 메모리에 보관됩니다.

사전 렌더링과 같은 속임수를 사용하지만 효율성을 위해 데이터의 다음 페이지를 숨기는 것은 더 나쁩니다. 이 예에서는 이제 메모리에 600개의 익명 함수 인스턴스가 있습니다.

좋아요, 그렇다면 사람들은 왜 이런 일을 할까요?

이러한 습관이 그토록 널리 퍼져 있고 뿌리 깊은 데에는 적어도 두 가지 이유가 있다고 생각됩니다.

반응성 또는 기타 원하는 동작

적어도 Svelte에서는 함수가 반응적으로 호출되도록 하기 위해 이 작업을 수행해야 하는 경우가 있습니다. 논리가 예상대로 작동하도록 하기 위해 이 작업을 수행해야 하는 다른 유형의 상황이 있을 수 있습니다. 비록 제가 React로 작업한 지 몇 년이 지났지만 해당 라이브러리에도 비슷한 예가 있을 것이라고 확신합니다.

그러나 이는 코딩하는 동안 필요에 따라 해결할 수 있는 극단적인 경우입니다.

함수 매개변수 전달 단순화

이 사람이 가장 흔한 범인일 것 같습니다. 일종의 상태를 함수에 직접 전달할 수 있으므로 Svelte 또는 React와 같은 UI 라이브러리를 처음 배울 때 파악하고 작업하는 것이 더 쉽습니다. 이것이 아마도 대부분의 튜토리얼에서 익명 함수를 소품으로 표시하는 이유일 것입니다.

다음은 예시입니다(Svelte 5):

<button onclick={() => handleSubmit()}>Submit</button>

로그인 후 복사

깔끔하고 좋죠? 하지만 이 페이지에 이 버튼의 인스턴스가 수백 개 있으면 잠재적인 성능 문제가 발생합니다. 잠재적으로 더 나은 성능을 발휘하도록 리팩토링하려면 어떻게 해야 합니까?

더 간단한 솔루션

프로그래밍에서 흔히 그렇듯이 간단하고 간단한 해결책은 EditButton과 같은 개별 구성 요소를 만든 다음 해당 인스턴스에만 productId 범위를 지정하는 것입니다. 따라서 핸들러 함수는 해당 productId가 무엇인지 이미 알고 있는 개별 구성 요소 내에 있기 때문에 핸들러 함수에 아무것도 전달할 필요가 없습니다. 이것이 코드가 모놀리식보다 모듈식이면 일반적으로 좋은 이유입니다.

가능하다면 먼저 이 솔루션을 시도해야 합니다. 그리고 우리 구성 요소는 하나의 productId만 처리하도록 격리되어 있으므로 해당 익명 함수는 필요하지 않습니다. 대신 우리의 컴포넌트 기능이 이를 직접 처리할 수 있습니다.

<button onclick={handleSubmit}>Submit</button>

로그인 후 복사

더욱 복잡한 솔루션

하지만 시스템 아키텍처 등으로 인해 업데이트 로직을 이와 같이 로컬 규모로 제한할 수 없는 경우가 있습니다. 이런 종류의 상황을 처리하기 위해 우리는 조금 더 복잡한 작업을 수행합니다. 말하기는 싫지만 익명 함수를 prop으로 보내는 것보다 약간 덜 선언적입니다. 하지만 이는 여전히 읽기 쉽고 많은 익명 기능을 메모리에 푸시하지 않는다는 목적에 부합합니다.

처리 중인 이벤트(예: 클릭)를 가져오는 html 요소에 데이터 속성을 사용하는 것이 포함됩니다. 그리고 그것은 다음과 같습니다:

// EditButton.svelte

<script>  
  // productId is sent to this component as a prop
  let { productId } = $props()
</script>

const onEditToggle = (productId) => {
  // Do some stuff with productId...
}

<button onclick={() => onEditToggle(productId)}>
  Edit
</button>

로그인 후 복사

거기서 무슨 일이 일어나고 있는지 보셨나요? EditButton 내부의 html 버튼 요소에 있는 사용자 정의 데이터 속성에 제품 ID를 넣습니다. 핸들러 함수가 실행되면 요소의 데이터 속성에서 바로 제품 ID를 검색할 수 있습니다.

이제 메모리에 선언된 onEditToggle 함수 하나만 있고 다른 모든 함수는 참조로 이를 가리킵니다.

가독성과 성능 사이의 균형

개인적인 느낌은 구성 요소를 모놀리식으로 만들고 이 모든 것을 내부적으로 결정해야 하는 대신 항상 잘 모듈화된 코드로 시작하여 핵심 데이터가 소품을 통해 해당 구성 요소에 바로 전달되도록 하는 것입니다. 이것이 바로 위의 "더 간단한 솔루션"에서 설명하고 있는 내용입니다.

절대 그렇게 할 수 없다면 데이터 속성이 있는 두 번째 솔루션을 선택하세요.

이제 anon 함수를 사용하는 것이 데이터 속성을 처리하는 것보다 조금 더 읽기 쉽기 때문에 시작하는 것이 더 낫다고 주장할 수 있습니다. 따라서 성능 문제가 발생하면 나중에 조정하면 됩니다.

저는 일반적으로 그런 생각에 동의하지만, 이것은 항상 같은 방식으로 수행할 만큼 흔한 합병증 중 하나입니다. 이렇게 하면 한 접근 방식을 다른 접근 방식과 비교하여 사용할지 여부와 시기를 생각할 필요가 없습니다. 둘 다 작동하며, 이러한 성능 문제가 발견되더라도 나중에 리팩토링이 필요하지 않습니다.

마지막으로 주의사항

Svelte가 변환 중에 이러한 anon 기능을 원활하게 처리하기 위해 어떻게든 이를 처리하는 것은 전적으로 가능합니다. 나는 Svelte의 런타임이나 컴파일러에 대해 확실히 말할 만큼 전문가가 아닙니다. 하지만 저는 개인적으로 이것이 사용하게 될 모든 JS 라이브러리에 적용되는 더 안전한 패턴이라고 생각하므로 미리 채택하는 것이 더 나은 습관입니다.

어떻게 생각하세요? 대위법이 있나요? 아니면 내 의견을 바꿀 수 있는 Svelte를 사용하여 런타임 및 컴파일 수준에서 어떤 일이 발생하는지에 대한 통찰력을 제공할 수 있습니까? 댓글로 알려주세요!

위 내용은 Props에서 익명 함수 사용을 중단하세요!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!