계전기를 어떻게 사용해서 응용 프로그램에 대해 생각합니까

소개하다.


첫인상


내가 릴레이를 사용하기 시작했을 때, 나는 그것에 대한 첫인상이 좋지 않았다.나는 그것이 이해하기 어려웠고, 사용하기에 지루했고, 나는 그것의 좋은 점을 보지 못했다.
비록 나는 릴레이를 좋아하지 않지만 나는 한 팀의 일원이다. 한 팀으로서 우리는 릴레이를 견지하는 것을 선택한다. 장기적으로 보면 이것은 좋은 선택이 아니다.
시간의 추이에 따라 나는 그것과 지내기 시작했고 그것을 어떻게 사용하는지 이해하기 시작했다.나는 당시에 그것을 어떻게 써서 문제를 해결해야 할지 몰랐지만, 나는 아직 그것을 어떻게 써서 문제를 해결해야 할지 몰랐다.

책임 01 명


몇 달 후에 저는 기술 담당자로 승진되었고 그에 따른 책임은 우리 팀에게 우리가 왜 우리가 사용하고 있는 것을 사용하는지 이해하고 설명하는 것입니다.나는 도전에 부딪혔다.나는 왜 우리가 다른 것이 아니라 계전기를 사용하는지 이해해야 한다.
나는 다른 어떤 해결 방안과 마찬가지로, 만약 당신이 그것을 어떻게 사용하는지, 왜 사용하는지 모른다면, 당신은 그것으로 해결하려고 하는 문제와 마찬가지로 심지어 더 나쁜 문제에 직면하게 될 것이라고 믿는다.

본문


이 글은 왜 우리가 계전기를 사용하는지 이해하는 과정이다.Relay를 사용하여 응용 프로그램에 대해 생각하는 방법을 보여 드리겠습니다. 왜냐하면 Relay가 제공하는 다른 해결 방안을 이해하려면 우리가 현재 존재하는 문제점을 먼저 알아야 한다고 믿기 때문입니다.

릴레이가 뭐예요?


이것은 자바스크립트 프레임워크입니다. GraphQL 를 사용하여 전방에서 데이터를 얻는 과정을 간소화하려고 합니다.페이스북이 개발한 것으로, 리액트의 구성화 이념과 같은 구상이다.

반응 부품과 계전기


React에서 구성 요소의 배후 이념은 응용 프로그램을 구성 요소라고 불리는 작은 부분으로 나누어 응용 프로그램의 복잡성을 낮추는 것이다.이러한 구성 요소들은 이해하기 쉽고 유지하기 쉬워 응용 프로그램의 확장성을 향상시켰다.

And how does that relates to Relay?


Relay의 이면에는 다음과 같은 이유로 데이터 종속성을 구성 요소와 함께 구성하는 것이 좋습니다.
  • 구성 요소 작업에 필요한 데이터를 이해하기 쉽다.
  • 구성 요소가 서버에서 다른 데이터를 필요로 하는 경우 전체 query 구조를 변경할 필요가 없고 구성 요소만 변경하면 됩니다.(모든 사례가 그렇지는 않지만 대부분의 사례가 그렇다)
  • 전체 구조와 분리된 구성 요소를 테스트하는 것이 더욱 쉽다.
  • 어떻게 계전기를 사용합니까?


    이를 이해하기 위해 다음 유튜브 페이지를 살펴보겠습니다.

    우리는 그것을 네 개의 구성 요소로 나누어 서버에서 데이터를 받을 수 있다.

  • 우리는 동영상을 렌더링하는 데 쓰인다.서버의 VideoPlayer가 필요할 수 있습니다.
  • videoSrc: 제목, 설명, 작성자, 좋아하고 싫어하는 수량과 같은 비디오 세부 정보를 표시합니다.
  • VideoDetails: 유튜브 알고리즘이 보고 싶다고 생각하는 동영상 목록입니다.
  • RelatedVideos: 기록된 사용자 프로필 이미지를 보여줍니다.

  • Just remembering that all of that it's just an example. For sure the real YouTube architecture it's much more complex than this.


    이 구성 요소들을 감안하면, 우리는 두 가지 방법으로 중계를 사용하여 서버에서 데이터를 얻는다.

    1. 각 구성 요소에서 필요한 데이터 가져오기


    우리는 이 해결 방안을 나타내는 도표를 그릴 수 있다.

    왼쪽에는 간략한 유튜브 페이지가 있습니다.각 구성 요소는 다음과 같이 UserImg 쿼리를 통해 서버를 호출하는 회색 원으로 표시됩니다.
    graphql`
      query NavbarQuery {
        user {
          profileImg {
            src
          }
        }
      }
    `
    

    이익.


    이 해결 방안이 있으면 프로그램의 모든 부분에 다른 마운트 표시기를 표시할 수 있습니다.예를 들면 다음과 같습니다.

    이렇게 함으로써 우리는 사용자 체험을 개선했고 그가 화면에 접근하는 것을 완전히 막지 않았으며, 우리가 어떤 데이터를 얻고 있는지, 우리가 어떤 데이터를 얻었는지 보여 주었다.

    Here's an article explaining why you should use loading skeletons in your interface.


    결점


    첫 번째 문제는 트리 구조와 관련이 있는데, 그 중 하나는 다른 구성 요소에 의존하여 렌더링을 한다.예를 들어 동영상을 보여주기 위한 구조를 살펴보자.

    여기에서, 우리는 구성 요소 GraphQL 가 완전히 렌더링될 때만 videoSrc 를 사용하여 데이터를 가져옵니다.만약 어떤 이유VideoPlayer로 인해 위의 모든 구성 요소가 불러오는 데 시간이 오래 걸린다면, 우리는 서버를 호출하고 동영상을 불러올 수 있을 때까지 이 시간을 기다려야 한다.
    이렇게 하면 우리는 두 번의 시간을 가지고 동영상을 불러올 수 있다.
  • 렌더링 VideoPlayer 위의 어셈블리.
  • 사용VideoPlayer 데이터는 response에서 수신server.
  • 또 다른 문제는 최종적으로 서버에 대량의 요청을 할 것이며, 그 중 모든 요청은 데이터의 일부분만 요청할 것이다.서버와의 연결이 열리면 필요한 모든 데이터를 요구할 수 있습니다.

    Ok, so we have these two problems. What it's the alternative?


    2. 제안된 솔루션


    우리는 모든 구성 요소에서 데이터를 얻는 것이 아니라, 페이지를 불러올 때 한 번씩 가져옵니다. 다시 말하면, 모든 페이지는 하나의 조회입니다.

    But didn't you said that Relay is built on colocating the data dependencies with the components that need them?


    네.내가 videoSrc라고 말했을 때fetch 함수가 아니라 필요한 데이터에 대한 성명을 가리킨다.우리는 페이지가 나타날 때만 한 번 가져옵니다.이렇게 생겼어요.

    이익.


    이렇게 하면, 우리는 페이지를 불러올 때 페이지에 필요한 모든 데이터를 보여 주어야 한다.다음과 같은 이점이 있습니다.
  • 서버에 대한 요청량을 줄였습니다.
  • 구성 요소가 불러오기를 기다리지 않았기 때문에 사용자에게 관련 데이터를 표시하기 위해 불러오는 시간을 줄였습니다.
  • 세션으로 데이터 의존항을 분류하다


    비슷한 구성 요소의 데이터 의존항을 연합하기 위해서 우리는 data dependenciesRelay를 사용할 수 있다.
    AFragments, inFragment은 특정 구성 요소에 필요한 데이터에 대한 설명입니다.
    이것은 우리가 모든 구성 요소를 추출하는 것과 같지만, 추출이 아니라 필요한 데이터만 설명하고, 추출은 한 번만 발생합니다.구현 프로세스는 다음과 같습니다.
    // page component
    graphql`
      query PageQuery {
        user {
          ...NavbarFragment_user
        }
      }
    `
    
    // navbar component
    graphql`
      fragment NavbarFragment_user on UserType {
        profileImg {
          src
        }
      }
    `
    
    이런 방식을 통해 Relay 그것이 무엇을 필요로 하는지 정확하게 설명하고, 만약 어떤 변화가 있다면, 우리는 부분적으로만 바꿀 뿐, 페이지 조회에서는 바꾸지 않을 것이다.

    Even though this is nice, we have a problem :(


    결점

    Navbar10 버전에서 우리는 모든 구성 요소Relay를 가지고 있을 수 없다. 사용자에게 일부 데이터를 표시하기 전에 전체 페이지에 loading indicator를 표시해야 한다. 아래와 같다.

    이 문제를 해결하는 데는 두 가지 방법이 있다.
    이 문제를 해결하기 위해 첫 번째 방법을 사용할 수 있습니다. 구성 요소마다 하나 loading indicator 를 호출합니다. 비록 이 fetch 는 응답을 되돌려 주지 않지만, 하나 fetch 를 표시합니다.
    또 다른 방법은 제가 추천하는 방법입니다. 계전기를 버전 11로 업그레이드하고 loading indicator로부터@defer 명령과 GraphQL로부터Suspense 부품을 사용하기 시작합니다.React 명령을 사용하면 @defer의 특정한 부분, 예를 들어 query을 비동기적으로 불러와야 합니다. 이 부분의 응답은 서버에서 되돌아오지 않지만 fragment 구성 요소에 전달되는 loading indicator를 보여 줍니다.

    Here's the Relay documentation where they explain in more details how to do that and in this video how they're using that on Facebook.


    결론

    Suspense가 그랬듯이 React는 여전히 많이 사용되지 않는 라이브러리이기 때문에 어떻게 작동하는지 설명하는 글과 강좌가 별로 없다.
    나는 정말 이 글이 당신이 응용 프로그램에서 어떻게 사용하는지Relay나 그 주요 사상에 대한 이해를 증진시킬 수 있기를 바랍니다.
    더 기술적인 해석을 놓치거나 내가 대답하지 않은 질문이 있다면 언제든지 대답하세요🤙

    좋은 웹페이지 즐겨찾기