okay summarize this script using the same style you did for "hook in react"

script:

So far you have learned about a technique called higher order components that is used to encapsulate common functionality, but it's not the only one available to you. For example, you can choose between different eating utensils depending on the type of food you're eating. Some chopsticks for your favorite sushi dish or a fork for a delicious carbonara. But there's nothing wrong with using a fork for eating sushi after all. Not everyone has learned how to use chopsticks and it's the tool that makes the job easier that matters. Well, this is also the case when it comes to code reusability. There are several tools you can use to share code between react components, and in this video you are going to be introduced to a new one, the render props pattern. Say the Little Lemon Restaurant is looking for a way to keep count of all the items it has on the menu. They would like to display this information in the application so they know when they need to replenish stock and to make it easier for customers to see what is or isn't available at any given time. That information is stored on a server. So we would have to be fetched first prior to displaying it. There are various ways to define the fetching logic like a higher order component. However, render props is also a powerful technique you can leverage to reuse common code. The render props technique is so appropriately named that it's almost self explanatory. It's about using a prop called render with a particular attribute that it has to be a function. To be more precise, a component with a render prop takes a function that returns a react element and calls that function inside its render logic. For example a meal provider component could use this pattern if you remember a higher order component enhanced a component by providing new props into it with render props. However the new props are injected dynamically as the parameter of the function. You may already have recognized some similarities between the two. The end goal is the same to enhance components without modifying their original implementation. The way in which they inject those new props or enhancements is what differs to better illustrate this point. Let's explore an application that showcases the implementation of a component that uses a render prop in this example the little lemon restaurant would like to keep account of all the desserts and drinks that it has in the menu. That information will need to be fetched from a server that they control and displayed in the application with a single piece of text. The logic for fetching data is one example of a cross cutting concern. Multiple components may depend on data that lives somewhere else but you don't want to implement the same fetching logic over and over in every component that needs it. Right this is a good place to use the render props pattern to abstract this functionality to showcase how it works. I have created a component called data fetcher whose only purpose is to fetch data based on a U. R. L. This is one of its props but it's the second one that should catch your attention and that's the render prop. I'm not fetching real data in this example but I have created a mock if else statement that will return either a list of all desserts or drinks available based on the U. R. L. Path as usual. This fetching logic is a side effect that should be placed inside use effect. Finally let's move to the return statement. This is the unusual part. The component is returning the result of calling the render function and has no other rendering business. This is what makes it very flexible. Data fetcher only has one purpose fetching data and the way they receive it is via the argument in the render function which is the local state used to store the list of desserts or drinks. It's then up to the developers to decide how they would like to present that data on the screen. Finally, let's explore the two presentational components. I have defined to show the number of desserts and drinks available in the menu. The desserts count component uses a particular endpoint to fetch desserts and uses a paragraph element as the render prop, displaying the number of desserts as a single text. The same applies to the drinks count component with the difference being that he utilizes another U. R. L. And instead shows a header element reflecting the number of drinks.
좋아, "hook in react"에서 했던 것과 같은 스타일로 이 스크립트를 요약해 보세요.스크립트에서와 동일한 스타일로 요약합니다:지금까지 일반적인 기능을 캡슐화하는 데 사용되는 고차 컴포넌트라는 기법에 대해 배웠지만, 이 기법만 사용할 수 있는 것은 아닙니다. 예를 들어, 먹는 음식의 종류에 따라 다양한 식사 도구 중에서 선택할 수 있습니다. 좋아하는 스시 요리에는 젓가락을, 맛있는 까르보나라에는 포크를 사용할 수 있습니다. 하지만 초밥을 먹을 때 포크를 사용하는 것이 잘못된 것은 아닙니다. 모든 사람이 젓가락 사용법을 배운 것은 아니며 중요한 것은 일을 더 쉽게 만들어주는 도구입니다. 코드 재사용성 측면에서도 마찬가지입니다. 리액트 컴포넌트 간에 코드를 공유하는 데 사용할 수 있는 몇 가지 도구가 있는데, 이 비디오에서는 새로운 도구인 렌더 소품 패턴을 소개합니다. 리틀 레몬 레스토랑이 메뉴에 있는 모든 아이템의 개수를 세는 방법을 찾고 있다고 가정해 봅시다. 이 정보를 애플리케이션에 표시하여 재고를 보충해야 하는 시기를 파악하고 고객이 특정 시점에 어떤 메뉴가 있는지 쉽게 확인할 수 있도록 하려는 것입니다. 이 정보는 서버에 저장됩니다. 따라서 이를 표시하기 전에 먼저 가져와야 합니다. 고차 컴포넌트처럼 가져오기 로직을 정의하는 방법에는 여러 가지가 있습니다. 하지만 렌더 소품은 공통 코드를 재사용하는 데 활용할 수 있는 강력한 기법이기도 합니다. 렌더 소품 기법은 이름만 들어도 알 수 있을 정도로 적절하게 명명되었습니다. 렌더라는 소품을 함수여야 한다는 특정 속성을 가진 렌더라는 소품을 사용하는 것입니다. 더 정확히 말하면, 렌더링 프로퍼티가 있는 컴포넌트는 반응 엘리먼트를 반환하는 함수를 취하고 렌더링 로직 내에서 해당 함수를 호출합니다. 예를 들어 식사 제공자 컴포넌트는 상위 컴포넌트가 렌더링 프로퍼티로 새로운 프로퍼티를 제공함으로써 컴포넌트를 향상시킨 것을 기억한다면 이 패턴을 사용할 수 있습니다. 하지만 새 소품은 함수의 파라미터로 동적으로 주입됩니다. 이미 두 가지의 유사점을 알아차리셨을 것입니다. 원래 구현을 수정하지 않고 컴포넌트를 향상시킨다는 최종 목표는 동일합니다. 이 점을 더 잘 설명하기 위해 새로운 소품이나 향상된 기능을 주입하는 방식이 다릅니다. 이 예제에서 렌더 소품을 사용하는 컴포넌트의 구현을 보여주는 애플리케이션을 살펴보겠습니다. 리틀 레몬 레스토랑에서 메뉴에 있는 모든 디저트와 음료에 대한 정보를 유지하고자 합니다. 이러한 정보는 제어하는 서버에서 가져와서 애플리케이션에 텍스트 한 줄로 표시해야 합니다. 데이터를 가져오는 로직은 교차 절단 문제의 한 예입니다. 여러 컴포넌트가 다른 곳에 있는 데이터에 의존할 수 있지만, 이를 필요로 하는 모든 컴포넌트에 동일한 가져오기 로직을 반복해서 구현하고 싶지는 않을 것입니다. 바로 이 지점이 렌더 소품 패턴을 사용하여 이 기능을 추상화하여 작동 방식을 보여줄 수 있는 좋은 장소입니다. 저는 데이터 페처라는 컴포넌트를 만들었는데, 이 컴포넌트의 유일한 목적은 U. R. L. 기반 데이터를 가져오는 것입니다. 이 컴포넌트도 소품 중 하나이지만, 여러분이 주목해야 할 두 번째 소품이 바로 렌더링 소품입니다. 이 예제에서는 실제 데이터를 가져오는 것이 아니라 평소와 같이 U. R. L. 경로를 기반으로 사용 가능한 모든 디저트 또는 음료 목록을 반환하는 모의 if else 문을 만들었습니다. 이 가져오기 로직은 사용 효과 안에 배치해야 하는 부수 효과입니다. 마지막으로 반환문으로 이동해 보겠습니다. 이것이 특이한 부분입니다. 컴포넌트는 렌더링 함수를 호출한 결과를 반환하고 있으며 다른 렌더링 비즈니스는 없습니다. 이것이 바로 이 컴포넌트를 매우 유연하게 만드는 이유입니다. 데이터 페처는 데이터를 가져오는 목적이 하나뿐이며, 데이터를 받는 방식은 디저트 또는 음료 목록을 저장하는 데 사용되는 로컬 상태인 렌더링 함수의 인수를 통해 이루어집니다. 그런 다음 해당 데이터를 화면에 표시할 방법을 결정하는 것은 개발자의 몫입니다. 마지막으로 두 가지 프레젠테이션 컴포넌트를 살펴봅시다. 메뉴에서 사용 가능한 디저트와 음료의 수를 표시하도록 정의했습니다. 디저트 개수 컴포넌트는 특정 엔드포인트를 사용하여 디저트를 가져오고 단락 요소를 렌더링 프로퍼티로 사용하여 디저트 개수를 단일 텍스트로 표시합니다. 음료 수 컴포넌트에도 동일하게 적용되지만 다른 U. R. L.을 사용하고 대신 음료 수를 반영하는 헤더 요소를 표시한다는 차이점이 있습니다.