동적 라우팅이 있는 GitHub 페이지

본고에서 언급된 문제는 이미 한동안 토론되었다. https://github.com/isaacs/github/issues/408 불행하게도 아직 진정한 해결 방안이 없기 때문에 해결 방안이 필요하다.
GitHub Pages는 매우 편리한 정적 사이트 위탁 관리 서비스이다. 예를 들어 개인 투자 조합, 블로그나 프로젝트 문서, 심지어 현대 인터넷 응용 프로그램은 많은 상황에서 정적 HTML 파일과 (대량)javascript에 불과하다.하지만 정적 사이트의 단점은...좋아요.정적입니다.이것은 동적 루트가 있을 수 없다는 것을 의미한다. 예를 들어 your-project.github.io/posts/<post-slug> 그 중에서 <post-slug>는 동적 매개 변수이다.모든 가능한 루트는 미리 알고 정적 파일을 가리켜야 한다.아마도 이 파일들은 구축 과정을 통해 만들어진 것일 것이다. 새로운 블로그 글을 추가할 때마다 페이지를 다시 배치하기만 하면 된다.GitHub 작업/작업 흐름과 같은 CI/CD 파이프를 사용하면 이 과정은 새로운 태그 파일을 저장소로 전송하는 것으로 귀결될 수 있어 많은 장면에서 매우 편리하다.그러나 때로는 그렇지 않습니다. 사용자가 생성한 내용이나 프로젝트가 더 복잡해질 때 동적 경로만 필요합니다.

동적 노선은 어떻게 작동합니까?

이 개념에 익숙하고 GitHub 페이지를 어떻게 속여서 동적 루트를 지원하는지 알고 싶으면 이 부분을 건너뛰고 해결 방안을 계속 사용할 수 있습니다.
일반적으로 라우팅/경로는 서버의 도메인(정적) 파일을 가리킵니다.your-server.com/some/path/index.html이 서버에 존재하지 않는 파일에 접근하려고 하면 오류 응답을 합니다. 이것은 서버에 첨부된 기본 파일 404.html 을 제공하는 것을 의미합니다.너는 아마 이런 상황을 본 적이 있을 것이다.

이것은 기본 오류 파일입니다. 이 예에서nginx 서버에서 서비스를 제공합니다.그러나 요청한 경로가 무엇이든지 상관없이 서버를 설정할 수 있습니다.서버에 index.html가 있고 그에 따라 설정되었다고 가정하십시오.지금 your-server.com/index.html 또는 your-server.com/some/path/that/does-not-exist.html 로 전화를 걸 수 있습니다.항상 같은 index.html 파일을 반환합니다.이제 이 파일은 정적 HTML 파일이 아닌 스크립트가 될 수도 있습니다.그렇지 않으면 너의 동적 노선은 그렇게 동적이지 않을 것이다. 왜냐하면 그것들은 모두 완전히 같은 내용을 제공하기 때문이다.
Afront controller는 서버에 대한 모든 요청을 처리하고 실제 요청에 따라 데이터베이스에서 데이터를 가져와 템플릿에서 HTML 응답을 생성하는 동적 스크립트입니다.이러한 방법으로 위의 /posts/<post-slug> 예와 같이 동적 부품이 있는 라우팅을 지원할 수 있습니다.
GitHub 페이지
GitHub Pages는 동적 콘텐츠를 제공하는 데 사용되지 않기 때문에 이러한 프런트엔드 컨트롤러를 지원하지 않습니다.그럼요.정적 HTML 파일에서 Javascript를 사용하여 사용자의 상호작용을 기반으로 하는 것과 같은 내용을 동적으로 변경할 수 있습니다. 대부분의 웹 응용 프로그램은 앞에서 말한 바와 같이 정적 HTML 파일에 불과하고 Javascript가 관리합니다.그러나 이 모든 것은 GitHub 서버가 아닌 브라우저에서 발생합니다.따라서 전화 your-username.github.io/some/file.html 를 걸면 다른 내용을 찾지 않고 파일을 정확하게 찾을 수 있습니다. 만약 파일을 찾을 수 없다면, 저장소에 추가하지 않았기 때문에 다음과 같이 표시됩니다.

GitHub의 기본값404.html 파일입니다.이 점에서 나는 대부분의 개발자/사용자들이 현재 고통스러운 현실만 받아들일 것이라고 가정한다. 즉, GitHub 페이지는 그들의 서비스에 적합한 것이 아니라 보다 전면적인 위탁 관리 해결 방안으로 전환할 수 있다. 이 해결 방안에서 그들은 서버의 실제 조작을 더욱 잘 통제할 수 있다.하지만 난 아니야!나는 게으른 미니멀리스트로 플랫폼 계정 하나면 충분해!

구식 대체품

처음에 내가 고려한 것은 타협일 뿐이지'진정한'동적 노선이 아니다. 나는 한 페이지에서 응용한 역사로 돌아가 # 방법like the old AngularJS을 사용할 수 있다.알고 싶으면 # 뒷부분은 서버 응답의 실제 URL의 일부분이 아닙니다.이것은 브라우저에 의해 HTML 닻으로 이동하는 데 사용될 뿐이며, 자바스크립트로 접근할 수 있습니다.서버는 심지어 이 부분도 모른다.이것은 단지 클라이언트의 것이다.그러나 이것은 네가 이런 노선을 가질 수 있다는 것을 의미한다.your-server.com/#/posts/<post-id>이 프로그램은 서버의 /에 위치하고 브라우저에서 실행할 때 처리# 뒤에 있습니다.프로그램의 링크를 누르면 # 다음 부분만 업데이트되고 자바스크립트를 통해 내용을 변경합니다.하지만 넥스트처럼 예쁘고 현대적인 프레임은 아닌 것 같다.js는 심지어 이런 형식의 루트를 더 이상 지원하지 않는다.Vue’s Nuxt.js actually has a fallback option 그래도 여전히...

솔루션

너는 이미 이 문장에서 일부 해결 방안을 보았다.404쪽입니다.GitHub Pages는 실제로 저장소에 사용자 정의404.html를 추가하고 프로젝트의 브랜드 등에 따라 조정할 수 있습니다.프런트엔드 컨트롤러 모드에 익숙하다면, 지금 "aahhhaaaa"시간이 있을 수 있습니다.이 모델의 중요한 부분은 모든 요청만 받아들이고 응용 프로그램에 경로를 지정한 다음 응용 프로그램에서 요청을 처리하는 것이다.좋아요.404페이지도 다를 게 없어요.모든 요청을 처리합니다...기존 리소스와 일치하지 않습니다.내가 무슨 말을 해야 할지 알아?근데 좀 달라요.고전적인 프런트엔드 컨트롤러가 서버에 위치하고 요청한 자원이 실제로 존재하는 것처럼 필요한 응답을 당신에게 보냅니다.GitHub 페이지에서 동적 라우팅을 지원하도록 유도하는 것은 약간...까다롭다왜냐하면 그것은 존재하지 않기 때문이다!하지만 우리는 그것을 이렇게 보일 수 있다.Nuxt의 동적 라우팅 기능은 현대인의 눈과 마찬가지로 주의를 끌지 못한다.js 또는 React가 다음입니다.js.

개념 증명

간단한 방법은 사용자 정의 404.html 로 모든 요청을 응용 프로그램으로 되돌려주고, 응용 프로그램이 browser history API 브라우저에 표시된 URL을 처음 요청한 내용으로 업데이트하는 것입니다.방향을 바꿀 때, 이 정보를 응용 프로그램에 전달해야 한다.이를 위해 나는...어떻게 생각하세요?우리 오랜 친구#.여기에 GitHub 페이지를 설치했습니다. https://mktcode.github.io/static-dynamic-routing 페이지404.html는 다음과 같습니다.

<!DOCTYPE html>
<html>
  <head>
    <title></title>
  </head>
  <body></body>
  <script>
    window.location.href = '/static-dynamic-routing/#' + window.location.pathname.replace('/static-dynamic-routing', '')
  </script>
</html>

그래서 404를 못 찾은 것보다는!메시지, 이것은 응용 프로그램의 루트로 방향을 바꿀 뿐입니다.저장소에 GitHub 페이지를 설정할 때 이 GitHub 페이지의 예는 하위 디렉토리/static-dynamic-routing/에 있습니다.그것은 <your-username>.github.io/<repo-name>/ 이하에서 생활할 것이다.이것이 바로 우리가 반드시 이곳에서 약간의 교체를 해야 하는 이유이다.그렇지 않으면 사용자를 mktcode.github.io/로 리디렉션합니다.다행히도, 너는 configure a custom domain for your GitHub Page 아주 쉽다. 그리고 너는 이 문제를 처리할 필요가 없다.
그래서 지금 우리가 어떤 노선이라고 부르든지 간에 우리는 우리의 응용 프로그램에서 끝날 것이다. 이 노선을 알게 될 것이기 때문에 그에 상응하는 행동을 취할 수 있다.나의 작은 예에서, 나는 주소 표시줄에 표시된 URL을 바꾸고 내용을 처리하기만 하면 된다.이런 현대 구조에서 동적 루트는 기본적으로 이렇게 일한다.

<!DOCTYPE html>
<html>
  <head>
    <title>My App</title>
  </head>
  <body>
    <h1>My App</h1>
    <h2 id="header">Post Path: {PATH}</h2>
  </body>
  <script>
    if (window.location.hash.length > 1) {
      const path = window.location.hash.replace('#', '')
      history.pushState({ page: 1 }, "Some title", '/static-dynamic-routing' + path)

      document.getElementById('header').innerHTML = document.getElementById('header').innerHTML.replace('{PATH}', path)
    }
  </script>
</html>

브라우저에서 이 링크를 열려고 시도합니다. https://mktcode.github.io/static-dynamic-routing/posts/my-post
한순간에 브라우저의 주소 표시줄에서 볼 수 있습니다 #.이때 방향을 바꾸는 일이 일어났다. 그리고 우리는 그것이 일어난 적이 없는 척했다.기본적으로 그렇습니다.

Nuxt와 함께 사용합니다.js

만약 당신이 반응형 사람을 더 좋아한다면, 당신은 반드시 스스로 실현해야 한다.다음 것만 보여드릴게요.가자.
In Nuxt.js you can easily configure dynamic routes 비슷한 /pages/posts/_slug.vue 파일을 만듭니다.Nuxt는 나머지 작업을 완성할 것입니다. /posts/my-post-title 이런 노선이 있습니다.정적 사이트 모드에서도 작업을 할 수 있지만, 전제는 사이트가 통합된 Nuxt 서버나 같은 방식으로 설정된 다른 서버에 의해 전달된다는 것이다. (생각해 봐. 프런트엔드 컨트롤러 모드)GitHub 페이지는 작동하지 않으며 404페이지만 볼 수 있습니다.하지만 여기에는 Nuxt를 사용해도 내 방법이 완전히 유효하다는 증거가 있다.js:
https://mktcode.github.io/dynamic-nuxt-gh-pages/post/my-totally-dynamic-post-title
그것이 필요한 것은 the 404.html file in the static directory 와 router middleware 뿐이며,nuxt 내부에서 원본 루트로 방향을 바꾸어 브라우저의 주소 표시줄을 업데이트합니다.응용 프로그램에 라우트가 없는 경우 Nuxt error page가 표시됩니다.겸사겸사 한마디 하자면...이제 정상적인 HTML 앵커를 허용하려면 #!를 사용하여 리디렉션합니다.이전에 성공한 모든 것은 여전히 유효해야 한다. 그리고...GitHub 페이지의 동적 라우팅!좋아요.약간.

결말

나의 첫 문장을 좋아하길 바랍니다!:)계속해서 저와GitHub, 평론과 브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라브라더 많아!5년 후..."헤이, 내가 dev 문장을 쓰기 시작할 것 같아!"D

Reference

이 문제에 관하여(동적 라우팅이 있는 GitHub 페이지), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/mktcode/github-pages-with-dynamic-routes-dli

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)