DE{CODE}: 구텐베르크 및 헤드리스 WordPress

WordPress 차단이라고도 하는 Gutenberg는 콘텐츠 제작자에게 기존 WordPress 사이트에서 콘텐츠를 배치할 수 있는 강력하고 새로운 방법을 제공합니다. 그러나 헤드리스 WordPress 개발자가 동일한 기능으로 마케팅 팀을 강화할 수 있는 방법은 무엇입니까? 이 DE{CODE} 세션에서는 WordPress용 GraphQL(WPGraphQL)의 창립자인 Jason Bahl이 헤드리스 사이트에서 WordPress 블록 편집기를 사용하기 위한 새로운 기능과 모범 사례를 공유합니다.

세션 슬라이드

전체 텍스트 성적 증명서

제이슨 발 : 안녕하세요. Gutenberg 및 Headless WordPress에 대한 제 강연에 오신 것을 환영합니다. 제 이름은 제이슨 발입니다. 저는 WPGraphQL의 생성자이자 관리자입니다. 저는 WP Engine의 수석 소프트웨어 엔지니어입니다. Twitter @jasonbahl 또는 Twitter @wpgraphql에서 저를 찾을 수 있습니다.

그래서 오늘 저는 구텐베르크가 무엇인지, 헤드리스 워드프레스가 무엇인지, 헤드리스 워드프레스를 언제, 왜 사용해야 하는지, 구체적으로 헤드리스 워드프레스와 함께 구텐베르크를 사용할 수 있는 방법, 헤드리스 워드프레스와 구텐베르크를 언제, 왜 사용해야 하는지에 대해 이야기하고 싶습니다. 함께 프로젝트에 적합할 수 있습니다.

따라서 WordPress에는 역사적으로 이와 비슷한 편집기가 있었습니다. 콘텐츠를 편집할 수 있는 TinyMCE 텍스트 영역이 있습니다. 우리는 미디어를 삽입한 다음 콘텐츠를 게시할 수 있으며 2018년에는 이 빈 캔버스에 콘텐츠를 삽입하고 블록 수준에서 콘텐츠와 상호 작용할 수 있는 이 블록 기반 편집기인 Gutenberg가 등장했습니다.

따라서 각 단락에는 설정이 있습니다. 각 이미지에는 설정이 있습니다. 각 갤러리, 제목 – 콘텐츠에 대해 생각할 수 있는 모든 것이 블록이라고 합니다. 이제 콘텐츠를 제어하는 ​​방법에 대해 정말 세분화할 수 있으며 콘텐츠를 드래그 앤 드롭하고 구성할 수 있습니다. 이제 WordPress의 매우 풍부한 편집 경험이므로 Gutenberg가 무엇인지에 대한 입문서입니다.

그렇다면 이제 Headless WordPress는 무엇입니까? Headless를 이해하기 위해 전통적인 WordPress를 살펴보겠습니다. 전통적인 WordPress에서는 관리 UI인 WordPress에 로그인하고 콘텐츠를 게시한 다음 사용자가 사이트를 방문하고 WordPress에 내장된 언어인 PHP가 페이지를 렌더링합니다. 따라서 CSS, HTML 및 JavaScript를 로드하고 페이지를 사용자에게 전달합니다. 이것이 일종의 전통적인 WordPress입니다.

Headless WordPress를 사용하면 여전히 WordPress를 CMS로 사용합니다. 여전히 WordPress에서 콘텐츠를 게시하고, 콘텐츠를 관리하고, 콘텐츠를 관리하지만 HTML 페이지를 브라우저에 전달하는 대신 WordPress는 일반적으로 JSON 형식으로 데이터를 전달한 다음 클라이언트 애플리케이션에서 해당 데이터를 사용할 수 있으므로 네이티브 iOS 또는 Android 애플리케이션을 사용할 수 있습니다. 또는 가상 현실 응용 프로그램.

제 동료인 Anthony는 WordPress를 사용하여 가상 현실 애플리케이션을 강화하는 방법에 대한 콘텐츠를 공유했습니다. 또는 인쇄 신문의 진입점으로 WordPress를 사용하는 신문사에서 일했습니다. 따라서 인쇄된 신문의 하드카피를 읽는다면 WordPress에서 제작된 콘텐츠를 읽는 것입니다.

물론 이 데이터를 사용하여 웹에 렌더링할 수도 있지만 PHP 템플릿에 얽매이지 않고 원하는 프런트 엔드 기술을 유연하게 선택할 수 있습니다. 따라서 Headless는 백엔드, 콘텐츠 관리 및 WordPress에서 관리되는 데이터를 표시하는 방법을 분리합니다.

따라서 이 데이터를 사용할 수 있는 두 가지 일반적인 방법이 있습니다. WordPress에 내장된 API인 WP REST API에서 JSON 형식의 데이터를 가져올 수 있으며 WPGraphQL이라는 또 다른 API가 있습니다. WordPress 및 JSON에서 데이터를 설치하고 가져올 수 있는 오픈 소스 플러그인입니다. 오늘은 WPGraphQL에 대해 이야기하겠습니다.

이제 WordPress가 무엇인지 알았으니 왜 Headless WordPress 프로젝트를 구축해야 할까요? 내가 언급했듯이 프론트 엔드 기술을 선택할 때 많은 유연성이 있습니다. 어떤 사람들에게는 프런트 엔드 프로젝트를 구축하는 방법을 선택할 수 있는 것이 매우 중요합니다. Next, Gatsby, Svelte와 같이 향상된 핵심 웹 바이탈을 목표로 하는 일부 프레임워크가 있습니다. 따라서 WordPress로 Headless를 사용하고 핵심 웹 바이탈을 개선할 수 있습니다.

코드에서 코드 분할과 같은 이점을 얻을 수 있습니다. 따라서 프런트 엔드 애플리케이션용 구성 요소를 빌드할 수 있습니다. 그리고 특정 페이지에 대해 어떤 구성 요소가 구축되고 있는지에 따라 더 낮거나 적은 자산을 클라이언트에 보내고 페이지 속도를 높일 수 있습니다. 헤드리스는 또한 개발자가 프런트 엔드 사용자 경험을 보다 세밀하게 제어할 수 있도록 하므로 WordPress 관리자에 설치된 플러그인이 프런트 엔드에 미치는 영향이 적습니다.

따라서 관리자 사용자는 플러그인을 설치하고 헤드리스 사이트의 프런트 엔드에 임의의 스크립트 또는 임의의 마크업을 추가할 수 없습니다. 개발자가 프런트 엔드에 대한 제약을 정의하고 WordPress가 전송된 데이터를 받은 다음 제가 입력하고 싶은 것 중 하나는 개발자 경험입니다.

Headless WordPress를 사용하면 원하는 기술 스택을 유연하게 사용할 수 있으므로 경우에 따라 더 나은 개발자 경험이라는 이점이 있습니다. 제가 다룰 사례 중 하나는 구성 요소 기반 개발이라고 하며 잠시 후에 이에 대해 많은 이야기를 나누겠습니다.

이것이 몇 가지 이유입니다. 헤드리스 워드프레스를 사용하고 싶을 때 어떤 상황에 처할 수 있습니까? 음, 기본 모바일과 같은 웹이 아닌 애플리케이션을 빌드해야 하는 경우 Headless로 이동하고 싶을 것입니다. 다시 말하지만, 핵심 웹 바이탈이 WordPress 사이트, 현재 WordPress 사이트에서 좋지 않거나 괜찮지만 좋은 상태로 유지하는 데 비용이 많이 드는 경우 Headless를 고려할 수 있습니다.

WordPress에서 데이터를 가져와야 하는 조직에 여러 애플리케이션이 있는 경우 Headless도 전환해야 할 수 있습니다. 그리고 조직을 위한 구성 요소 라이브러리 또는 구성 요소 기반 디자인 시스템에 이미 투자했으며 WordPress의 데이터가 필요한 경우 Headless에 투자하는 것이 좋습니다. 팀이 JavaScript를 선호하고 PHP로 빌드하는 것을 좋아하지 않는다면 Headless를 고려해야 하는 이유이기도 합니다.

그러나 헤드리스로 가고 싶지 않은 몇 가지 이유는 현재 개발 시간이 약간 더 필요하다는 것입니다. 따라서 예산이 적거나 시간을 축소하고 기존 WordPress에 이미 솔루션이 있는 경우 아직 헤드리스로 전환하지 않을 수 있습니다. 사이트 관리자가 프런트 엔드를 수정하는 플러그인 설치를 제어해야 하는 경우 아직 헤드리스로 전환하지 않을 수 있습니다.

팀이 PHP를 정말로 선호하고 JavaScript 또는 대체 프런트 엔드를 배우고 싶지 않다면 기존 WordPress를 고수할 수도 있습니다. 구성 요소 기반 개발 또는 구성 요소 기반 라이브러리에 투자하지 않은 경우 관심이 없다면 기존 WordPress 개발 워크플로를 고수할 수 있습니다.

그리고 기존 WordPress의 핵심 웹 바이탈이 정말 훌륭하고 유지 관리 비용이 매우 낮아 웹 사이트를 매우 빠르게 실행하는 경우 기존 WordPress를 고수해도 괜찮을 수 있습니다. 따라서 헤드리스로 갈 필요가 없습니다. 하지만 Headless가 일부 팀에 좋을 수 있다고 생각하는 이유를 보여드리겠습니다.

따라서 WordPress 개발자 경험을 다시 살펴보면 큰 HTML 덩어리를 생성하는 한 필드에 콘텐츠를 게시합니다. 이러한 세분화된 블록이 있는 Gutenberg 편집기를 사용하더라도 최종 결과는 하나의 큰 HTML 덩어리입니다. 따라서 Gutenberg에서 게시하든 전통적인 고전 편집기에서 게시하든 이 HTML 덩어리는 PHP를 통해 테마로 전송되며 HTML, CSS 및 JavaScript를 로드하는 하나의 글로벌 페이지를 갖게 됩니다. 그리고 이러한 자산은 전역적으로 페이지에 적용됩니다.

따라서 WordPress 개발자는 일반적으로 파일 유형에 따라 개발을 분리하므로 CSS를 페이지에 전체적으로 적용되는 별도의 파일에 넣거나 HTML이 PHP로 작성되고 WordPress에서 필요한 데이터를 가져온 다음 JavaScript가 별도의 파일에 jQuery를 사용하여 자주 작성해야 합니다. 그래서 이 세 가지가 모여서 페이지를 만들 것입니다.

문제는 이것들이 분리되지 않고 전체 페이지에 적용된다는 것입니다. 그래서 때때로 당신은 변화를 만들 수 있습니다. 나에게 이런 일이 일어났습니다. 한 번은 관리자의 요청에 따라 사이트 바닥글의 스타일을 변경하고 3일 후에 해당 패스 코드 검토로 인해 사이트의 다른 곳에서 스타일이 변경되었다는 보고를 받았습니다. 통과했습니다.

갑자기 사이트의 다른 부분이 손상되었습니다. 이는 CSS가 전 세계적으로 적용되어 인식하지 못하는 부분에 영향을 미칠 수 있기 때문입니다. 하지만 과거에는 잘 모르겠지만 7~8년 동안 구성 요소 기반 아키텍처라고 불렸던 새로운 경향이 있습니다. 이를 통해 구성 요소라고 하는 응용 프로그램의 특정 부분을 빌드할 수 있습니다.

그리고 JavaScript, HTML, CSS를 개별적으로 테스트할 수 있는 작은 비트로 결합할 수 있으므로 애플리케이션의 일부를 빌드할 수 있습니다. 몇 가지 우려 사항, 마크업, JavaScript, 스타일 및 이러한 구성 요소를 함께 구성하여 더 복잡한 애플리케이션을 구축할 수 있습니다.

따라서 구성 요소 기반 개발을 통해 복잡한 기능을 더 작은 독립된 조각으로 나누고 개별적으로 테스트하고 작동하는지 확인한 다음 연결되어야 하는 문제를 결합할 수 있습니다. 모든 UI 조각에는 특정 책임이 있습니다. 이미지 카드라면 특정 URL로 이미지를 특정 크기로 렌더링하는 역할을 할 수 있습니다.

따라서 마크업 종속성이 있습니다. 스타일 종속성이 있습니다. 상태 저장 상호 작용이 있을 수 있습니다. 이들은 모두 특정 구성 요소와 관련이 있습니다. 따라서 마크업, JavaScript 및 CSS를 한 곳에서 결합하고 테스트하고 제대로 작동하는지 확인할 수 있습니다. 이로 인해 애플리케이션 전체에서 이러한 구성 요소를 재사용하거나 프로젝트 전체에서 구성 요소를 재사용할 수도 있습니다.

따라서 구성 요소 라이브러리라는 추세가 있습니다. Material UI 또는 최종 디자인 구성 요소와 같은 프로젝트가 있거나 Chakra UI도 인기가 있습니다. 그리고 우리는 이러한 구성 요소를 여러 프로젝트에서 사용할 수 있습니다. 또한 액세스 가능한 마크업과 같은 주요 문제를 해결할 수 있습니다. 그리고 우리는 이를 업데이트하고 조직의 여러 프로젝트에 한 번에 적용할 수 있습니다. 이러한 이유로 우리는 더 많은 확신을 가지고 더 빠르게 반복하고 출시할 수 있습니다.

그러면 Headless WordPress를 어떻게 사용할 수 있습니까? 앞서 언급한 것처럼 WordPress에서 구성 요소로 데이터를 가져오는 방법에는 두 가지가 있습니다. 하나는 REST API입니다. 하나는 WPGraphQL입니다. 내 친구 Drake는 한동안 Headless 사이트를 구축해 왔기 때문에 그에게 물어보니 이렇게 말했습니다.

그는 WPGraphQL을 선호합니다. 그래서 그것이 오늘 우리가 이야기할 것입니다. WPGraphQL은 무엇입니까? 당신은 물어볼 수 있습니다. 모든 WordPress 사이트에 확장 가능한 GraphQL 스키마 및 API를 제공하는 무료 오픈 소스 WordPress 플러그인입니다. 그렇다면 GraphQL은 무엇입니까? 음, 그래프 쿼리 언어입니다.

좋아, 제이슨. 나는 아직도 당신이 말하는 것을 이해하지 못합니다. 자, 보여드리겠습니다. 따라서 GraphQL의 작동 방식은 클라이언트 애플리케이션이 서버에서 원하는 것을 지정하는 요청을 보내는 것입니다. 요청은 다음과 같습니다. 값이 없는 JSON 키처럼 보입니다. 따라서 이 경우 요청은 뷰어를 요청하고 뷰어에서 "이름" 필드가 반환되기를 원합니다.

그리고 GraphQL 서버의 응답은 다음과 같을 수 있습니다. 실제 JSON 데이터, 키 및 값이며 요청의 모양과 일치합니다. 따라서 이 경우에는 이름을 얻거나 Jason Bahl이라는 이름의 뷰어를 얻습니다. 따라서 GraphQL은 클라이언트 애플리케이션이 애플리케이션 데이터 그래프에서 트리를 뽑도록 합니다.

시각적으로 보이는 것은 다음과 같습니다. 그래프에 들어갈 수 있습니다. 예를 들어 뷰어나 사용자 필드 또는 노드를 추가할 수 있습니다. 그리고 해당 노드에는 Jason이라는 이름과 같은 속성이 있을 수 있습니다. 그리고 해당 노드는 이미지 URL과 같은 속성을 가질 수 있는 아바타와 같은 그래프의 다른 노드에 대한 연결을 가질 수 있습니다.

그리고 해당 사용자는 해당 사용자가 작성한 게시물과 같은 다른 노드에 연결할 수 있습니다. 그리고 이러한 게시물에는 제목, Hello World 또는 Goodby Mars와 같은 속성이 있을 수 있습니다. 그리고 이러한 게시물은 뉴스나 스포츠와 같은 고유한 제목이 있는 범주와 같이 그래프의 다른 노드에 연결될 수 있습니다. 그리고 이러한 카테고리는 더 많은 게시물과 마찬가지로 다른 노드에 연결될 수 있습니다. 그리고 그 게시물에는 추천 이미지 등이 있을 수 있습니다. 그래서 우리는 GraphQL로 조각을 요청할 수 있는 이 큰 데이터 그래프를 가지고 있습니다.

따라서 GraphQL 관리자 또는 WordPress 관리자에서 도구를 사용할 수 있습니다. 쿼리를 작성할 수 있는 GraphiQL이라는 도구가 있습니다. 여기서는 하위 선택 항목, 이름, 아바타, URL이 포함된 Viewer 필드를 선택합니다. 이를 실행하면 요청한 필드가 표시되므로 시각적으로 쿼리가 다음과 같이 보입니다.

우리는 그래프를 입력하고 한 명의 사용자를 요청했습니다. 아바타의 URL에 연결된 아바타인 사용자의 이름을 요청했습니다. 우리는 이 모든 데이터 그래프를 사용할 수 있지만 특정 데이터 세트만 요청하면 그에 대한 응답으로 특정 세트를 돌려받습니다. 이제 컴포넌트를 사용할 수 있습니다.

그래서 구성 요소 기반 개발의 이점에 대해 이야기했고 실제로 이를 보여주고 싶습니다. 그래서 이것이 제가 프리젠테이션 구성 요소라고 부르는 것입니다. 그래서 이것은 담당하는 카드 구성 요소입니다. 이미지와 제목이 있는 이 카드를 렌더링하는 것은 하나의 책임입니다.

그리고 우리는 코드를 볼 수 있고 스타일 제어가 있음을 알 수 있습니다. 너비를 설정할 수 있고 원하는 이미지를 전달할 수 있으며 제목을 전달할 수 있습니다. 따라서 프로젝트 전체에서 이 구성 요소를 재사용할 수 있습니다. 그리고 이 구성 요소에는 필요한 모든 종속성이 있습니다. 렌더링할 HTML이 있습니다. 스타일이 있습니다. 여기에 스타일 컨트롤이 있습니다. 호버 상태 및 기타와 같은 일부 상태 저장 구성 요소가 있습니다.

따라서 이것은 우리가 재사용할 수 있는 격리된 구성 요소이며 이제 GraphQL을 사용하면 GraphQL을 사용하여 WordPress 관리자에서 방금 구성한 쿼리를 가져올 수 있고 이제 뷰어 카드 구성 요소를 가져올 수 있습니다. 따라서 쿼리를 작성하고 카드 구성 요소와 결합하면 이제 구성 요소가 완성됩니다.

HTML, CSS, JavaScript가 있습니다. 그리고 데이터 덕분에 이제 우리가 요청한 데이터로 렌더링할 무언가가 생겼습니다. 이제 우리는 이것을 애플리케이션 전체에서 사용할 수 있으며 조각이라는 GraphQL의 기능이 있습니다. 이를 통해 GraphQL 쿼리를 가져와서 재사용 가능한 조각으로 나눌 수 있습니다.

따라서 이 경우에는 사용자 프로필 카드 조각을 만들고 이름, 아바타 및 URL을 지정한 다음 더 큰 쿼리에서 해당 조각을 사용하고 있습니다. 실행하면 예상한 결과를 얻습니다. 이제 해당 조각을 가져 와서 구성 요소에 넣을 수 있습니다. 이제 사용자 프로필 카드라는 다른 구성 요소가 생겼습니다.

이 사용자 프로필 카드는 사용자를 쿼리할 때마다 이름, 아바타 및 구성 요소에서 사용할 아바타의 URL을 가져와야 함을 지정합니다. 이제 우리는 응용 프로그램에서 사용자를 요청하는 재사용 가능한 구성 요소를 가지고 있으며 아바타 및 사용자 이름과 함께 이 재사용 가능한 카드를 렌더링하는 데 필요한 데이터를 얻을 수 있습니다.

이제 이것은 애플리케이션의 더 큰 부분에서 가져와 사용할 수 있습니다. 재사용 가능한 사용자 프로필 카드 구성 요소에서 가져오는 조각을 사용하여 뷰어 쿼리 전에 수행한 쿼리는 다음과 같습니다. 그런 다음 뷰어 카드 구성 요소로 출력하고 이제 애플리케이션 전체에서 이를 재사용할 수 있습니다.

이 사용자 카드 또는 작성자 카드에 의존하는 응용 프로그램의 더 큰 부분을 만들 수 있습니다. 따라서 이제 제목을 담당하는 블로그 제목 구성 요소와 같은 여러 구성 요소를 가질 수 있습니다. 사용자 프로필을 렌더링하는 방금 만든 사용자 프로필 카드를 가질 수 있습니다. 애플리케이션의 이 부분에 대한 마크업 및 데이터를 담당하는 콘텐츠 또는 발췌 구성 요소를 가질 수 있습니다.

그리고 예, 우리는 이 애플리케이션을 구축하는 데 필요한 마크업, CSS 및 데이터를 담당하는 이러한 작은 구성 요소를 구축할 수 있습니다. 그리고 우리는 그것들을 함께 구성할 수 있습니다. 개별적으로 테스트할 수도 있고 더 큰 단위로 테스트할 수도 있습니다. 따라서 이를 다양한 템플릿에서도 사용할 수 있습니다.

작성자가 다른 블로그 게시물이나 블로그 역할에 이러한 재사용 가능한 구성 요소를 사용할 수 있지만 동일한 구성 요소를 사용하여 렌더링할 수 있습니다. 다른 아카이브 페이지에 사용할 수 있습니다. WordPress 템플릿 부분과 매우 유사하므로 헤드리스 애플리케이션을 작은 조각으로 나눌 수 있지만 기술을 함께 결합하는 이점을 얻습니다.

구성 요소 기반 디자인과 그 이점을 경험하는 Headless WordPress 개발자에 대한 정보입니다. 이제 구텐베르크와 관련하여 특히 구텐베르크와 함께 Headless WordPress를 특별히 고려하는 이유는 무엇입니까? 글쎄요, 팀에서 고급 사용자 정의 필드 및 가변 필드와 함께 Headless WordPress를 이미 사용하고 있고 Gutenberg를 사용하도록 편집기 환경을 업데이트하려는 경우 Gutenberg와 함께 Headless를 사용할 수 있는 이유 중 하나입니다.

관리자에서 사용되는 구성 요소와 프런트 엔드에서 사용되는 구성 요소를 구축하여 이점을 얻으려면 블록 편집기의 Gutenberg 백엔드 편집기가 모두 구성 요소 기반이기 때문에 Gutenberg와 함께 Headless를 고려하는 것이 좋습니다. 구조화된 입력을 활용할 수 있습니다. 관리자의 각 블록에는 구조화된 필드가 있습니다.

필드 수준에서 제어할 수 있는 특정 특성이 있습니다. 그리고 구조화된 출력이 구성 요소에 전달되는 이점도 얻을 수 있습니다. 그리고 내가 언급한 것처럼 프로젝트 전체에서 구성 요소와 블록을 재사용할 수 있습니다. 예를 들어 프로젝트 전체에서 사용하려는 접근성 및 특정 마크업 문제를 해결하기 위해 에이전시에서 구축한 블록 라이브러리를 원할 수 있습니다. 그런 다음 하나의 개별 프로젝트 내에서뿐만 아니라 프로젝트 전체에서 업데이트할 수 있습니다.

따라서 이것은 WordPress의 하위 테마와 같은 모든 단일 사이트로 이동하여 모든 단일 사이트에서 마크업 및 기타 항목을 업데이트해야 하기 때문에 확장하기 어려울 수 있는 부분입니다. 여기에서 블록 라이브러리를 NPM 종속성으로 사용하고 조직 전체에서 업데이트할 수 있습니다.

따라서 현재 Gutenberg를 사용한 WordPress 개발 상태는 백엔드에 구성 요소 기반 블록이 있다는 것입니다. 자체 사용자 지정 블록을 구축하거나 핵심 WordPress 블록을 사용할 수 있습니다. 그러나 PHP의 출력은 제가 언급한 것처럼 HTML의 큰 덩어리입니다. 그러면 이 한 블록의 HTML을 가져오는 것에서 프런트 엔드의 구성 요소로 전송되는 백엔드의 구성 요소를 갖는 것으로 어떻게 전환할 수 있을까요?

따라서 구텐베르크 데이터를 WordPress에서 구성 요소로 가져오는 몇 가지 옵션을 살펴보겠습니다. 따라서 한 가지 옵션은 콘텐츠를 HTML로 가져오는 것입니다. 따라서 WordPress 콘텐츠를 HTML로 쿼리한 다음 해당 HTML을 구성 요소로 구문 분석할 수 있습니다. 또는 블록을 GraphQL 유형으로 쿼리할 수 있습니다. 따라서 우리는 블록 목록을 쿼리할 수 있으며 각 블록은 구성 요소에 매핑할 수 있는 GraphQL 유형이 됩니다.

따라서 콘텐츠는 HTML입니다. 이것이 오늘날 WPGraphQL 코어에서 할 수 있는 일입니다. 개별 GraphQL 유형으로 블록을 쿼리하려는 경우 현재 두 가지 옵션이 있습니다. 우리는 커뮤니티 확장인 Gutenberg 확장용 GraphQL을 가지고 있고, 개인적으로 작업하고 있는 베타 플러그인인 WPGraphQL Block Editor를 가지고 있습니다.

이제 이러한 옵션을 살펴보겠습니다. WPGraphQL 코어에서 콘텐츠를 HTML로 쿼리하고 구성 요소로 구문 분석할 수 있습니다. 게시물과 같은 것을 쿼리하고 ID, 제목 또는 콘텐츠와 같은 필드를 요청할 수 있습니다. 그리고 콘텐츠는 하나의 큰 문자열, 하나의 큰 HTML 청크를 반환할 것입니다. 그런 다음 해당 HTML을 구문 분석하고 다른 DOM 노드를 다른 구성 요소에 매핑할 수 있습니다.

wpgraphql.com의 이 경우와 마찬가지로 왼쪽에 있는 링크는 이것이 실제로 발생하는 코드입니다. WPGraphQL에서 반환되는 마크업을 가져와 구문 분석하고 특정 HTML 노드를 찾아 React 구성 요소로 변환합니다. 따라서 구문 강조를 수행하고 사용자가 복사를 클릭할 수 있도록 하는 이 코드 블록과 같은 대화형 기능을 가질 수 있으며 예를 들어 목차를 구문 분석하고 생성할 수도 있습니다. 이것이 하나의 접근법입니다. 그리고 현재 프로덕션 환경에서 wpgraphql.com에서 사용하고 있습니다.

이 경로를 사용하는 경우 고려해야 할 몇 가지 사항은 HTML 페이로드를 예측할 수 없다는 것입니다. 새로운 블록 라이브러리를 설치하거나 편집자가 콘텐츠에 넣을 수 있는 다양한 HTML을 설치하는 것과 같은 서버의 변경 사항은 예측할 수 없습니다. 따라서 구문 분석이 매우 어려울 수 있습니다. 변경 사항을 검사할 수 없습니다. 클라이언트 개발자는 무엇이 변경되었는지 알 수 없으므로 고려해야 할 사항만 있습니다.

이 접근 방식은 WordPress 관리자와 프런트 엔드를 매우 엄격하게 제어하는 ​​팀에 가장 적합하다고 말하고 싶습니다. 따라서 WordPress 백엔드 및 프런트 엔드에서 작업하는 한 사람 또는 소규모 팀인 경우 입력 및 출력을 조금 더 잘 제어할 수 있으므로 괜찮을 수 있습니다.

다른 옵션 중 하나인 Gutenberg용 WPGraphQL은 커뮤니티에서 관리하는 플러그인입니다. 이를 통해 콘텐츠 블록, 각 블록을 고유한 GraphQL 유형으로 쿼리할 수 있습니다. 이것이 작동하는 방식은 설정 페이지이며 스키마로 블록만 들어가야 하므로 보이지 않는 iframe에서 구텐베르크를 열고 JavaScript 클라이언트에서 블록 레지스트리를 가져와서 서버로 보냅니다.

그런 다음 GraphQL을 사용하여 블록을 특정 유형으로 쿼리할 수 있고 앞에서 보여준 것처럼 조각을 사용할 수 있으며 이러한 조각을 사용하여 프런트 엔드의 구성 요소에 매핑할 수 있습니다. 따라서 이것은 하나의 옵션입니다. 이 플러그인에 대한 몇 가지 고려 사항, 블록 레지스트리에 대한 변경 사항은 검사할 수 있으므로 좋은 것입니다.

프런트 엔드 애플리케이션에서 작업하는 팀은 GraphQL 자체 검사를 사용하여 시간이 지남에 따라 스키마가 어떻게 변경되는지 확인하고 주요 변경 사항이 있는지 또는 사용할 수 있는 새로운 필드가 있는지 알 수 있습니다. 이 접근 방식은 여러 사람 또는 여러 팀 프로젝트에 조금 더 효과적이라고 말하고 싶습니다. WordPress 관리자에서 작업하는 팀과 프런트 엔드에서 작업하는 다른 팀이 있는 경우 이 접근 방식이 더 적합할 수 있습니다. 양쪽에서 사용 중인 블록 간의 계약으로 GraphQL 스키마를 사용할 수 있습니다.

한 가지 흥미로운 점은 내가 언급한 것처럼 iframe에 블록을 로드한다는 것입니다. 이 때문에 항상 모든 상황에 맞게 확장되는 것은 아닙니다. 따라서 특정 페이지나 특정 템플릿 또는 특정 게시물 유형에 블록을 등록하는 경우 스키마에 대한 블록 레지스트리 맵을 가져오는 이 방법은 일부 블록을 놓칠 수 있습니다. 따라서 모든 프로젝트에 대해 확장되지 않을 수 있습니다.

그래서 다음 프로젝트인 WPGraphQL Block Editor는 제가 현재 작업하고 있는 베타 플러그인입니다. 또한 이를 통해 콘텐츠 블록을 자체 GraphQL 유형으로 쿼리할 수 있으며 Gutenberg의 WPGraphQL과 매우 유사하므로 지정한 데이터를 반환하는 조각을 작성할 수 있습니다. 그런 다음 프런트 엔드에서 구성 요소와 함께 이러한 조각을 사용할 수 있습니다.

이것에 대한 몇 가지 고려 사항은 베타 플러그인이므로 거기에 있습니다. 구조화된 입력 및 구조화된 출력의 이점을 누릴 수 있습니다. 따라서 프론트 엔드 개발자로서 이는 확실한 승리입니다. block.json 파일에 등록된 블록과 함께 작동합니다. 따라서 핵심 WordPress Gutenberg 블록에는 이 파일이 있으므로 해당 접근 방식으로 작동합니다. 많은 제3자가 이러한 방식으로 블록을 등록하지 않으므로 해당 블록을 수동으로 매핑해야 합니다.

블록은 개별 노드로 취급되지 않습니다. 블록을 개별 노드로 취급하고 싶지만 글로벌 ID가 없으므로 포스터 페이지와 같은 더 큰 개체의 일부로 해당 블록에 액세스해야 합니다.

Headless WordPress, Headless WordPress의 이점, Gutenberg와 함께 Headless WordPress 사용에 대해 배웠기를 바랍니다. 오늘 WPGraphQL을 사용해 보시기 바랍니다. wpengine.com/atlas에서 무료 Atlas Sandbox 계정에 가입할 수 있습니다. 그리고 제 발표에 참여해 주셔서 감사합니다. 다시 한 번 Twitter, jasonbahl 또는 Twitter @wpgraphql에서 저를 찾을 수 있습니다. 감사합니다.