React-Gutenberg Bridge 소개: 더 나은 편집 경험을 위한 헤드리스 블록 지원

헤드리스 WordPress가 제공하는 기회에 대해 기대하고 있지만 클라이언트의 마케팅 팀은 WYSIWYG Gutenberg 편집기에 연결되어 있습니다.

헤드리스 프로젝트에 대한 Faust의 새로운 Gutenberg 블록 지원이 두 가지를 결합하여 마케팅 담당자에게 권한을 부여하는 동시에 개발을 현대화하는 방법을 확인하십시오.

스피커:

• Teresa Gobble, WP Engine의 소프트웨어 엔지니어
• WP Engine의 선임 소프트웨어 엔지니어 Blake Wilson

세션 슬라이드:

성적 증명서:

TERESA GOBBLE: 안녕하세요, 여러분. 제 이름은 테레사 고블입니다. 저는 Faust 팀에서 일하는 WP Engine의 소프트웨어 엔지니어입니다.

그리고 선임 소프트웨어 엔지니어인 Blake Wilson과 함께 더 나은 편집 경험을 위한 헤드리스 블록 지원인 React-Gutenberg Bridge를 소개합니다. 환영. 시작하자.

오늘은 다룰 내용이 많습니다. 우선, React-Gutenberg Bridge의 가치뿐만 아니라 문제 및 솔루션과 관련된 몇 가지 사항을 살펴보겠습니다. 그런 다음 작동 중인 React-Gutenberg Bridge의 데모를 제공할 Blake로 이동합니다. 그런 다음 몇 가지 기술적인 세부 사항에 대해 이야기하겠습니다. 또한 이를 위해 준비한 향후 로드맵을 방문할 것입니다.

그래서 여기에 문제가 있습니다. 구텐베르크 블록을 WordPress에서 헤드리스 프런트 엔드로 변환하는 능률적인 방법은 없습니다. 존재하는 솔루션은 헤드리스 개발자가 기대할 수 있는 개발자 경험을 제공하기에는 아직 확장 가능하거나 직관적이지 않습니다.

디커플링은 편집기에서 구텐베르크 블록 콘텐츠를 자연스럽게 사용하는 기능을 중단합니다. 그리고 대행사는 거의 지침 없이 처음부터 자체 방식으로 만드는 방법을 궁금해합니다. 그리고 답이 없는 많은 질문이 사람들에게 남아 있습니다.

스타일링은 어떨까요? 재사용성, 동적 블록, InnerBlocks는 어떻습니까? 자, 여기에 React-Gutenberg Bridge가 등장합니다. 두 부분으로 구성된 솔루션입니다. 첫 번째는 Gutenberg 블록을 프로그래밍 방식으로 노출하여 헤드리스 프런트 엔드에서 구문 분석하고 읽을 수 있도록 하는 방법입니다. 이 부분을 WPGraphQL 콘텐츠 블록이라고 합니다.

둘째, 헤드리스 프런트 엔드에서 해당 블록의 설정 및 렌더링을 용이하게 하는 커넥터가 있습니다. 그리고 이것은 Faust WP Blocks라는 패키지입니다. 여기에서 이러한 두 가지 솔루션 조각과 함께 작동하는 방법에 대한 연습을 볼 수 있습니다.

웹사이트의 React 기반 백엔드에는 WPGraphQL 콘텐츠 블록 플러그인에 의해 노출되는 구텐베르그 블록이 있습니다. block.json 콘텐츠를 WPGraphQL에 노출합니다. WPGraphQL이라는 플러그인에 제공합니다.

그런 다음 블록의 사용자 지정, 검색 및 렌더링을 가능하게 하는 커넥터 패키지로 이동합니다. 그리고 이것은 오늘 기술 토론과 데모를 진행하면서 실제로 더 많이 논의될 것입니다. 그렇다면 이것이 팀에 어떤 종류의 가치를 가져다 줄까요?

음, 복잡성과 모호성을 줄이는 종단 간 독단적인 솔루션입니다. 특정 규칙을 따라 개발 시간을 절약합니다. 블록과 블록 패턴을 조합하여 사용할 수 있습니다. 그리고 반복해서 재사용할 수 있습니다. 이제 React-Gutenberg Bridge가 작동하는 방식에 대한 아이디어를 얻었으므로 Blake로 이동하여 데모를 살펴보겠습니다.

블레이크 윌슨: 고마워요, 테레사. 안녕하세요 여러분. 저는 블레이크 윌슨입니다. 저는 여기 WP Engine의 수석 소프트웨어 엔지니어입니다.

그리고 저는 Faust를 구축하는 Faust JS 팀에 속해 있습니다. 저는 오늘 이 React-Gutenberg Bridge를 오케스트레이션하는 데 도움이 되도록 구축한 두 가지 구성 요소를 보여주는 정말 훌륭한 데모를 준비했습니다. 그럼 바로 시작하겠습니다.

시작하기 위해 여기에서 설정한 내용을 보여 드리겠습니다. 그런 다음 실제 코드로 이동하여 거기에 무엇이 있는지 확인할 수 있습니다. 우선, 여기 로컬에서 실행되는 WordPress 사이트가 있습니다.

몇 가지 플러그인이 설치되어 있습니다. 그래서 저는 Faust 플러그인을 가지고 있습니다. 이렇게 하면 Faust JS 사이트에서 미리 보기와 모든 종류의 유용한 정보를 쉽게 사용할 수 있습니다. WordPress 사이트를 GraphQL 끝점으로 변환하는 데 필요한 WPGraphQL이 있습니다.

그런 다음 WPGraphQL 콘텐츠 블록이 있습니다. 그래서 이것은 이 React-Gutenberg Bridge를 용이하게 하기 위해 우리가 만든 플러그인 중 하나입니다. 이 솔루션은 두 가지 주요 부분으로 구성됩니다.

따라서 WPGraphQL을 통해 프로그래밍 방식으로 Gutenberg 블록 데이터를 실제로 노출하는 부분 중 하나와 Faust JS 프런트 엔드에서 이를 소비하는 또 다른 부분이 있습니다. WPGraphQL 콘텐츠 블록과 그 작동 방식을 살펴보는 것으로 시작하겠습니다.

이제 그래픽 IDE로 이동합니다. 페이지의 데이터를 가져오기 위해 여기에 이 ​​쿼리를 설정했습니다. 따라서 이 경우에는 페이지 제목만 가져옵니다.

따라서 GraphQL 콘텐츠 블록이 하는 일은 GraphQL 스키마에서 콘텐츠 블록 유형을 노출하는 것입니다. 따라서 콘텐츠 블록을 입력하면 여기에서 볼 수 있듯이 이 페이지와 이 페이지의 모든 블록에 대한 정보를 얻습니다. 이 페이지로 이동하여 편집하고 일부 콘텐츠를 추가해 보겠습니다.

샘플 페이지로 이동합니다. 여기 빈 서판이 있는 것을 볼 수 있습니다. 계속해서 블록을 만들어 봅시다. 여기에 몇 개의 열을 만들어 보겠습니다.

그리고 우리는 50/50 열을 할 것입니다. 이 절반에 단락을 추가한 다음 이 절반에 이미지를 추가해 보겠습니다. 여기 내 미디어 라이브러리에 이미지가 있습니다. 계속해서 이것을 입력해 보겠습니다.

여기 보시다시피 두 개의 열이 있습니다. 다시 말하지만, 왼쪽에는 단락이 있고 오른쪽에는 이미지가 있습니다. 이것을 업데이트합시다. 그리고 WPGraphQL 콘텐츠 블록으로 돌아가서 결과로 무엇을 얻었는지 봅시다.

여기에서 볼 수 있듯이 이제 두 개의 콘텐츠 블록이 있습니다. 여기 첫 번째는 코어 컬럼, 코어 컬럼입니다. 그런 다음 그 안에 HTML을 렌더링합니다.

따라서 WPGraphQL 콘텐츠 블록의 좋은 점은 InnerBlocks도 처리하고 있다는 것입니다. 여기에서 flat true라는 콘텐츠 블록에 매개변수를 추가하면 해당 열에 있는 모든 블록을 실제로 얻을 수 있음을 알 수 있습니다. 그래서 우리는 당신을 위해 그 사건도 처리하고 있습니다.

핵심 열, 핵심 열, 핵심 단락, 핵심 이미지를 얻습니다. 따라서 모든 작업이 프로그래밍 방식으로 수행됩니다. 이제 프런트 엔드에서 이 블록 데이터를 사용할 수 있습니다. 그럼 여기서 조금 더 깊이 파헤쳐 봅시다.

우리가 그것에 대한 속성 중 일부를 원한다고 가정해 봅시다. GraphQL에서 공용체를 사용하여 사용할 수 있습니다. 따라서 핵심 이미지에서 속성을 가져옵니다. 예를 들어 캡션이 필요하다고 가정해 보겠습니다.

여기 보시면 캡션이 없습니다. 샘플 페이지로 돌아가 보겠습니다. 계속해서 여기에 캡션을 추가합니다. 내 자막. 그것을 업데이트하십시오.

이 쿼리를 새로 고치면 WPGraphQL 콘텐츠 블록에서 내 캡션이 적절한 속성으로 표시되는 것을 볼 수 있습니다. 이것이 솔루션의 1부입니다. 이제 우리는 실제로 구텐베르크 블록 데이터를 모두 가져와 프런트 엔드에서 사용하는 데 사용할 수 있습니다.

이제 VS Code로 넘어가서 해당 부분을 어떻게 처리하는지 살펴보겠습니다. 이것이 제가 함께 만든 Faust JS 예제 프로젝트입니다. 매우 간단합니다. Faust Scaffold Blueprint를 기반으로 하지만 이러한 블록을 처리하기 위한 몇 가지 추가 구성이 있습니다.

따라서 패키지 JSON을 살펴보면 몇 가지 종속성이 있음을 알 수 있습니다. 여기에는 코어 및 CLI와 같은 일반적인 Faust 패키지가 있습니다. Faust VP 블록도 있습니다. 따라서 이것은 모든 도우미 기능을 제공하는 패키지 중 하나입니다.

스타일 등을 처리하기 위한 WordPress 의존성도 있습니다. 또한 여기에 이 ​​WP Blocks 디렉토리가 있음을 알 수 있습니다. 따라서 이것은 프런트 엔드에 대한 모든 블록이 있는 곳이며 프런트 엔드에서 사용하는 모든 블록에 대한 레지스트리 역할을 합니다.

index.js 파일이 있는 것을 볼 수 있습니다. 이것은 본질적으로 우리가 프런트 엔드에서 사용하는 모든 블록을 결정하는 객체입니다. 여기에서 볼 수 있듯이 핵심 단락, 핵심 열, 핵심 열 및 핵심 이미지가 있습니다.

이것을 설정하는 것과 관련하여 우리가 이야기할 두 가지 주요 부분이 있습니다. 그래서 하나는 WordPress Blocks 공급자와 WordPress Blocks 뷰어입니다. 그럼 실제로 작동하는 모습을 살펴보겠습니다. 먼저 WordPress Blocks 공급자를 살펴보겠습니다.

그리고 이것은 pages_app에서 사용할 수 있습니다. 여기에서 볼 수 있듯이 이 구성 요소, 이 공급자, WordPress Blocks 공급자가 있습니다. 그리고 블록을 허용하는 구성 소품을 허용합니다. 여기에서 볼 수 있듯이 이 디렉토리의 색인인 WP 블록에서 블록을 가져오고 이를 구성 개체로 전달합니다.

본질적으로 이것이 말하는 것은 WordPress 블록 공급자가 전체 앱을 래핑하고 이러한 모든 블록에 대한 컨텍스트를 전체 앱에 제공한다는 것입니다. 이제 단일 템플릿으로 WP 템플릿으로 이동하겠습니다. 여기에서 컨텐츠 블록의 소품으로 WordPress Blocks 뷰어를 호출하는 것을 볼 수 있습니다. 이것이 WPGraphQL에서 반환되는 블록 데이터입니다.

좋습니다. 설정에 대해서는 이 정도면 충분합니다. 이것을 돌려서 실제로 어떻게 보이는지 봅시다. 그래서 localhost 3000에 dev 환경을 설정하는 NPM run dev를 실행할 것입니다. 이전에 설정한 블록입니다.

여기 보시다시피 구텐베르크 편집기에 동일한 블록이 있습니다. 이제 샘플 페이지를 위해 Gutenberg 편집기로 돌아가 봅시다. 여기에 두 개의 열이 있는 것을 볼 수 있습니다. 이것은 제 단락이고, 그 다음에는 여기 프런트 엔드에 있는 것과 일치하는 이미지입니다.

멋져 보이지만 스타일을 수정할 수 있습니까? 글꼴 크기를 변경할 수 있습니까? 당신은 확실히 할 수 있습니다.

이제 Gutenberg 편집기로 돌아가서 이 블록을 수정해 보겠습니다. 여기 단락에 배경색을 추가해 보겠습니다. 크기도 크게 변경합시다. 여기 이 이미지의 경우 둥글게 만들어 보겠습니다.

캡션을 빼봅시다. 그리고 우리는 그것을 업데이트 할 것입니다. 이제 이러한 스타일이 적용되는 것을 볼 수 있습니다. 그리고 프런트 엔드에서 볼 수 있습니다.

따라서 WordPress에서 기대하지 않는 게시자 경험을 헤드리스 WordPress 사이트에 다시 제공하고 있습니다. 이것에 대한 또 다른 좋은 점은 이제 이러한 블록에 대한 프로그래밍 데이터를 얻고 있으므로 다음 이미지와 같은 프레임워크별 기능을 사용하여 React 구성 요소를 만들 수 있다는 것입니다. 이제 WPGraphQL에서 반환되는 HTML을 렌더링하는 대신 이제 해당 프로그래밍 데이터를 사용하여 Gutenberg의 모든 이미지를 다음 이미지로 렌더링하는 구성 요소를 생성하여 지연 로딩, 더 나은 성능 및 더 나은 최적화된 이미지를 제공할 수 있습니다. 전반적으로 사용자에게 더 나은 사용자 경험을 제공합니다.

그래서 이것은 훌륭합니다. 우리는 Gutenberg 편집기에서 정확히 우리가 기대하는 것을 보고 있지만 아직 지원되지 않거나 Faust 사이트에서 구성하지 않은 구성 요소를 추가한다고 가정해 보겠습니다. 이제 여기 아래에 새 구성요소를 생성해 보겠습니다. 우리는 테이블을 사용할 것입니다.

그리고 우리는 행 1, 행 2의 두 행을 할 것입니다. 가서 업데이트하십시오. 여기 코드를 다시 보면 핵심 단락, 핵심 열, 핵심 열 및 핵심 이미지의 네 가지 블록이 정의되어 있음을 알 수 있습니다. 여기에는 코어 테이블이 없습니다.

이 페이지를 보면 어떻게 될까요? 한 번 보자. 이제 Faust 프런트 엔드의 샘플 페이지로 돌아가겠습니다. 그리고 여전히 여기에 행 1과 행 2가 있는 테이블이 있는 것을 볼 수 있습니다.

이는 Faust JS 프로젝트에서 블록이 아직 정의되지 않은 경우 렌더링된 HTML에 현명한 대체 작업을 수행하기 때문입니다. 그렇게 하면 정의되지 않았거나 null이 표시되지 않거나 콘텐츠가 전혀 표시되지 않습니다. 최소한 원래 렌더링된 HTML을 다시 가져오고 있습니다.

이 모든 것을 염두에 두고 블록을 생성하는 데 실제로 무엇이 필요한지, 즉 실제로 어떻게 생겼는지 살펴보겠습니다. 그래서 우리는 여기서 VS Code로 돌아갈 것입니다. 예를 들어 핵심 이미지를 선택해 보겠습니다.

보시다시피 이것은 전통적인 React 구성 요소입니다. 우리는 그것을 핵심 이미지라고 부릅니다. 그리고 다른 React 구성 요소와 마찬가지로 props를 허용합니다.

여기 블록에는 기본적으로 두 조각이 있습니다. 그래서 프레젠테이션 레이어인 실제 React 구성 요소가 있습니다. 그런 다음 이 블록이 수행하는 데 필요한 데이터인 block.fragments를 얻습니다.

여기에서 코어 이미지에 코어 이미지 조각인 프래그먼트를 생성하고 있는 것을 볼 수 있습니다. 그리고 우리는 이 블록을 렌더링하는 데 필요한 속성인 속성을 얻습니다. 따라서 대체 텍스트, 소스, 캡션, 클래스 이름, 너비, 높이 등을 가져오는 것을 볼 수 있습니다.

그런 다음 우리가 할 수 있는 것은 이러한 속성을 실제 React 로직에 적용하는 것입니다. 따라서 여기에서 요청된 모든 필드는 props에서 사용할 수 있습니다. 여기에서 요청한 속성(attributes.alt, attributes.source 등)인 props.attributes가 나오는 것을 볼 수 있습니다. 따라서 이것은 동일한 파일 내에서 블록에 대한 모든 데이터 요구 사항을 함께 배치하는 좋은 방법입니다.

이는 필요한 데이터만 요청하고 요청이 훌륭하고 성능이 좋은지 확인하는 것입니다. 이 예제 프로젝트에도 몇 가지 도우미 기능이 있습니다. 여기에 몇 가지가 있는 것을 볼 수 있습니다. 스타일을 가져오고 이미지 크기의 소품을 가져옵니다.

따라서 이들은 본질적으로 WordPress에서 이러한 스타일을 가져와 React가 사용할 수 있는 실제 스타일 개체로 결합합니다. 현재 스타일은 인라인 스타일에 지원됩니다. 전역 스타일 시트도 얻을 수 있지만 현재 theme.json에 대한 지원을 제공하기 위해 노력하고 있습니다.

따라서 Teresa는 향후 로드맵에서 이에 대해 조금 이야기할 것입니다. 그러나 이상적으로는 theme.json에서 모든 스타일과 패딩, 여백 등을 가져와 여기 헤드리스 프런트 엔드에 적용할 수 있는 지점이 올 것입니다. 이 모든 것을 염두에 두고 Teresa와 저와 빠른 기술 토론에 참여하여 이 기능의 현재 상태와 향후 계획에 대해 이야기하겠습니다.

TERESA GOBBLE: 데모 감사합니다, 블레이크. 멋 졌어요. 이제 몇 가지 기술적인 세부 사항을 살펴보고 이것이 어떻게 작동하는지 이야기해 봅시다. 첫 번째로 WPGraphQL 콘텐츠 블록을 사용하기 위한 요구 사항은 무엇입니까?

블레이크 윌슨: 네, 네. 좋은 질문입니다, 테레사. 따라서 플러그인을 사용하기 위한 유일한 요구 사항은 WPGraphQL도 설치하는 것입니다. 분명히 사이트가 Faust JS와 인터페이스하기를 원한다면 Faust JS 블록 패키지를 설치할 수 있습니다. 이 패키지는 헤드리스 프런트 엔드에서 렌더링 및 모든 유용한 기능을 용이하게 하는 데 도움이 됩니다. 그러나 실제로 블록 데이터를 노출하려면 WPGraphQL과 WP GraphQL 콘텐츠 블록 플러그인만 있으면 됩니다.

테레사 고블: 굉장합니다. 블록 데이터는 어떻게 수집됩니까?

BLAKE WILSON: 예, 모든 블록 데이터는 레지스터 블록 유형 기능을 사용하는 WordPress의 모든 블록에 의해 수집됩니다. 따라서 해당 기능과 함께 해당 인터페이스를 사용하는 거의 모든 블록이 콘텐츠 블록에 표시됩니다. 그리고 그것에 대한 좋은 점은 block.json 파일과 릴레이하고 자동으로 모든 필드를 자체 설명하고 자체 문서화한다는 것입니다. 따라서 모든 문서가 하나에 있습니다.

TERESA GOBBLE: 오, 굉장하네요. 얼마나 시간을 절약할 수 있습니다. 조금 더 이야기하고 싶은 또 다른 사항은 지원되지 않는 블록이 어떻게 되는지에 대한 것입니다. 지원되지 않는 블록이 쿼리되면 어떻게 됩니까?

BLAKE WILSON: 네, 또 다른 좋은 질문입니다. 여기서 일어날 수 있는 두 가지 실제 시나리오가 있습니다. 따라서 게시물 데이터에 WordPress에서 제거된 블록이 있다고 가정해 봅시다.

제거된 타사 차단이었을 수 있습니다. 따라서 이것은 Faust 프런트 엔드와 WordPress 레지스트리 모두에서 지원되지 않는 지원되지 않는 블록의 한 사례입니다. 이 경우 헤드리스 프런트 엔드에 적절하게 입력할 수 있도록 정의되지 않은 블록 또는 알 수 없는 블록이라는 콘텐츠 블록에 실제로 블록을 반환합니다. 두 번째 부분은 WordPress 레지스트리의 블록이 지원되지만 Faust JS 프런트 엔드에서 아직 지원되지 않는 경우입니다. 이 경우 렌더링된 HTML로 대체됩니다. 그런 식으로 적어도 null, undefined 또는 이와 유사한 값이 아닌 표시되는 HTML을 렌더링했습니다.

TERESA GOBBLE: 오, 굉장하네요. 그리고 이것은 실제로 저를 다음 질문으로 이끕니다. 헤드리스 분리 웹사이트의 제3자 플러그인의 경우 WPGraphQL 콘텐츠 블록 플러그인을 사용하여 제3자 플러그인을 사용할 수 있습니까? 이 모든 것이 어떻게 함께 작동합니까?

블레이크 윌슨: 네, 네. 따라서 타사 플러그인의 경우 첫 번째 또는 두 번째 질문으로 돌아가서 WordPress에 등록된 블록 유형 기능과 인터페이스하는 한 해당 블록은 자동으로 WPGraphQL 콘텐츠 블록에 노출됩니다. 따라서 해당 데이터가 렌더링되는 한 Faust JS 프런트 엔드에서 블록을 생성할 수 있습니다. 그리고 그것에 대한 좋은 점은 캐 러셀에 대한 타사 블록이 있다고 가정 해 봅시다. Faust JS 프런트 엔드에서 한 번 생성한 후에는 앞으로 다른 프로젝트에서 재사용할 수 있습니다.

TERESA GOBBLE: 오, 좋아요. 재사용성 부분이 필요한 곳입니다. 그리고 이 플러그인을 사용하면 분리된 웹사이트에서 기본적으로 작동하지 않는 타사 플러그인과의 간극 중 일부를 실제로 연결할 수 있습니다.

또한 지금 채팅을 보면 사람들이 타사 플러그인에서 블록을 만드는 데 도움이 되는 튜토리얼이 실제로 있습니다. 이제 채팅을 보면 해당 내용을 확인하고 클릭할 수 있습니다. 책갈피를 지정하십시오.

그렇다면 블록 내에서 블록을 어떻게 처리합니까? 정말 까다로울 수 있습니다. 그것이 어떻게 생겼는지에 대해 조금 말씀해 주시겠습니까?

블레이크 윌슨: 네, 네. 따라서 플랫이라는 콘텐츠 블록을 쿼리할 때 이 플래그 또는 이 매개 변수가 있습니다. 그리고 그것은 true 또는 false 값을 허용합니다. 따라서 이것이 true로 제공되면 해당 페이지에 있는 모든 블록의 플랫 배열 또는 플랫 목록을 실제로 얻을 수 있습니다. 그것이 열이든, 이미지든, 단락이든 상관 없습니다.

두 개의 추가 속성과 함께 해당 페이지에서 쿼리된 모든 블록의 전체 목록을 갖게 됩니다. 하나는 노드 ID입니다. 이것이 특정 블록의 실제 ID입니다. 그러면 해당 블록의 부모인 부모 ID도 갖게 됩니다. 그래서 당신이 할 수 있는 일은 프런트 엔드의 실제 계층적 목록으로 재구성하여 이전에 구텐베르크에서 본 것처럼 내부 블록 수수께끼를 거의 해결하는 것입니다.

테레사 고블: 굉장합니다. 실제로 콘텐츠 블록을 가져올 때 적절한 부모 자식 ID 내에서 블록의 플랫 목록을 반환하도록 지정할 수 있는 옵션이 있습니까?

BLAKE WILSON: 예, 예, 정확합니다.

테레사 고블: 좋습니다. WPGraphQL 콘텐츠 블록이 특정 기능을 살펴볼 수 있도록 채팅에 또 다른 자습서가 있습니다. 그래서 스타일링 작품에 대해 또 다른 질문을 드리고 싶습니다. 글로벌 스타일 시트를 사용한 스타일링, 인라인, 접근 방식은 무엇입니까? 스타일링은 어떻게 처리됩니까?

블레이크 윌슨: 네, 네. 그래서 스타일링은 아마도 우리가 지금 연구하려고 하는 가장 큰 노력 중 하나일 것입니다. 방금 보여드린 예에서는 인라인 스타일을 사용하고 있습니다.

전역 스타일, 전역 스타일 시트도 지원됩니다. 그리고 나는 당신이 로드맵에서 이것을 다음에 만질 것이라고 생각합니다. 그러나 이상적으로는 theme.json 지원도 지원하여 theme.json에서 여백, 패딩, 색상 및 모든 좋은 정보를 얻은 다음 적용할 수 있기를 원합니다. 따라서 우리는 다음 개발 단계에서 이에 대해 작업할 것입니다.

테레사 고블: 굉장합니다. 안내해 주셔서 감사합니다. 나는 많은 사람들이 그것에 대해 정말로 흥분한다는 것을 압니다. 그렇다면 게시자가 지원되지 않는 블록을 사용하지 못하도록 어떻게 제한합니까?

블레이크 윌슨: 네, 네. 그래서 거기에 플러그인이 있습니다. 때에 따라 다르지. 타사 차단을 사용하는 경우 이들 중 일부는 이미 이 기능이 내장되어 있습니다.

하지만 그렇지 않은 경우 게시자 관점에서 실제로 특정 블록을 토글할 수 있는 블록 가시성이라는 플러그인이 있습니다. 따라서 Faust 사이트에 아직 구현되지 않은 캐러셀 블록이 있다고 가정해 보겠습니다. 블록 가시성을 설치하고 아직 지원되지 않거나 개발 중인 동안 게시자가 사용하지 않도록 선택을 취소할 수 있습니다.

TERESA GOBBLE: 오, 굉장하네요. 플러그인 블록 가시성이 실제로 특정 블록을 토글, 숨기기, 표시할 수 있도록 하시겠습니까?

BLAKE WILSON: 예, 예, 정확합니다. 그렇게 하면 WordPress 측과 헤드리스 사이트 모두에서 지원한 블록 수가 제한되어 게시자가 알 수 있습니다. 프런트 엔드.

TERESA GOBBLE: 아, 확실히 더 깨끗한 배달인 것 같군요. 그래 좋아. 마지막 질문입니다. 이 프런트 엔드 블록이 게시자의 편집기에 해당합니까?

BLAKE WILSON: 네, 훌륭한 콜아웃입니다. 그래서 아직. 그것은 우리가 미래에 작업할 것이지만 지금 당장은 이러한 블록이 헤드리스 프런트 엔드에 대해 지원됩니다.

WordPress에서 만든 사용자 지정 블록이 있는 경우 NPX create block 명령을 사용하는 경우 WordPress 측에서 해당 보기를 계속 지원해야 합니다. 그러나 그것은 우리가 작업하고 있는 것입니다. 로드맵에 포함되어 있습니다.

TERESA GOBBLE: 오, 굉장하네요. 좋아요. 블레이크, 그 점에 대해 이야기해주셔서 감사합니다. 정말 도움이 되었고 데모도 마찬가지였습니다.

계속해서 기어를 바꾸고 실제로 해당 프로젝트 로드맵에 대해 조금 더 이야기해 봅시다. 실제로 5단계가 있으며 그 중 2단계는 이미 완료되었습니다. 1단계와 2단계입니다. 1단계에서는 블록을 효율적으로 해체한 다음 재구성하는 방법의 구현을 보았습니다.

그 후 우리는 사람들이 거기에 있는 다양한 유틸리티와 도우미 기능에 모두 액세스할 수 있도록 하기 위해 Gutenberg 블록과 더 긴밀한 Faust 통합에 중점을 둔 2단계로 이동했습니다. 우리가 실제로 진행하고 있는 이 다음 단계인 3단계에서는 기술 토론 중에 Blake가 언급한 것처럼 theme.json 지원 및 재사용 가능한 블록 라이브러리를 제공하는 데 집중하고 있습니다.

이 작업이 완료되면 4단계와 5단계가 진행됩니다. 4단계는 기존 개발 및 편집 경험을 향상하는 데 중점을 두고 있으며 5단계는 핵심 WordPress를 넘어 더 넓은 생태계를 지원하는 데 중점을 둡니다. 우리는 앞으로 다가올 이러한 단계에 대해 매우 기대하고 있으며, 로드맵이 어디에 있는지 최신 정보를 얻기 위해 우리와 함께하고 블로그 게시물도 살펴보기를 바랍니다.

아래 채팅에서 저희 블로그 게시물에 대한 링크를 확인하실 수 있습니다. 계속해서 북마크하십시오. React-Gutenberg Bridge에 대한 토론에 참여해 주셔서 감사합니다. 블레이크를 화면으로 다시 불러와서 감사의 인사를 전하고 이 이후에 질문이 남아 있는 경우 어디로 갈 수 있는지에 대한 추가 정보를 제공하고 싶습니다.

BLAKE WILSON: 네, 감사합니다, Teresa, 그리고 오늘 이 세션에 참여하고 시청해 주신 모든 분들께 감사드립니다. 여러분 모두가 이 기능을 사용해 볼 수 있도록 이 기능에 대한 커뮤니티 피드백을 받게 되어 정말 기쁩니다.

마음에 드신다면 채팅의 링크에 예제 프로젝트가 있습니다. 또한 헤드리스 Discord에 대한 채팅 링크가 있으므로 귀하와 같은 생각을 가진 다른 헤드리스 개발자가 헤드리스 공간에서 향후 기능 및 릴리스에 대해 참여하고 채팅할 수 있는 곳입니다. 다시 한 번 감사드립니다. 정말 감사합니다.