Go-DOM - 주요 이정표

작업한 지 2주도 안 된 후; 드디어 Go-DOM의 첫 번째 중요한 이정표에 도달했습니다.

이제 브라우저는 DOM 트리를 구축할 때 원격 JavaScript를 다운로드하고 실행합니다.

간략한 역사

이 프로젝트는 말도 안되는 아이디어로 시작되었습니다. Go와 HTMX가 어느 정도 인기를 얻고 있는 스택임을 확인합니다.

Go에는 순수 서버 측 렌더링을 테스트하는 데 필요한 모든 도구가 이미 있습니다. 그러나 HTMX와 같은 라이브러리를 추가하면 앱의 동작은 초기 DOM 간의 구성 결과입니다. 대화형 요소의 속성 도달한 HTTP 끝점 및 해당 끝점에서 전달된 콘텐츠 응답 헤더와 본문 모두. 사용자 관점에서 동작을 확인하려면 브라우저가 필요합니다. 또는 적어도 브라우저와 완전히 다르지 않게 작동하는 테스트 하네스입니다.¹

'headless browser in go'를 검색하면 헤드리스 모드에서 실제 브라우저를 사용하라는 결과만 나옵니다. 엄청난 오버헤드가 있는 이 조합은 빠르고 효율적인 TDD 루프를 방해합니다. 실제 브라우저에 의존하면 일반적으로 속도가 빨라지는 대신 속도가 느려집니다.²

그래서 아이디어가 촉발되었습니다. 웹 애플리케이션용 테스트 도구로 순수 Go로 헤드리스 브라우저를 작성합니다.

해결해야 할 첫 번째 불확실성은 HTML 구문 분석이었습니다. 스크립트 실행도 마찬가지입니다. 나는 아주 빨리 성공했습니다. 2일 이내에 이 두 가지를 모두 해결해야 합니다. 나는 매우 기초적인 HTML 파서를 가지고 있었습니다. 또한 v8을 코드 베이스³에 통합하고 JavaScript 코드에서 Go 객체에 액세스할 수 있도록 했습니다.

go x/net/html이 이미 HTML 파서를 구현했기 때문에 HTML 파서는 나중에 제거되었습니다. HTML 구문 분석의 모든 단점을 다룹니다. 잘 구성된 문서를 구문 분석하는 것은 해결하기 매우 어려운 문제가 아닙니다. 까다로워지는 잘못된 형식의 HTML을 우아하게 처리합니다.

얼마 후에 인라인 스크립트를 적절한 순간에 실행하는 데 성공했습니다. 즉, 전체 HTML이 구문 분석된 후가 아니라 요소가 실제로 DOM에 연결될 때 스크립트가 실행됩니다.

HTTP 요청 작업

인라인 스크립트로 HTML 문서를 처리할 수 있게 된 후; 다음 단계는 실제로 소스에서 스크립트를 다운로드하는 것이었습니다. 이는 HTTP 레이어를 통합하는 데 필요했습니다. 브라우저가 콘텐츠 자체를 가져오도록 합니다. 콘텐츠를 먹기보다는

http.Client를 사용하면 http.RoundTripper 인터페이스를 사용하여 실제 전송 계층을 제어할 수도 있습니다. 일반적으로 서버를 시작합니다. TCP 포트에서 요청을 수신합니다. 이러한 맥락에서 TCP는 전송 계층 역할을 합니다. 그러나 그 자체는 HTTP 요청 처리와 관련이 없습니다. Go의 표준 HTTP 스택의 단순성으로 인해; 전체 HTTP 서버는 func Handle(http.ResponseWriter, *http.Request)라는 단일 함수로 표현됩니다.

헤드리스 브라우저는 TCP 스택의 오버헤드를 완전히 우회하고 사용자 정의 RoundTripper를 사용하여 이 기능을 직접 호출할 수 있습니다.

이제 브라우저는 HTTP 요청을 수행할 수 있지만 브라우저 코드 자체는 HTTP 계층이 우회된다는 사실을 인식하지 못합니다. 그리고 DOM 구문 분석 중에 스크립트를 다운로드할 수 있는 기능도 생겼습니다.

예제 코드

현재 코드 베이스에 보이는 대로 간단한 테스트를 살펴보겠습니다(코드는 IMHO의 다소 간과되는 조합인 Ginkgo와 Gomega를 사용합니다)

먼저 테스트에서는 /index.html 및 /js/script.js라는 두 개의 엔드포인트를 제공하는 간단한 HTTP 핸들러를 생성합니다.

It("Should download and execute script from script tags", func() {
  // Setup a server with test content
  server := http.NewServeMux()
  server.HandleFunc(
    "GET /index.html",
    func(res http.ResponseWriter, req *http.Request) {
      res.Write(
        []byte(
          `<script src="/js/script.js"></script>Hello, World!`,
        ),
      )
    },
  )
  server.HandleFunc(
    "GET /js/script.js",
    func(res http.ResponseWriter, req *http.Request) {
      res.Header().Add("Content-Type", "text/javascript")
      res.Write([]byte(`var scriptLoaded = true`))
    },
  )

  // ...

여기서의 의도는 단지 스크립트가 실행되었는지 확인하는 것입니다. 이를 위해 스크립트는 관찰 가능한 부작용을 생성합니다. 즉, 전역 범위에서 값을 설정합니다.

스크립트가 실행되었는지 확인하려면 테스트 자체에서 임시 JavaScript를 실행하여 전역 범위를 검사하면 됩니다. 표현식 결과를 확인합니다.

브라우저를 생성하고, 인덱스 파일을 로드하고, 관찰된 부작용을 확인하는 코드

browser := ctx.NewBrowserFromHandler(server)
Expect(browser.OpenWindow("/index.html")).Error().ToNot(HaveOccurred())
Expect(ctx.RunTestScript("window.scriptLoaded")).To(BeTrue())

테스트 실행도 꽤 빠릅니다. JavaScript 실행과 관련된 테스트 모음의 일부는 현재 23밀리초에 실행되는 32개의 테스트로 구성되어 있습니다.

다음 마일스톤은 HTMX를 통합하는 것입니다.

이 프로젝트는 처음에 HTMX 애플리케이션을 검증하는 동안 구상되었으므로 합리적인 다음 목표는 해당 사례만 지원하는 것입니다. 버튼과 버튼을 누르면 증가하는 카운터가 있는 간단한 HTMX 애플리케이션입니다.

• AnXMLHttpRequest 구현이 필요합니다. 이를 위한 작업이 진행 중입니다.
• XPathEvaluator. 처음부터 폴리로 채워질 수 있다고 생각합니다.
• 이벤트 전파. 지금은 DOMContentLoaded 및 로드 이벤트만 발생합니다. 요소는 더 많은 이벤트를 지원해야 합니다. 클릭과 같은; 그리고 이를 트리거하는 방법도 있습니다.
  • 적절한 이벤트 캡처와 버블링이 필요할 수도 있습니다.

그런 다음 ...

이후에는 더욱 발전된 사용자 상호 작용이 가능합니다. 적절한 양식 처리(예: 입력 핸들라인(예: 필드에서 enter를 누르면 양식이 제출됩니다. 여기에는 일반적으로 일종의 URL 리디렉션도 포함됩니다. 이로 인해 기록 객체가 필요하게 됩니다) 등이 필요합니다. .

외부 사이트 통합

전송 계층을 제어하는 ​​기능이 있습니다. 우리는 독특한 능력을 갖춘 테스트를 제공할 수 있습니다. 런타임 시 시스템이 의존하는 외부 사이트를 모의할 수 있습니다. 예를 들어 특정 호스트 이름에 대해 테스트에서는 해당 동작을 시뮬레이션하는 또 다른 Go HTTP 핸들러를 제공할 수 있습니다.

가장 확실한 예는 외부 ID 공급자를 사용하는 것입니다. 테스트는 로그인 흐름의 동작을 시뮬레이션할 수 있습니다. 외부 시스템에서 더미 계정을 만들도록 강요할 필요가 없고, 외부 시스템의 중단으로 인해 테스트가 실패하거나, ID 공급자가 도입한 2FA 또는 Captcha로 인해 프로세스를 전혀 자동화할 수 없습니다.

또 다른 사용 사례는 지도 라이브러리와 같이 사용 비용이 발생하는 API 집약적 라이브러리를 사용하는 것입니다. 테스트 스위트 실행에 대한 추가 청구서를 받지 않으려면 외부 사이트를 모의하세요.

호환성보다 유용성

100% whatwg 표준을 준수하는 구현을 만드는 것은 상당한 노력입니다. 나는 whatwg 사양의 일부를 실제로 읽기 시작할 때까지 범위를 완전히 이해하지 못했습니다. 목표는 웹 애플리케이션용 테스트 작성을 돕는 도구를 만드는 것입니다. 완전한 호환성은 장기적인 목표입니다. 하지만 프로젝트가 어느 정도 사용성에 도달할 때까지 공백을 메우기 시작하겠습니다.

그런 이유로; 실제 애플리케이션에서 사용될 가능성이 높은 기능이 우선순위가 높을 가능성이 높습니다. 잘못된 결과를 제공하는 실제 테스트를 가리키는 기능 요청이 우선시될 가능성이 높습니다. 특정 표준 구현을 위한 기능 요청은 거부될 가능성이 높습니다.

소문을 퍼뜨려라

저는 이것이 많은 개발자들에게 매우 유용한 도구가 될 수 있다고 믿습니다. 따라서 이 내용을 읽으면 동료들에게 이 도구가 있다는 것을 알려주십시오. 이것은 지금까지 여가 시간 프로젝트로 현재로서는 많은 시간을 갖고 있습니다. 하지만 영원히 그럴 수는 없습니다.

이 라이브를 보고 싶다면 소문을 퍼뜨려주세요...

아마도 이것을 후원하시겠습니까? Go로 웹 애플리케이션을 구축하는 대기업이 있나요? 편하게 연락주세요

여기에서 프로젝트를 찾아보세요: https://github.com/stroiman/go-dom

---

1. 인기 BBC 라디오 연극에 대한 경의를 들으셨다면 감사합니다. ↩

2. 개인적인 경험을 바탕으로 작성되었습니다. TDD를 올바르게 수행하면 피드백 주기가 빨라 속도가 빨라집니다. 실제 브라우저의 오버헤드로 인해 프로덕션 코드 이후에 테스트를 작성하게 되는 경향이 있습니다. 빠른 테스트 스위트가 제공하는 피드백 루프의 이점을 잃습니다. ↩

3. v8go 프로젝트는 이미 기반을 마련했습니다. 하지만; v8의 모든 기능이 Go 코드에 노출되는 것은 아닙니다. 기본 개체를 포함하는 데 필요한 기능을 포함합니다. 별도의 포크에 추가할 수 있었습니다. 이는 여전히 WIP입니다. ↩

위 내용은 Go-DOM - 주요 이정표의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!