@Knaackee 가능성을 시험해 보았습니까? 누군가가 RR의 모든 버전과 함께 작동하도록했는지 궁금합니다.

다음으로 자신의 라우터가 있는데 왜 RR을 사용합니까?

기존 앱을 Next로 이식 할 때 @sergiodxa 계량 옵션. 정적, 중첩 된 경로 구성이 작동하고 무엇을 계속 사용할 수 있는지 궁금합니다.

@oyeanuj 🤔 점진적으로 Next로 마이그레이션 할 수 있습니다. Next.js를 1 개의 경로를 처리하도록 설정하고 프록시를 사용하여 현재 앱과 Next.js를 모두 보유한 다음 두 번째 경로를 RR에서 Next.js로 이동하면됩니다. 마이그레이션하는 동안 현재 앱을 유지할 수있는 방법은 결국 Next.js에 모든 것이 포함됩니다.

예제를 살펴보면 next에는 RRv2-3과 같은 단일 라우팅 테이블이 있고 RRv4와 같은 "중첩 된 경로"를 지원하지 않는 것으로 보입니다. 이것들은 멋지다.

RR을 사용하려고하거나 모르는 큰주의 사항이 있습니까?

@igl 그것에 대한 해결책을

중첩 된 경로의 새로운 react-router 4 패러다임은 게임 체인저이며 현재 프로젝트에서 필수 항목입니다. rr4를 next.js와 함께 사용하는 데 성공한 사람이 있는지 궁금합니다.

MemoryRouter 는 의도 한대로 작동하지 않습니다 ...
그렇지 않으면 동적 구성 요소는 HashRouter 가 제대로 작동하는 클라이언트 측만 될 수 있습니다.

const AdminPage = dynamic(
  import('..../AdminPage'),
  { ssr: false }
);

나는 또한 @malixsys 접근 방식을 react-router 클라이언트 측 라우팅을 처리하고 next 라우터로 모든 서버 렌더링 콘텐츠를 처리하고 있습니다.

@malixsys @pegiadise 다음 라우터와 리 액트 라우터를 함께 사용하는 방법에 대한 자세한 정보를 제공 할 수 있습니까?

componentDidMount 플래그를 설정하고 플래그가 진실 일 때 <Router /> 조건부로 렌더링 할 수 있습니다. ( componentDidMount 는 서버에서 실행되지 않습니다 😉)

사실, 곧 Next.js에 React Router를 통합 할 예정입니다. :)
— https://twitter.com/rauchg/status/948318111828099072

여전히 일어나고 있습니까? V6 카나리아의 릴리스 정보를 볼 수 있지만 이에 대한 언급은 없습니다.

결국. 확실히 우리 마음에 있습니다. 지금 당장 다른 우선 순위가 있습니다 (레이아웃 구성 요소, 안정적인 개발 및 기타 오래 지속되는 몇 가지 미해결 문제).

부끄러운 일입니다. 팀의 우선 순위가 낮을 수 있지만 기본적으로 저와 같은 사람들이 사용을 시작하는 것을 막는 유일한 방법입니다. 라우트를 두 번 설정하고 포기해야한다는 내용에 도달 할 때까지 튜토리얼을 읽었습니다.

@timneutkens가 반응 라우터 통합을 추가하면 nextjs 채택을 늘리고 개발을 개선하는 데 도움이 될 것입니다. 저와 같은 개발자들은 이런 일이 일어나기를 원합니다. 우선 순위를 높이는 것을 고려해주세요.

부끄러운 일입니다. 팀의 우선 순위가 낮을 수 있지만 기본적으로 저와 같은 사람들이 사용을 시작하는 것을 막는 유일한 방법입니다.

같은.

추적 할 수 있도록 적어도이 문제를 다시 열 수 있습니까?

나는 이것을 다시 열 것입니다. 그러나 이것은 오픈 소스 프로젝트 이고 우리는 모든 것에 Next.js를 사용하기 때문에 현재 zeit.co에 대해 그다지 강력한 사례를 가지고 있지 않습니다.

이것이 제가 장기 목표의 일부이며 즉시 구현할 수 없다고 말한 이유입니다.하지만 우리는 그것을 위해 노력하고 있습니다.

Next 6에서 소개 한 기능은 실제로 React Router 지원을 위해 작동하고 있습니다.

Next 6에 대한 다른 우선 순위는 Next.js의 안정성과 확장 성을 엄청나게 향상 시키는데, 예를 들어 100 배 더 빠른 페이지 확인, 앱 구성 요소, 개발중인 다음 내보내기 작업 만들기, babel 7 등.

나는 이것이 나의 이전 의견에 대해 자세히 설명하기를 바랍니다.

따라서 TLDR은 다음과 같습니다.

• 우리는 그것을 할 것이지만 즉시는 아닙니다
• Next 6에는 Next.js의 여러 부분이 많이 개선되었습니다.

@timneutkens 의 의견을 더 확장하기 위해 : 우리는 확실히 RR을 원하지만 현재 라우터에 우선 순위를 부여하는 긴급한 제한이 없습니다. 상상할 수있는 모든 라우팅 사용 사례가 현재 Next.js API로 성공적으로 구현되었습니다.

React Router 지원 을 가 있습니다 .

• 자체 라우터를 유지 관리 할 필요없이 자체 Next.js 코드베이스를 단순화하고 크기를 줄이고 모듈화합니다.
• 이미 RR을 사용하고있는 대규모 애플리케이션의 마이그레이션 경로 단순화

따라서이 문제를 계속 공개해야한다는 데 동의합니다!

대위법으로 react-router가 없다는 것은 next가 relay-modern과 잘 작동한다는 것을 의미하며 우리가 이전 react-router 앱에서 next로 전환 한 이유 중 하나였습니다.

@merry 작년에 릴레이 모던으로 RRv4 앱에서 작업했는지 여부. 좀 더 구체적으로 설명 하시겠습니까?
둘 중 하나 때문에 심각한 문제가 있었던 기억이 없습니다.

@igl 이것은 릴레이 문서에 따른 것입니다 : https://facebook.github.io/relay/docs/en/routing.html#react -router-https-reacttrainingcom-react-router

문제는 RRv4의 구성 요소 접근 방식이 사전 컴파일 단계에서 결정 성을 허용하지 않아 클라이언트에서 요청 폭포가 발생할 수 있다는 것입니다.

@rauchg 흥미롭게도 Next의 라우터에 대한 나의 이해는 중첩 라우팅 개념을 지원하지 않기 때문에 페이지 내에서 탐색하는 동안 외부 마크 업을 유지할 수 있다는 것입니다. 현재 라우터로이를 가능하게하는 방법이 있는지 알고 있습니까?

@dbbk 는 nextgram 예제 앱 (https://github.com/now-examples/nextgram)을 확인합니다.

다음 5 번에서는 모든 페이지가 확장되는 최상위 레이아웃 구성 요소를 사용하여 "외부 마크 업"을 수행합니다. 기본 레이아웃에는 상단 탐색이 있고, 목록 / 세부 정보 / 기타에 대한 기본을 확장하는 몇 가지 하위 레이아웃이 있습니다. 페이지 구성 요소는 이러한 하위 레이아웃을 고유 한 특정 콘텐츠로 확장합니다. 다음 6에서는 _app.js 사용하여 기본 "외부 마크 업"을 수행 할 수도 있습니다.

다음 버전은 React Router가 아닌 라우팅 솔루션을 선택하도록 구성 할 수 있습니까?

안녕, 난 단지 (사용 페이지에 소품을 통과하기 위해 라우터 반응 할 필요 <Route render ={} /> 대신 <Route component ={} /> 나는이 다음에 할 수있는)?

https://github.com/zachrbrown/next-react-router를 참조 https://github.com/zachrbrown/next-react-router/blob/master/src/IsomorphicRouter.js에 몇 가지 간단한 설명이

예제를 살펴보면 next에는 RRv2-3과 같은 단일 라우팅 테이블이 있고 RRv4와 같은 "중첩 된 경로"를 지원하지 않는 것으로 보입니다. 이것들은 멋지다.

안녕하세요,

이것은 단일 경로에 대해 단일 페이지를 만들어야 함을 의미합니까?

2 개의 경로 sign up , log in 가 있다고 가정 해 보겠습니다. 동일한 레이아웃을 공유하는 1 페이지가있을 것입니다. 유일한 차이점은 양식 영역입니다. pages 폴더에 파일 1 개를 생성하면됩니다. 그러나 다음 경로에서는 pages 폴더에 2 개의 파일을 만들어야합니다. 맞나요?

그렇다면 레이아웃은 양식 영역뿐만 아니라 모든 탐색과 함께 다시 마운트됩니다.

https://github.com/zeit/next.js/issues/75

@ 7c78 할 수있는 한 가지는 모든 페이지에 대한 영구 페이지 레이아웃에 _app.js 를 활용하는 것입니다. 또 다른 작업은 원하는 것을 얻기 위해 다양한 페이지에서 재사용 할 수있는 공유 레이아웃 구성 요소를 만드는 것입니다.

// pages/login.js

class LoginPage extends React.Component {
  render() {
    return (
      <AuthForm>    // same component can be reused in signup
        <form>
          ...implementation of login
        </form>
      </AuthForm>
    );
  }
}

또한 최근에 수행 한 작업을 수행하고 페이지 구성 요소가 모두 확장하는 기본 레이아웃 구성 요소를 정의 할 수 있습니다.

//layouts/baseAuth.js

class BaseAuth extends React.Component {
  abstract formContent();  // we use typescript, but you can have the same concepts
  abstract formSubmit():

  render() {
    return (
      <SomeStyledDiv>
        <form>
          {this.formContent()}
          {this.formSubmit()}
        </form>
      </SomeStyledDiv>
    );
  }
}

그런 다음 로그인 및 가입 페이지에서 BaseAuth를 확장하고 각각에 formContent 및 formSubmit 를 정의합니다 (정확한 요구 사항을 모르기 때문에 장난감 예제입니다).

안녕하세요.
나는 현재 당신의 접근 방식을 사용하고 있으며 다음 예제도 그것을 사용합니다.

그러나 내 관심사는 별도의 양식에 대해 별도의 페이지를 만들어야한다는 것입니다. 그것은 레이아웃이 재사용되지만 페이지는 아닙니다. 그리고 레이아웃은 모든 탐색과 함께 다시 마운트됩니다.

RRv4에서는 단일 페이지가 있으며 양식은 전체 페이지가 아닌 경로를 기반으로 렌더링 / 재 마운트됩니다. 경로는 구성 요소 일뿐입니다.

빠른 응답에 감사드립니다!

@ 7c78 vDOM 이 동일한 상태로 확인 될 때 ​​DOM 노드가 다시 사용된다고 생각하지만 다시 마운트하는 것은 사실입니다.

우리는 또한 릴레이 모던과 함께 리 액트 라우터를 사용할 수 없기 때문에 우리가 매우 염려 해 왔던 것이 아닙니다. 그래서 우리는 상관없이이 패턴을 사용해야했습니다.

@merry 서버가 모든 경로에 대해 새 문서 / html을 반환하기 때문에 vDOM에 대해 잘 모르겠습니다. 죄송합니다.이 가정을 무시하십시오. 저는 단지 초보자 일뿐입니다.

어쨌든이 패턴을 사용해야한다는 데 동의합니다. 감사!

전체 앱이 pages / index.js에 있도록하여 next.js와 함께 RR을 사용할 수 있지만, 즉시 코드 분할과 같은 다음의 장점 중 일부를 잃고 직접 설정해야합니다.

Reach Router가 고려된다면 그것을 좋아할 것입니다. react-router와 매우 유사하며 몇 가지 중요한 이점을 제공합니다.

• 링크 생성 및 포커스 관리 (https://reach.tech/router/accessibility)와 관련된 몇 가지 중요한 문제를 해결합니다.
• 무게가 적음 (작성 당시)
  
  
  
  • @ reach / [email protected] : 18.7 kB / 6kB ( 링크 )
  
  
  • [email protected] : 44.1Kb / 10.4kB ( 링크 )
  
  

도달 라우터도 훌륭합니다 🥇

RR 스타일의 동적 경로는 좋은 API이지만 정적 (정적으로 분석 가능한) 라우팅도 많은 이점을 제공합니다. 두 접근법 모두 슬램 덩크 승자가 아닙니다.

@sorokinvj 플러그인을 통해서만 지원됩니다 (현재) .. https://github.com/fridays/next-routes

정적 링크는 너무 기본적이어서 링크의 매개 변수도 지원하지 않습니다.

나는 타사 패키지 다음 경로를 사용하고 있습니다 .https : //github.com/fridays/next-routes

내 iPhone에서 보냄

2018 년 10 월 24 일 23:01에 Andy Ingram [email protected] 은 다음과 같이 썼습니다.

RR 스타일의 동적 경로는 좋은 API이지만 정적 (정적으로 분석 가능한) 라우팅도 많은 이점을 제공합니다. 두 접근법 모두 슬램 덩크 승자가 아닙니다.

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

우리는 당분간 next-routes 도 사용하고 있지만 다음 팀은 정규식 파일 이름 (Sapper에서 영감을 얻음)을 통해 파일 시스템 라우팅에 경로 매개 변수를 추가하는 작업을하고 있다고 생각합니다.

@merrywhether 나는 next-routes 도 사용하고 있지만 이것이 Next.js 코어의 일부가되는 것을 선호합니다.

당신은 언급했습니다

다음 팀이 경로 매개 변수 추가 작업을하고 있다고 생각합니다 ...

이것에 대한 참고 문헌이 있습니까? 경로 매개 변수에 대한 미해결 문제일까요? 하나를 찾을 수 없습니다 ... 아마도 플러그인이 필요를 해결하고 앞으로 권장되는 솔루션이 될 것입니다.

@curran 소스는

이 문제는 2017 년 4 월 5 일에 제기되었으며 지금은 2019 년 2 월 27 일입니다. 거의 2 년 동안 해결책이 없습니다.
절반 정도의 내장 라우터를 좋은 것으로 교체 할 때가 되었을까요?

아야. 이는 라우팅 솔루션에 많은 시간을 투자 한 NextJS 개발자에게 상당히 모욕적입니다.

처음에는 ReactRouter를 놓쳤습니다. 이제는 누군가가 나에게 상기시키기 전까지 NextJS가 다른 라우터를 가지고 있다는 사실조차 기억하지 못합니다. 예를 들어 Verbose Link API는 (데이터 / API 아키텍처에 따라) 프록시로 래핑하기가 쉽습니다. 이 일급 비밀 공유 : 😆

import _Link from "next/link"
export function Link({as, children, href}) {
  as = as || QS.parse(U.parse(href).query || "").url || null // QS, U are parsing libs
  return <_Link as={as} href={href}>
    {children}
  </_Link>
}

<Link as="/about" href="/page?url=/about"/> verbose
→
<Link href="/page?url=/about"/> ok

나는 우리 모두가 부차적 인 것에 대해 불평하는 데 더 적은 시간을 소비해야한다고 생각한다 😉

@ ivan-kleshnin Nice 비슷한 래퍼를 추가했습니다.

이전 의견에 따라 https://www.contributor-covenant.org/version/1/4/code-of-conduct 를 가리키고 싶습니다.

댓글을 숨겼습니다.

대부분의 사용 사례에서 next/router 에 문제가 없습니다.
그러나 universal routing 부분에서 약간 개선되어야합니다.
Now 2 배포의 경우 now.json 만 가져 와서 내 애플리케이션에서 라우팅하는 데 사용하고 싶습니다.

RR4를 nextJs 프로젝트에 구현하려면 다음 두 가지를 수행해야합니다.

1. NextJS SSR 방지, next/dynamic 를 사용하면 그렇게 할 수 있습니다.
2. 사용 HashRouter 대신 BrowserRouter -> 사용자 재 장전 페이지, 브라우저가 이전 페이지를로드 할 수있는 경우 (안 404 페이지)

RR4를 nextJs 프로젝트에 구현하려면 다음 두 가지를 수행해야합니다.

1. NextJS SSR 방지, next/dynamic 를 사용하면 그렇게 할 수 있습니다.
2. 사용 HashRouter 대신 BrowserRouter -> 사용자 재 장전 페이지, 브라우저가 이전 페이지를로드 할 수있는 경우 (안 404 페이지)

이 답장을 보내 주셔서 감사합니다.

@ reach / router와 react-router 5가 병합됩니다 : https://reacttraining.com/blog/reach-react-router-future/

이것이 next.js에 어떤 영향을 미칩니 까?

@ alp82 Next.js는 여전히 React Router 또는 Reach Router를 사용하지 않기 때문에 Next.js에는 전혀 영향을주지 않습니다.

인덱스 페이지에서 여러 페이지 구성 요소를 렌더링하려면 nextjs의 스위치 경로 기능이 필요합니다.
그래서 어떻게 nextjs ....... ??에서 이것을 구현할 수 있습니까?

RR4를 nextJs 프로젝트에 구현하려면 다음 두 가지를 수행해야합니다.

1. NextJS SSR 방지, next/dynamic 를 사용하면 그렇게 할 수 있습니다.
2. 사용 HashRouter 대신 BrowserRouter -> 사용자 재 장전 페이지, 브라우저가 이전 페이지를로드 할 수있는 경우 (안 404 페이지)

404 오류를 발생시키지 않고 이전 페이지를 다시 렌더링하려면 익스프레스 서버 파일에서이 get 경로를 사용하십시오.

server.get ( 'your params', (req, res) => {
const actualPage = '/ your_page'
const queryParams = {id : req.params.id}
app.render (req, res, actualPage, queryParams)
})

내가 사용하는 접근 방식을 문서화 next.js 가진 react-router 단일 진입 점 파일 대신 기본 파일 시스템 기반 기능을 기본 SSR을 보존 완전히 라우팅 등을 제공합니다.

피드백을 받고 개선해 드리겠습니다.

설명서는 다음과 같이 사용할 수 있습니다.

• GitHub 저장소
• dev.to 게시

건배!

단일 진입 점으로 끝날 때 반응 라우터를 포함하는 것은 매우 권장하지 않습니다. 즉 (엄청나게) 개발 빌드가 느리고 클라이언트 측에 너무 많은 코드를 전달할 가능성이 높으며 자동 정적 내보내기와 같은 최적화에 대한 가시성이 떨어집니다.

@timneutkens 어쩌면 내가 틀렸다. 그러나 지연 로딩을 사용하면 라우팅 구성은 하나의 구성 파일 일뿐입니다. 여기서는 확장 성이나 성능에 영향을 미치지 않을 것입니다. 이것에 대해 더 배우고 싶습니다.
react-router의 장점은 개발자가 코드를 완전히 제어 할 수 있다는 것입니다.

@timneutkens , 여기서 논쟁을 시작하지는 않겠지 만 내 댓글 숨기기를 해제 해달라고 부탁드립니다. 나는 내 직업을 사용할 수있게 만들고 그것을 커뮤니티에 돌려주기 위해 시간을 보냈지 만 사람들을 침묵시키는 것이 오픈 소스 개발에 어떻게 도움이 될 수 있는지 모르겠습니다.

@timneutkens 는 당신이 언급 한 점에 관해서는 트레이드 오프 문제입니다. Mine은 Next.js가 다른 설정에서 어떻게 사용될 수 있는지를 보여주는 실험입니다.

클라이언트 측에 너무 많은 코드

모든 최신 번들은 클라이언트 자산을 청크로 분할 할 수 있으며 react-router 경로는 실제로 매우 편리한 분할 지점입니다.

더 높은 개발 빌드 시간

큰 프로젝트에 지불하는 대가이지만 적절한 웹팩 미세 조정으로는 해결할 수 없습니다.

정적 내보내기 없음

정적 내보내기가 중요한 최적화 레이어라는 데 동의합니다. 평균적인 Next.js 애플리케이션이 제공하는 대부분의 페이지는 어쨌든 동적 데이터를 검색해야하며 정적 내보내기의 이점을 얻을 수 없습니다.

이 문제에 대한 해결책이 부족하지 않습니다. 예 : 정적으로 내보낼 경로 목록을 수동으로 선언 할 수도 있습니다.

내가 댓글을 숨긴 이유는 이것이 높은 트래픽 문제이며 Next.js 앱 빌드에 대한 권장 사항을 반영하지 않기 때문입니다. 누군가가 여기서 react-router를 사용하려고한다면 그들은 여러분의 예제를 맹목적으로 사용하고 Next.js를 사용하여 라우팅을 올바르게 설정하는 방법을 조사하지 않을 것입니다.

큰 프로젝트에 지불하는 대가이지만 적절한 웹팩 미세 조정으로는 해결할 수 없습니다.

접근 방식에 따라 개발 시간 부팅 속도를 높일 수는 없습니다. webpack은 일반적인 구성 요소에 대한 편집 속도를 대폭 느리게 만드는 모든 단일 경로를 컴파일하고 감시하기 때문에 webpack 구성에 대한 특정 미세 조정이 없습니다. 따라서 Next.js에 주문형 항목이있는 이유 : https://nextjs.org/blog/next-8#improved -on-demand-entries

또한 경로 등의 (자동) 미리 가져 오기가 있습니다. 여기에 들어갈 수있는 세부 사항이 많이 있지만 tldr은 결국 개발자 경험과 앱이 더 나빠질 것이라는 것입니다.

사용하려는 유일한 시간이 이미 react-router를 사용하고있는 앱을 마이그레이션 한 다음 점차 여러 페이지로 이동하는 것임을 적절하게 반영하는 경우 댓글 숨김을 해제해도 괜찮습니다.

안녕하세요 @timneutkens
정적으로 분석 할 수있는 몇 가지 전문가를 계산해 보시고 동적 라우팅 솔루션으로는 불가능한 일이 있으십니까?

https://github.com/jaredpalmer/after.js 같은 것이 있습니까?

나는 모든 의견을 읽었으며 RR4 +가 next.js의 향후 반복에서 포함되는지 또는 선택 사항인지 아직 명확하지 않습니다. 라우터 로드맵 또는 유사한 것입니까?

@laurencefass (오늘 현재) react-router 를 지원할 계획이없는 것 같습니다.

나에게 Next.js의 라우팅 시스템은 충분히 성숙 해지고 있으므로 어쨌든 (더 이상) 필요하지 않을 것입니다. :)

"나에게 Next.js의 라우팅 시스템은 충분히 성숙 해져서 아마 (더 이상) 필요하지 않을 것입니다. :)"

기존 코드베이스에서 Next.js를 점진적으로 채택하려는 사람들을 제외하고. 더 유용한 토론은 아마도 "Next.js 라우팅 대 반응 라우터 라우팅"이 아닐 것입니다. 더 유용한 토론은 "react-router를 사용하여 거대한 앱을 Next.js로 점진적으로 마이그레이션하는 방법"이라고 생각합니다.

다음의 라우터는 경로보기를 중첩 할 수 없습니다. 그렇죠? 경로에 대한 모든 탐색은 DOM을 날려 버리고 새로 고칩니다. 중첩 된 뷰는 매우 일반적인 요구 사항입니다.

@dbbk https://github.com/jaredpalmer/after.js

@dbbk nextjs 팀이 작업 중이라고 들었습니다.

다음 js는 라우터에 매우 유연합니다. https://dev.to/toomuchdesign/next-js-react-router-2kl8

웹 사이트를 일반 JS 및 jQuery 코드에서 React로 이동하고 있습니다. 예전 코드와 달리 페이지를 변경할 때 음악이 멈추지 않도록해야해서 React Router를 사용했습니다.

이제 SEO 목적으로 Google 검색에서 좋은 트래픽이 발생했기 때문에이를 유지해야합니다. 따라서 더 나은 성능을 위해 Next.js와 함께 SSR을 선호합니다.

Next.js는 서버 측에서 페이지를 렌더링 할 수 있으며 클라이언트 측에서 페이지가로드되면 Next.js는 React Router 제어 하에서 탐색을 허용하므로 사용자가 음악을 듣고 있으면 Next.js 링크가 음악을 중지하려면 현재 페이지를 떠나야합니까?

O Next.js는 클라이언트 측 라우팅 만 만들 수 있습니까?

React Router를 통합하면이 문제를 해결할 수있을 것입니다. 앱이 클라이언트 측에 도달하면 연속 음악 재생이 필수이기 때문입니다.

다음 js는 라우터에 매우 유연합니다. https://dev.to/toomuchdesign/next-js-react-router-2kl8

@laurencefass , 아주 좋은 접근 방식입니다. 전에 읽었습니다. 그리고 기사는 Next.js 팀이 권장하지 않는다고 말합니다. 이유를 모르겠습니다. 하지만 나에게 좋은 것 같아

@KeitelDOG 를 위해 react-router가 필요하지 않습니다. Next.js 라우팅은 동일한 이점을 제공 할뿐만 아니라 자동 코드 분할 덕분에 앱이 더 가벼워집니다 (react-router로는 쉽게 얻을 수 없음).

_edit : 그냥 추가하겠습니다 : react-router의 유일한 장점은 동일한보기 기능에 쉽게 중첩 된 경로 일 수 있습니다. Next.js 라우터는 사용 사례의 95 %를 해결해야합니다 _

@martpie 응답 Link 구성 요소로 보았습니다. 그런 다음 Next.js는 내가 원하는 믹스 서버-클라이언트입니다.

그리고 동적으로 중첩 된 경로를 세부적으로 제어하는 ​​구성 요소의 경우 React Router를 사용하는 것이 좋습니다. 그러나 React 웹 사이트를 Next.js로 변경하지 않고 대신 JS-jQuery 웹 사이트를 내 SEO 이점을 잃지 않고 React 다중 페이지 애플리케이션으로 변경하기 위해 계획하고 테스트하기 때문에 해결 방법을 얻을 수 있다고 확신합니다. Google에서. 그래서 Next.js로 가야한다고 생각합니다.

@timneutkens Next.js 10에서이를 지원할 계획이 있습니까?

@TrejGun 감사합니다, 그것은 확실히 주제에서 벗어난 것이 아닙니다.

계획이 있습니까?
next/router 는 훌륭하고 많은 도움을 제공합니다. 그러나 복잡한 응용 프로그램에 대처하려면 더 전문적인 라우터가 필요합니다. React-router는 라우터의 선두 주자입니다.
after.js 를 참조 할 수 있습니다.

예,이 페이지 기반 시스템은 중첩 된 경로의 이점을 얻을 수있는 복잡한 데이터 기반 애플리케이션을 처리 할만큼 정교하지 않습니다.

React-router는 현재까지 최고의 라우터가 될 v6 버전 을 곧 출시 할 예정입니다. next.js 지원을 기대하고 있습니다.

더 나은 접근 방식은 next.js 와 router 을 분리하여 사람들이 좋아하는 router 자유롭게 선택할 수 있도록하는 것입니다.

이전 댓글에 +1. next.js는 내가 사용하지 않는 유일한 이유는 라우터의 유연성이 부족하기 때문입니다. 향후 릴리스에서 React Router 6을 지원하거나 라우터를 스왑 가능하게 만드십시오.

React Router를 정말 좋아하는 사람들은 같은 제작자가 만든 React Router를 사용하는 Next.js 대안 인 "Remix"라는 새 프로젝트를 따르는 데 관심이있을 것입니다.

• https://twitter.com/remix_run/status/1253043162714525696
• https://remix.run

문제는 프레임 워크가 SSR, Server Side Props 등으로 인해 해당 라우터에 깊이 연결되어 있다는 것입니다.

Next는 성능을 염두에두고 구축되었으며 서버 측 react-router는 렌더링하려는 항목과 필요한 데이터를 알기 전에 DOM 트리를 걸어야한다는 점에서 성능에 큰 영향을 미칩니다. getInitialProps 의 전체 목적은 데이터를 가져 오기 전에 반응을 일시적으로 렌더링 할 필요가 없도록하는 것입니다. 이는 많은 프레임 워크가 서버 (및 클라이언트에서 다음과 같이 나타남)에서 경험하는 일반적인 함정입니다. 폭포 요청). 다음으로 각 최상위 페이지에서 다양한 하위 구성 요소가 필요로 할 수있는 다양한 데이터 패턴을 _all_ 선언하고 전체 요청 경로에서 분기 (또는 대규모 단일 오버 페치 수행)함으로써이 문제를 해결할 수 있습니다. 실제로 각 페이지를 개별적으로 선언하는 것과 크게 다르지 않습니다.

이것은 Relay가 react-router 와도 호환되지 않는 것과 같은 이유이며 facebook.com이 복잡한 웹 사이트가 아니라고 비난 할 수는 없습니다.

Next 라우터로 작업하기위한 주요 성공적인 전략은 구성 가능성 (어쨌든 현대 React의 추진 추세)으로 기울여 주요 중복없이 구성 요소를 재사용 할 수있는 동시에 모든 데이터를 가져올 수있는 효율적인 SSR을 보유하는 것입니다. ( getInitialProps 를 통해) React 렌더러와 대화하기 전에.

나는 나무를 걷는 것에 따른 성능 저하가 과장된 것 같다. 오늘날 많은 프로덕션 응용 프로그램이 예를 들어 Apollo로이 작업을 수행하고 있으며 괜찮은 것 같습니다.

또한 서버가 너무 많은 작업을 수행하는 것을 정말로 덜어주고 싶다면 CDN에서 응답을 캐시 할 수도 있습니다.

물론, React-router가 (AFAICT) 현재 구현에서 Next와 근본적으로 호환되지 않는 주된 이유를 지적하고 있습니다. 느린 콜드 스타트 ​​시간으로 무료 Heroku 다이노를 행복하게 사용하는 사람들이 입증했듯이 많은 사이트에는 실제로 성능이 전혀 필요하지 않습니다. 완벽하게 맞을 수 있습니다). 그러나 Next는 서버 응답 시간이 눈에 띄게 느려지는 것에 관심을 갖기 때문에 성능에 덜 공격적이라면이를 사용하는 일부 대기업들에게 인기가 없을 것입니다. 일부 사이트에서 문제가되지 않았다면 사람들은 React의 스트리밍 렌더러를 사용하지 않고 (그리고 개선을 간절히 기다리고 있습니다) 두 개의 렌더링이 완료되기 전에 응답을 시작하지 않을 것입니다.

CDN은 응답을 캐시 할 수 있지만 많은 개인화 / 로그인 옵션을 제거합니다 (적중률을 높이거나 클라이언트에 대한 부분 페이지 렌더링을 연기하려는 정도와의 상충 관계이기 때문에). 전체 앱을 CDN 캐시 할 수 있다면 CRA 및 react-snapshot 하고 서버를 완전히 피하는 것이 좋습니다. 서버가 얼마나 많은 작업을 수행하는지에 대한 질문이 아니라 요청에 응답하는 데 걸리는 시간입니다.

그리고 Apollo는 Relay와 같은보다 독단적이고 성능 지향적 인 프레임 워크에 비해 성능보다 사용 편의성을 강조하는 프레임 워크의 훌륭한 예입니다. 그것은 모두 스펙트럼입니다.

네, 충분히 공평하다고 생각합니다. 그러나 나는 remix.run이 어떻게 밝혀 졌는지 궁금합니다. 아마도 그들은 react-router 와 함께 작동하도록 새로운 접근 방식을 제시 할 것입니다. 네, 중첩 된 경로가 필수는 아니지만, 경로에 따라 내부 UI의 일부를 변경하는 것이 다른 페이지를 가지고 각 페이지를 다른 레이아웃으로 래핑하는 것보다 더 직관적이라는 데 동의해야합니다.

다음 9.3로, 거기에 getStaticPaths 에 추가로 getServerSideProps 도움에 프레임 워크는 경로가 루트 매개 변수가있는 경우 경로가 미리 렌더링하는 발견 할 수 있습니다. react-router로 비슷한 접근 방식을 취할 수 있습니다.

@merryweather : "Next는 성능을 염두에두고 구축되었으며, 서버 측 react-router는 렌더링 할 대상을 알기 전에 DOM 트리를 살펴 봐야한다는 점에서 성능에 큰 영향을 미칩니다."

순진한 질문 : 클라이언트에서 코드가 실행되면 최상위 링크를 렌더링하고 가져 오기 / 프리 페치 / 캐시 할 수 있습니까? 클라이언트가 어디를 탐색할지 모르는 경우 서버에서 DOM 트리를 탐색하는 것이 합리적입니까?

순진한 작업 시나리오 : 클라이언트가 URL을 요청하면 최상위 링크와 기본 활성 링크 콘텐츠를 렌더링하고 요청시 다른 모든 항목을 ajax / 가져옵니다 (또는 페이지가로드되면 백그라운드에서 프리 페치). 다른 모든 항목에는 하위 수준이 모두 포함됩니다. 경로 ... 헹구고 반복 ...?

@laurencefass 그러나 최상위 링크조차도 코드에 있으며 올바르게 발견해야합니까? 아니면 react-router와 함께 파일 시스템 라우팅을 사용하여 최상위 링크를 찾을 수 있도록 하시겠습니까?

@ avin-kavish Im은 구현에 대한 세부 정보에 대답하는 가장 좋은 사람은 아니지만 클라이언트에서는 초기 화면 콘텐츠 (최상위 링크 + 기본 콘텐츠) 만 렌더링하면됩니다. 다른 것은 내가 생각하는 첫 번째로드에서 중복됩니다. 그렇다면 왜 서버에서 DOM을 사용합니까?

Next.js의 주요 문제는 라우터가 아니라 getInitialProps , getServerProps 또는 getStaticProps 의 데이터 가져 오기 패턴입니다. 왜 ? 필요한 구성 요소에 대한 데이터 격리를 중단하기 때문입니다. 예를 들어 메뉴에 대한 데이터를 가져 오려는 경우 어디에서 가져 오겠습니까? 모르겠어요. pages 와 같은 상위 구성 요소는 그것에 대해 아무것도 알지 못합니다.

Next.js의 주요 문제는 라우터가 아니라 getInitialProps , getServerProps 또는 getStaticProps 의 데이터 가져 오기 패턴입니다. 왜 ? 필요한 구성 요소에 대한 데이터 격리를 중단하기 때문입니다. 예를 들어 메뉴에 대한 데이터를 가져 오려는 경우 어디에서 가져 오겠습니까? 모르겠어요. pages 와 같은 상위 구성 요소는 그것에 대해 아무것도 알지 못합니다.

자세히 설명해 주시겠습니까? 대체 솔루션은 무엇입니까?

@lishine 여기에서 약간의 주제를 벗어난 것에 대해 죄송하지만 대부분의 경우 라우터가 여기에서 주요 문제라는 것을 알지 못합니다. Next.js 라우터는 훌륭하고 선언적이며 구성에 대한 규칙이 좋습니다. Next.js에서 사용할 수없는 유일한 것은 getInitialProps , ...와 같은 데이터 가져 오기 방법입니다.
내 앱에서 각 구성 요소는 graphql 또는 rest에 관계없이 동일한 위치, 동일한 파일에서 자체 데이터를 선언해야합니다.
상위 페이지 구성 요소는 하위 구성 요소를 구성하기위한 것이며 데이터를 가져 오는 것은 작업이 아닙니다. 자식 구성 요소는 부모가 아닌 자체 데이터를 가져와야합니다.

명확성을 위해 앱에 사용하는 코드 샘플은 다음과 같습니다.

const query = `
{
  result:users(
    where:{
      _and:[{
        active:{
          _eq:true
        }
      }, {
        is_exam_manager:{
          _eq:true
        }
      }]
    },
    order_by:{
      created_at:desc_nulls_last
    }
  ){
    id
    key:id
    user_code
    first_name
    last_name
    password
    active
  }
}
`
const Main = (props: any) => {
  const {
    data: { result }
  } = props
  return (
    <div>
      <Add title={'Add user'} role={'exam_manager'} />
      <Table
        columns={columns}
        dataSource={result}
        bordered={true}
        size={'small'}
      />
    </div>
  )
}
const MainWithData = graphql(query)(Main)
export default MainWithData

보시다시피 자체 데이터가있는 구성 요소가 하나 있습니다. 원하는 곳에 둘 수 있습니다.

물론 Next.js 패턴을 아무 문제없이 사용할 수 있지만 제 경우에는 나중에 쉽게 유지 관리하고 리팩토링하기 위해 가능한 한 데이터 및 구성 요소에 대한 격리를 선호합니다.

내 앱에서 각 구성 요소는 graphql 또는 rest에 관계없이 동일한 위치, 동일한 파일에서 자체 데이터를 선언해야합니다.
상위 페이지 구성 요소는 하위 구성 요소를 구성하기위한 것이며 데이터를 가져 오는 것은 작업이 아닙니다. 자식 구성 요소는 부모가 아닌 자체 데이터를 가져와야합니다.

저도 같은 방식으로 사용합니다.
따라서 SSR 가져 오기를 사용하지 않습니다.
그렇다면 사람들은 실제로 Next.js로 SSR 가져 오기를 어떻게 수행합니까?!

@linshine 우리는 최상위 페이지 수준에서 필요한 것을 다운로드해야합니다.

@lishine 여기에서 약간의 주제를 벗어난 것에 대해 죄송하지만 대부분의 경우 라우터가 여기에서 주요 문제라는 것을 알지 못합니다. Next.js 라우터는 훌륭하고 선언적이며 구성에 대한 규칙이 좋습니다. Next.js에서 사용할 수없는 유일한 것은 getInitialProps , ...와 같은 데이터 가져 오기 방법입니다.
내 앱에서 각 구성 요소는 graphql 또는 rest에 관계없이 동일한 위치, 동일한 파일에서 자체 데이터를 선언해야합니다.
상위 페이지 구성 요소는 하위 구성 요소를 구성하기위한 것이며 데이터를 가져 오는 것은 작업이 아닙니다. 자식 구성 요소는 부모가 아닌 자체 데이터를 가져와야합니다.

명확성을 위해 앱에 사용하는 코드 샘플은 다음과 같습니다.

...

보시다시피 자체 데이터가있는 구성 요소가 하나 있습니다. 원하는 곳에 둘 수 있습니다.

물론 Next.js 패턴을 아무 문제없이 사용할 수 있지만 제 경우에는 나중에 쉽게 유지 관리하고 리팩토링하기 위해 가능한 한 데이터 및 구성 요소에 대한 격리를 선호합니다.

@ revskill10 자식이 데이터 조각을 선언하고 부모가 최상위 쿼리에 해당 조각을 포함하도록 할 수없는 이유는 무엇입니까? 특히 하위 관련 조각을 더 많이 만들면 완벽한 데이터 격리가 가능합니다. 자식 조각이있는 부모 쿼리를 갖는 것은 JSX에서 자식을 선언하는 것과 다르지 않으므로 동일한 수준의 결합을 가지지 만 요청 폭포를 피할 수 있습니다 (슬프게도 REST에서는 훨씬 더 어렵습니다).

Relay-Next 앱이 있으며이 패턴은 데이터 캡슐화 및 재사용 가능한 구성으로 완벽하게 작동하며 getInitialProps 를 쉽게 활용합니다.

@merrywhether much harder in REST 에 대해서는 말할 것도없고, 접근 방식에 문제가 있습니다. 어떤 fragments 가 SSG / SSR이 될지 아니면 CSR이 될지 결정할 수 없다는 것입니다.
내 접근 방식에서는 { noSSR: true/false} 해당 구성 요소를 가져 오는 것만 큼 쉽습니다.

주요 라우팅 라이브러리와 기본 구현을 공유하지 않는 공급 업체별 라우팅 라이브러리에 대한 종속은 매우 우려되는 부분입니다.

최근에 Next.js를 검토하여 현재 클라이언트를 위해 구축되는 여러 프런트 엔드 애플리케이션간에 공유되는 공통 코어의 기반으로 사용해야하는지 여부를 평가했습니다. Next.js에는 잠재력이 있습니다. 이 라우터는 내가 Next.js를 거부하고 대신 CRA를 이러한 애플리케이션의 기반으로 유지하게 된 주요 이유 중 하나입니다.

react-router / @reach/router 의 구성 요소 기반 최상위 API를 SSR의 기반으로 사용하는 것이 어려움을 이해합니다. 그러나 이것이 기본 구현이 완전히 맞춤화 된 이유는 아닙니다. Gatsby의 SSG는 Next.js와 같은 관심사를 갖고 있으며 파일 기반 라우팅 구조에 준 유사합니다. 하지만 내 이해에 Gatsby는 휠을 재발 명하거나 다른 라이브러리에서 사용하는 Link API와 일치하지 않는 Link API를 노출하는 대신 라우팅 구현을 강화하기 위해 후드 아래에서 @reach/router 를 사용합니다.

@dantman Next.js 대안으로 무엇을 선택했는지 물어볼 수 있습니다. 서버 측 렌더링이 필요하다고 가정합니다 .... 저는 After.js를 사용해 보았습니다. Zeit에서 지원하지 않는 경우 Next.js에서 구현하는 방법에 대한 영감 / 아이디어를 제공 할 수 있습니다.

@dantman Next.js 대안으로 무엇을 선택했는지 물어볼 수 있습니다. 서버 측 렌더링이 필요하다고 가정합니다 .... 저는 After.js를 사용해 보았습니다. Zeit에서 지원하지 않는 경우 Next.js에서 구현하는 방법에 대한 영감 / 아이디어를 제공 할 수 있습니다.

죄송합니다. 도움이되는 답변이 없습니다. SSR은 어려운 요구 사항이 아니었기 때문에 프로토 타입에 사용 된 CRA를 계속 사용했습니다.

Next.js는 최근에 SSR / SSG / 클라이언트 전용 페이지를 혼합하고 동형 앱 또는 정적 / PWA 앱으로 실행할 수있는 기능을 얻었 기 때문에 범용 프레임 워크로서의 가능성이 있다고 생각했습니다. WebPack 사용자 정의는 CRA가 globalize-compiler를 사용하여 어렵게 만들고 있기 때문에 유혹적이었습니다. Next.js 서버는 GraphQL / REST 브리지를위한 API 서버가 필요했기 때문에 중립적 / 긍정적이었습니다. 그리고 SSR / SSG의 옵션은 긍정적이었습니다. 핵심을 구축 할 때 6 개의 애플리케이션이 기반을두고 있으며 미래에 유용 할 수 있다는 것은 불가능하지 않습니다. 그러나 Next.js의 SSR이 작동하는 방식에도 몇 가지 문제가 있었으며 이러한 긍정적 인 점은 라우터로 인한 문제의 가치가 없었습니다.

@dantman

주요 라우팅 라이브러리와 기본 구현을 공유하지 않는 공급 업체별 라우팅 라이브러리에 대한 종속은 매우 우려되는 부분입니다.

뛰어난 안정성과 "제품 / 시장 적합성"으로 인해 3 년 동안 변경되지 않은 API로 오픈 소스 구성 요소를 "잠금"으로 한정하는 것은 매우 이상합니다.

Next.js는 성공 했으며 라우터 에도 불구하고

많은 사람들이 제가 트위터에 댓글을다는 것을 보았 듯이, 옛날에 우리는 일부 라우터에서 병합하는 것을 진지하게 즐겼습니다 (하지만 Reach 또는 React Router 중 어느 것이 표준인지, 어떤 주요 버전인지 혼란 스럽지만). 그러나 세상은 우리를 다른 흥미로운 방향으로 이끌었습니다. 실제로 모든 사람들이 Next.js로 계속 성공하고 멋진 제품을 구축했기 때문에 실제로 추가의 요점이 무엇인지 몰랐습니다.

다른 라우터 API를 원하는 이유를 사람들에게 실제로 물어볼 때 가장 자주 등장하는 이유는 사람들이 라우터에 구축 된 자체 개발 프레임 워크 솔루션에 갇혀 있고 불만스러워서 Next로 마이그레이션하기를 기다릴 수 없기 때문입니다. . 제품 디자인에 뿌리를 둔 이유가 아니 었습니다.

Next가 라우터 덕분에 성공했다고 말하면 두 가지 문제가 제거 되었기 때문입니다.
1️⃣ 라우터를 선택해야한다는 생각 . 이것을 제거하는 것은 돌이켜 보면 훌륭한 결정입니다. 안정적인 라우터를 갖춘 Next.js가 존재하는 동안 라우터 세계는 분열되어 모든 종류의 API 변경을 시작했습니다.

2️⃣ 라우터의 학습 곡선 . 라우팅에 대한 많은 워크샵과 자습서가 제공되었지만 Next.js 파일 시스템 우선 라우팅은 설명하는 데 2 ​​초가 걸리며 놀라운 것을 빌드 할 수있는 플랫폼을 제공하며 제품 개발로 바로 이동합니다.

이 마지막 요점을 강조하고 싶습니다. Next.js에 구축 된 세계에서 가장 빠르게 성장하는 최신 웹 사이트 중 하나 인 TikTok.com을 고려해보세요. 해당 웹 사이트의 전체 라우팅 토폴로지는 2 초 학습 곡선으로 설명 할 수 있습니다. https://www.tiktok.com/@sheezus.christ/video/6824007862197439750 은 pages/[user]/video/[id].js 이고 https://www.tiktok.com/trending 은 pages/trending.js

하이브리드 정적 / SSG / SSR과 같이 귀하가 언급 한 최근 Next.js 혁신 중 상당수는 라우터 설계를 통해 활성화됩니다. 사실, 라우터는 클라이언트에게 더 적은 JS를 제공하기 위해 앞으로 나올 다른 많은 유사한 최적화를 가능하게 할 것입니다.

그러나 Next.js의 SSR이 작동하는 방식에도 몇 가지 문제가 있었으며 이러한 긍정적 인 점은 라우터로 인한 문제의 가치가 없었습니다.

이것에 대해 듣고 싶습니다. 위의 예제는 Next.js 하이브리드 정적 / SSR로 구동되며 전반적으로 많은 성공을 거두었습니다!

이것은 정말 재미있는 스레드입니다. Next는 폭포 라우팅 (react-router 및 친구라고도 함)을 피해야하는 구체적인 이유가 있습니다. getInitialProps 는 많은 성능 최적화를 가능하게하고, 특히 일부 사람들이 특별히 이러한 최적화를 원하기 때문에 Next의 접근 방식은 꽤 인기가 있습니다. 성능은 디자인 트레이드 오프와 함께 제공되며 때로는 성능보다 디자인을 선택하는 것을 선호 할 수 있지만 도구가 잘못되는 것은 아니며 특정 프로젝트에 대해 잘못된 것입니다.

궁극적으로 react-router는 모든 라우팅 솔루션이 아닙니다. Next와 마찬가지로 장단점이 있습니다. FWIW, Facebook은 react-router를 사용하지 않으며 아마도 React 사용에 대해 한두 가지를 알고있을 것입니다. 따라서 대안이있는 것은 괜찮습니다. 실제로 JS 생태계의 가장 큰 장점 중 하나는 아이디어의 영역에서 서로 다른 요소가 경쟁하게하고 궁극적으로 우리 모두가 앞으로 나아갈 수 있도록하는 것입니다.

문제를 마무리하는 중이므로 라우팅 기능에 대한 의견, 기능 요청 및 버그 보고서에 항상 열려 있음을 분명히하고 싶습니다.

이상적으로는 제품 중심적인 것입니다 ( "X를해야하지만 불가능합니다"또는 "Y는 가능하지만 인체 공학적이지 않음"). 우리는 항상 훌륭한 사용자 경험으로 린 웹 사이트와 애플리케이션을 만드는 데 도움이되는 개선 사항을 찾고 있습니다 🤗

@rauchg 링크 에 href 및 as 두 개의 소품이있는 이유를 설명해 주시겠습니까? as prop의 값을 기반으로 의도 한 페이지를 추론 할 수없는 이유는 무엇입니까?

표현의 예를 들어 내가 같은 경로가있는 경우 /blog/:slug , 난 그냥에 HTTP 요청을 보낼 수 /blog/hello-world 하고 그것에 발 라우터를 기대합니다. /blog/:slug 와 blog/hello-world 를 모두 서버로 보낼 필요가 없습니다.

@ avin-kavish 좋은 질문입니다. URL에 표시되는 내용과로드 할 페이지 사이에는 중요한 차이가 있습니다. 사실 TikTok은이를 사용하여 특정 항목을 모달로 렌더링하므로 페이지를 새로 고치면 다른 페이지가됩니다. 그러나 여기서 한 가지 큰 개선 영역은 파일 시스템에있는 유효한 페이지를 참조하도록 정적으로 적용해야한다는 것입니다. 이에 대한 토론을 만들고 태그를 지정하여 후속 조치를 취할 것입니다!

https://github.com/zeit/next.js/issues/8207에 대한 문제가 이미 있다고 생각합니다.

누군가가 나처럼 모든 것을 다시 렌더링하지 않고 새 페이지로 이동할 수있는 "중첩 된 경로"기능과 같은 반응 라우터로이 문제를 본 경우 실제로보고 투표 할 수있는 전용 문제가 있습니다. 나는 방금 그것에 대해 알아 냈습니다 : https://github.com/zeit/next.js/issues/8193

헉

이 내 기본 문제에서 명확하게하기 위해하는 것은 RR / 도달 스타일의 구성 요소 API의 부족 아니다, 나는 SSR 수있는 파일 / 설정 기반의 API와 잘입니다. 나는 미래에 Suspense가 대체 SSR / 라우팅 API를 실행 가능하게 만들 수있을 것이라고 약간 낙관적이지만. 내 주요 문제는 라우터가 더 넓은 React 커뮤니티의 일부와 공유하는 대신 다시 구현되는 구현에 대한 일반적인 문제로 완전히 사용자 지정된다는 것입니다.

나는 Gatsby의 접근 방식이 수용 가능하다고 생각합니다. SSG 가능 파일 + 구성 기반 라우팅 API를 가지고 있으며 자체 향상된 링크 구성 요소를 내 보냅니다. 그러나 그들은 @reach/router 를 사용하여 기본 구현을 강화합니다.

주요 라우팅 라이브러리와 기본 구현을 공유하지 않는 공급 업체별 라우팅 라이브러리에 대한 종속은 매우 우려되는 부분입니다.

뛰어난 안정성과 "제품 / 시장 적합성"으로 인해 3 년 동안 변경되지 않은 API로 오픈 소스 구성 요소를 "잠금"으로 한정하는 것은 매우 이상합니다.

라우터는 본질적으로 Next.js에 연결되어 있습니다. 한 가지 이유로 Next.js를 채택한다는 것은 라우터에 묶여 있다는 것을 의미합니다. Next.js를 채택하고 나중에 next / router에 우리가하려는 일을 방해하는 한계가 있음을 발견하면 합리적인 탈출 해치가 전혀 없습니다. "Lock-in"은 그것에 대한 완벽한 설명입니다.

락인만으로는 큰 문제가되지 않습니다. Gatsby의 @reach/router 도 종속됩니다. 그러나 @reach/router 는 Gatsby 외부에서 사용됩니다. 전체 라우터 스택을 유지하기 위해 Gatsby 커뮤니티 만 신뢰할 필요는 없습니다. 나는 더 큰 커뮤니티가 그것에 의존하고 더 많은 이해 관계자가 (라우팅 스택에 특정한) 관련되어 유지되고, 어려운 라우팅 문제 (예 : 접근성)를 따라 잡으며, 더 다양한 커뮤니티에 의존하고 있다고 믿을 수 있습니다. 앞으로 발생할 수있는 잠재적으로 심각한 문제를 공유 할 가능성이 높습니다.

어떤 것이 당신의 마음 속에있는 표준, Reach 또는 React Router, 그리고 어떤 주요 버전인지 혼란 스럽지만

<Link> 의 실질적인 표준 측면에서. Reach와 React Router (RR)는 모두 매우 유사한 API를 공유합니다. 예를 들어 <Link to='/about'>About</Link> 는 RR과 Reach 모두에서 유효합니다 (물론 확장 Gatsby). 이것은 Next.js의 특이한 <Link href='/about'><a>About</a></Link> 를 훨씬 더 어리둥절하게 만듭니다.

Next.js가 사용해야한다고 생각하는 측면에서. Next.js가 이미 하나를 사용하고 있다면 특정 라이브러리에 묶여 있지는 않습니다. 내 주요 관심사는 라우팅 구현이 Next.js 외부의 더 넓은 커뮤니티와 라이브러리와 공유된다는 것입니다.

실제로 그것은 상대적으로 논쟁의 여지가 있습니다. 지금까지 대규모 사용자 기반의 RR 및 Reach 외에는 React 라우터를 보지 못했습니다. 그리고 RR과 Reach는 하나의 라이브러리가 될 것이므로 최종 결과로 시작하는 것이 동일합니다.

얼마 전에 Next를 시도했지만 라우터의 유연성이 부족하여 After.js https://github.com/jaredpalmer/after.js?utm_source=hashnode.com 이라는 Razzle 구현을 발견했습니다

React Router는 단지 패키지이므로 가져올 수 없으며 렌더링을 클라이언트 측으로 만 제한하여 필요한 곳에서 SPA처럼 작동하고 중첩 된 구성 요소 경로를 제공 할 수 있습니까? React 라우터는 페이지에 (잠재적으로) 포함되고 다른 구성 요소와 마찬가지로 Next.js 페이지 라우터와 함께로드되는 구성 요소 집합 일 뿐입니 까?

zeit이 RR을 통합 할 계획이라는 이전 스레드를 읽었는데 오늘날에도 여전히 사실입니까?

최후의 수단으로 next.js 라우터에 중첩 된 경로를 허용하지 않는 이유는 무엇이며 이러한 영역이 사전 렌더링되지 않을 것임을 분명히합니다. 최소한 경로에 따라 페이지의 하위 리소스가 변경되기를 원할 때 필연적으로 작성해야하는 if 조건을 작성하지 않으려는 노력을 절약 할 수 있습니다.

이 문제에 대한 투표를 추가하고 있습니다.

언급되지 않은 또 다른 프로는 RR이 더 테스트 가능하다는 것입니다. (AFAIK는 라우터 테스트를위한 공식 nextjs API가 없습니다) 테스트 및 스토리를 래핑하기위한 MemoryRouter가 있습니다.

Next.js에는 많은 좋은 기능 (자동 WebPack, 정적 파일 및 CRA와 같은 TypeScript가 있지만 PWA, API 경로, 서버리스 지원, 빠른 새로 고침, 웹 + 네이티브 앱에 대한 실험적인 Expo 지원)과 코어가 있습니다. API가 훌륭하지 않더라도 SSR 및 SSG 용입니다. 그러나 내장 라우팅 시스템과 SSR / SSG가 일부를 위해 작동하는 동안; 다른 사람들에게는 두 API의 한계가 해당 프로젝트에 대해 잘못된 트레이드 오프를 제공하기 때문에 개발을 방해합니다.

타협은 어떻습니까. Next.js에는 이미 플러그인이 있습니다. 라우터를 내부적으로 교체하는 대신 Next.js의 코어에서 라우터와 SSR API (예 : 경로 파일의 getStaticProps / getServerSideProps )를 분리하면 어떨까요? 예를 들어 매우 기본적인 핵심 부분을 @next/core 넣고 현재 의견이있는 라우터와 get*Props API를 @next/router 로 이동할 수 있습니다. 단순성과 이전 버전과의 호환성을 위해 next 는 @next/core 를 다시 내보내고 Vercel이 선호하는 라우터로 미리 구성되어 제공되는 프레임 워크가 될 수 있습니다. 그러나 커뮤니티가 Next.js의 좋은 부분을 목욕물과 함께 버려야하는 프로젝트에 더 적합한 서로 다른 절충안으로 라우터 및 SSR / SSG API를 개발하는 것이 가능할 것입니다.

Next.js 코어가 제공하기 위해 라우터 플러그인이 필요한 사항에 대한 몇 가지 생각 :

• {url, body 등} 요청이 주어지면 코어는 라우터 플러그인이이 요청을 문서 (문자열 또는 스트리밍)로 렌더링하거나 응답 (예 : 404 또는 리디렉션)을 던질 것으로 예상합니다.
• 내보낼 때 코어는 라우터 플러그인이 렌더링해야하는 페이지 목록을 제공 할 것으로 예상합니다.

@next/router 는 다음과 같은 작업을 수행하여 API를 통해 동일한 패턴을 구현할 것입니다.

• 요청이 주어지면 담당 경로 파일을 식별하고 정상적으로 렌더링합니다.
• 클라이언트에서 SSR API를 호출 할시기를 알고 필요한 경로를 렌더링하기 위해 현재 수행하는 것과 유사한 작업을 수행하는 경우 (API 기반 SSR API를 정상적인 API 경로로 이동할 수 있음)
• 페이지 파일 트리 및 getStaticPaths 를 사용하여 내보내기시 정적 페이지 목록 제공

@apollo/react-ssr 와 함께 React Router v6을 사용하고 react-ssr-prepass 또는 react@experimental 와 함께 Suspense를 사용하여 라우터 플러그인을 실험하는 것을 볼 수 있습니다. 동형 SSR 경로에 대한 SSR 전용 경로를 포기하고 get*Props 스타일 API를 제한하지 않고 SSR / SSG를 구현합니다.

내가 깨달은 것은 중첩 라우팅 + SSG를 현재 API를 손상시키지 않고 달성 할 수 있다는 것입니다. 따라서 현재 getStaticPaths 가) 있으므로이를 사용하여 사전 렌더링을 위해 중첩 된 경로를 힌트 할 수 있습니다. 예를 들면

/foo/[...slug] 경로가 주어지면

function FooPage() {

  return (
      <Switch>
          <Route path="/foo/bar">
              <SomeResource />
              <Route path={`${parenthPath}/baz`} component={SomeSubResource} />
          </Route>
          .... more routes
      </Switch>
  )
}

미리 렌더링 할 수 있습니다.

export async function getStaticPaths() {

  return {
    paths: [
      { slug: [ 'bar' ] },
      { slug: [ 'bar', 'baz' ] },
    ],
  }
}

현재 상황에서 next.js는 반응 형 페이지 생성의 편의성을 갖춘 서버 측 프레임 워크와 같습니다. react-router 만큼 강력하지 않습니다. 디렉토리 기반 라우팅은 앞에서 언급했듯이 tiktok과 같은 소비자 대면 사이트를 구축하는 데 적합 할 수 있지만 복잡한 데이터 기반 애플리케이션 포털의 경우 중첩 라우팅이 여전히 왕입니다. 이것이 단일 페이지 응용 프로그램이 처음에 만들어진 이유이며 전체 페이지를 교체하지 않고도 UI의 일부를 변경할 수 있습니다. 이것은 리소스-하위 리소스 관계를 매우 편리하게 모델링하는 데 활용할 수 있습니다. 현재 전자 상거래 사이트와 같은 소비자 사이트의 공개 페이지를 구축하려면 next.js 사용할 수 있지만 관리자, 구매자 및 판매자 포털과 같은 비공개 영역을 구축해야 할 때는 CRA로 전환하십시오.

@ avin-kavish의 주요 문제는 작동하도록 만드는 것이 아니라 최적화하는 것입니다. Next.js 기본의 각 페이지에는 자체 번들이 있으며 속도에 최적화되어 있습니다.

한 페이지에 많은 콘텐츠 / 하위 콘텐츠를 추가하기 시작하면 결국에는 상당히 큰 번들로 끝날 수 있습니다 (그 자체로는 "끔찍한"것은 아니지만 장단점). next/dynamic 생각으로 수동 최적화를 수행 할 수 있습니다. :)

@rauchg 유일한 차원은 다음 라우터가 좋은지 나쁜지 여부가 아닙니다. 또 다른 매우 중요한 것은 next.js 및 커뮤니티 지원과의 마이그레이션이며 https://github.com/vercel/next.js/issues/1632#issuecomment -633310614가 잘 설명합니다. Next.js는 고품질 SSR 앱에 필요한 많은 상용구를 추상화 할 수있는 좋은 솔루션이며, 따라서 많은 웹 앱에서 매우 매력적인 마이그레이션 대상입니다. 현재 문제는 next.js로 마이그레이션하기 위해 완전한 라우팅 재 작성이 필요하다는 것입니다.

이전에 @dantman이 제안한 플러그 형 라우팅은이 문제를 매우 우아한 문제로 해결하고 누구에게도 원칙을 판매하도록 요구하지 않습니다 😉

react-router (및 중첩 라우팅 솔루션)의 문제는 코드 자체를 실행 (또는 시뮬레이션)하지 않고는 특정 URL에 대한 관련 코드 경로를 사용할 수 없기 때문에 정적 분석을 훨씬 어렵게 만든다는 것입니다. 다음은 단순히 "웹 페이지에 UI 배치"프레임 워크 이상입니다. 예를 들어 Chrome 팀과 협력하여 더욱 최적화 된 번들링 전략을 개발했습니다.

react-router 사용자는 그 책임을 최종 사용자에게 전적으로 위임하기 때문에 react-loadable을 직접 사용하는 데 익숙하지만 Next는 쉽지 않은 추상화와 자동화를 시도합니다. 제안 된 플러그 형 라우터 접근 방식은 동일한 유형의 출력을 얻기 위해 프레임 워크에 광범위한 빌드 시간 정보를 제공하는 라우터 플러그인을 포함해야 할 것입니다. 모든 라우터는 자체 패턴을 기반으로 이러한 정보를 생성하는 방법을 알아야하기 때문입니다.

순전히 추측이지만 React가 Suspense를 완료하는 동안 많은 것들이 림보에 있다고 생각합니다. 라이브러리의 첫 번째 클래스 패턴이 모든 라우터 라이브러리에 큰 영향을 미치고 비동기 /로드 가능 빌드를위한 구체적인 기반을 제공하기 때문입니다. 번들 패턴.

짧은 이야기 / 아래에 대한 좋은 요약 : "모든 솔루션에 적합한 단일 크기"라는 것은 없습니다. 모든 것은 장단점이 있습니다. Next.js가 현재하는 방식의 모든 "장점"에는 단점이 있습니다. 가장 중요한 장점 / 단점은 각 프로젝트마다 다릅니다. 따라서 플러그 형 라우터 / ssg / ssr 아키텍처에 대한 권장 사항입니다. 프로젝트마다 다른 것이 필요하며 현재 Next.js는 절충에 대한 우선 순위가 Next.js에서 하드 코딩되는 방식과 일치하는 프로젝트에서만 작동합니다.

react-router (및 중첩 라우팅 솔루션)의 문제는 코드 자체를 실행 (또는 시뮬레이션)하지 않고는 특정 URL에 대한 관련 코드 경로를 사용할 수 없기 때문에 정적 분석을 훨씬 어렵게 만든다는 것입니다.

솔직히 SSG를 사용하고 비 동적 경로가 많은 경우에만 중요합니다. 모든 경로가 SSG 또는 클라이언트 전용이면 유용하지 않습니다. 그리고 대부분의 경로가 동적이면 getStaticPaths 사용하여 명시 적으로 선언해야합니다. 수정없이 원시 react-router를 사용하고 명시 적으로 정적 경로를 정의하도록 요청하는 가상의 Next.js 플러그인에서 경로를 명시 적으로 정의하는 것과 동일한 작업량입니다.

확실히 이점이며 일부 팀은 그것을 원할 것입니다. 그러나 이는 잠재적 인 Next.js 사용자의 하위 그룹에 불과합니다. RR 또는 다른 라우팅 라이브러리가 제공하는 이점 중 일부를 원할 수있는 다른 그룹이 있으며 정적 경로를 명시 적으로 선언해야하는 필요성은 허용 가능한 절충점이거나 문제가되지 않습니다. 예를 들어, 저의 마지막 몇 가지 프로젝트는 100 %가 로그인 페이지 뒤에 있고 정적으로 렌더링 할 필요가없는 B2B / B2C 앱입니다. Next.js는 Next.js를 선호하는 CRA에 비해 몇 가지 장점이 있습니다. 그러나 라우터와 같은 것들은 큰 위험 신호 였고 우리는 CRA를 계속 사용했습니다. 이러한 프로젝트는 raw react-router가있는 Next.js에 매우 적합했을 것입니다.

이것은 또한 next/router 원하지 않는 모든 사람들이 JSX 형태의 react-router를 사용하기를 원한다고 가정합니다. 이것이 next/router 대안의 유일한 유형은 아닙니다.

다른 유형의 라우터는 Gatsby.js 스타일입니다. 프로젝트가 여전히 파일 시스템 기반 페이지 구조를 사용하지만 내부는 react-router와 같은 다른 라우팅 라이브러리로 구현됩니다 (Gatsby는 내부적으로 @reach/router ). 이러한 종류의 라우터 플러그인은 동일한 정적 분석 이점을 제공합니다. 그러나 대체 라우터가 중첩 라우팅과 관련이없는 이점을 제공합니다. 예를 들어 경로 API에 대한 잠재적 인 선호 사항 수용, 접근성 처리 개선, 해당 라우터 주변의 생태계에 대한 통합 개선.

물론 react-router 생태계 내에서도 JSX 양식이 react-router를 사용하는 유일한 방법은 아닙니다. react-router-config도 있습니다. 정적 분석을 수행하기 쉽고 중첩 라우팅도 지원합니다.

react-router 사용자는 그 책임을 최종 사용자에게 전적으로 위임하기 때문에 react-loadable을 직접 사용하는 데 익숙하지만 Next는 쉽지 않은 추상화와 자동화를 시도합니다.

그리고 우리 중 일부는 코드 분할 처리에 문제가 없습니다. 중첩 라우팅은 자동 코드 분할보다 프로젝트에 더 중요 할 수 있습니다. 프로젝트에 가장 적합한 트레이드 오프가 무엇인지에 관한 것입니다.

이것은 부수적이지만 실제로 경로에 대해이를 자동으로 수행하는 babel / webpack 플러그인의 잠재력에 대해 궁금합니다.

또한 react-loadable은 효과적으로 소멸 된 라이브러리입니다 (게시 후 2 년, 버그 보고서를 수락하지 않음). 개인적으로 저는 react-loadable의 내부 포크를 기반으로 Next.js에 자동으로 내장 된 것을 사용하는 것보다 @loadable/components 코드 분할을 수동으로 수행하고 싶습니다.

제안 된 플러그 형 라우터 접근 방식은 동일한 유형의 출력을 얻기 위해 프레임 워크에 광범위한 빌드 시간 정보를 제공하는 라우터 플러그인을 포함해야 할 것입니다. 모든 라우터는 자체 패턴을 기반으로 이러한 정보를 생성하는 방법을 알아야하기 때문입니다.

예. 이것이 일반적으로 플러그인 시스템이 작동하는 방식입니다. 솔직히 이런 종류의 정보가 플러그인에 의해 제공 될 수 있다는 사실은 문제가 아니라 장점입니다. 플러그인에 이것을 포함한다는 것은 Next.js가이 정보를 수집하는 방식이 일부 유형의 프로젝트 요구에 적합하지 않은 경우 해당 프로젝트의 요구에 맞는 것으로 대체 할 수 있음을 의미합니다. 그러나 그렇게하기 위해 모든 Next.js를 포크하고 다시 작성할 필요가 없습니다.

순전히 추측이지만 React가 Suspense를 완료하는 동안 많은 것들이 림보에 있다고 생각합니다. 라이브러리의 첫 번째 클래스 패턴이 모든 라우터 라이브러리에 큰 영향을 미치고 비동기 /로드 가능 빌드를위한 구체적인 기반을 제공하기 때문입니다. 번들 패턴.

이것은 그 자체로 플러그 형 라우터 시스템에서 작업하기위한 꽤 좋은 주장이 될 수 있습니다. 라우팅 및 SSR 물건 모두 Next.js에 하드 코딩되어 있기 때문에 지금은 쉽게 Next.js. 내에서 시스템을 라우팅 미래의 모든 유형에 실험을 할 수 없습니다 Suspense는 Next.js의 라우팅 및 기타 라우팅 라이브러리에 어떤 영향을 미칩니 까? Next.js 청크를 포크하고 다시 작성하지 않고는 (적어도 Next.js의 SSR 및 번들링과 관련하여) 실험 할 수있는 것이 아닙니다.

라우터 플러그인은 이런 종류의 실험을 수행하기에 좋은 장소입니다. 플러그인 API가 충분히 낮은 수준이면 next/router 플러그인 만 포크하고 해당 라우터의 react @ experimental + Suspense 기반 버전을 작성해 볼 수 있습니다. 그리고 이것은 플러그인 (Next.js의 모든 포크가 아님)이기 때문에 실험에 참여하고 새로운 서스펜스 기반 라우터를 테스트하기가 쉽습니다. 이런 종류의 실험이 실제 프로젝트에서 피드백을 수집하기 위해 react @ experimental 이 존재하는 이유 이기 때문에 이것은 나중보다는 지금 중요합니다.

@dantman 나는 당신이 말한 것에 동의하지 않습니다. 그것은 모두 트레이드 오프에 관한 것입니다. 가장 큰 단점은 Next 팀이 시간을 보내는 것입니다. 지금까지 저 구성 고성능 SSR이 주요 초점이었던 것 같습니다. 나는 이것이 모든 사용자에게 반드시 관련이있는 것은 아니지만 Next가 처음에 눈에 띄는 데 사용 된 각도라는 것을 이해합니다 (이것이 우리가 직장에서 그들을 선택하는 이유입니다). 그들은 최근 Gatsby와 Jamstack의 인기로 인해 SSG를 더 많이 파고 있었지만 여전히 SSR imo에 가장 적합합니다.

솔직히 SSG를 사용하고 비 동적 경로가 많은 경우에만 중요합니다.

SSG 대 SSR은 첫 페이지 ( "중요 경로"JS)에 대해 가능한 가장 작은 JS 페이로드를 제공하려고 시도하거나 동적 경로를 수행하는 데 실제로 중요하지 않기 때문에 이것이 의미하는 바를 잘 모르겠습니다. 중요 경로 자산을 최소화하는 것은 일반적으로 SSR 앱에 매우 중요하므로 (따라서 모든 노력) 감사합니다. 그리고 솔직히, 당신이 만드는 모든 것이 로그인 월 CSR 전용 앱이라면, Next _does_는 CRA에 비해 많은 단점이 있습니다 (SSR은 결코 CSR만큼 편리하지 않을 것입니다). 실제로 성능 향상을 위해 런타임 SSR (로그인 / 개인화의 서버 측 처리 포함)을 수행하는 앱을 할인하는 것처럼 들립니다. 모든 것이 SSG와 CSR 이분법에 부합하는 것은 아닙니다.

우리 중 일부는 코드 분할 처리에 문제가 없습니다.

우리 중 일부는 웹팩, react-dom / server 등을 처리 할 수 ​​있습니다. 지금까지 Next의 목표는 CRA처럼 이러한 배출을 더 희귀하고 희귀하게 만드는 것 같습니다. 그리고 당신이 옳습니다. 그 공간에는 많은 솔루션이 있고 Relay와 같은 라이브러리의 새로운 데이터 플러스 코드 패턴으로 인해 더욱 이국적이므로 반응로드 가능이라고 말 했어야했습니다.

궁극적으로 플러그 형 라우터 시스템이 좋을 수 있다는 데 동의하지 않습니다. 저는 Next 팀이 프레임 워크의 핵심 원칙 (예 : 번들 분할 논리)을 제거하고 플러그 형 아키텍처로 추출하는 것이 많은 작업이 될 것이라고 지적했습니다. 그리고 내 추측은 곧 내 핵심 종속성에 대한 향후 변경으로 쉽게 뒤집힐 수있는 내 라이브러리의 기본 변경을 설계하고 싶지 않다는 사실을 강조하고있었습니다. 넥스트 디자인의 일부 측면이 제한적이라는 데 확실히 동의하지만, 대부분의 경우 이러한 제한은 지금까지의 디자인 제약을 고려할 때 의미가 있습니다.

솔직히 SSG를 사용하고 비 동적 경로가 많은 경우에만 중요합니다.

SSG 대 SSR은 첫 페이지 ( "중요 경로"JS)에 대해 가능한 가장 작은 JS 페이로드를 제공하려고 시도하거나 동적 경로를 수행하는 데 실제로 중요하지 않기 때문에 이것이 의미하는 바를 잘 모르겠습니다.

우리는 아마도 어떤 경로가 존재하는지 정적으로 분석하는 능력이 필요한 다른 이유를 생각하고있을 것입니다. 우리 둘 다 "정적 분석"을 "단순히 코드를 읽는 것만으로 빌드시 경로 목록 (예 : ['/about', '/', '/profile'] )을 식별 할 수있는 능력"이라고 가정합니다.

어떤 유형의 JS 번들 최적화에 대해 말하는 것 같습니까? 문서에서 정보를 찾지 못 했으므로 정적 경로 분석을 기반으로하는 최적화 유형을 정확히 알지 못합니다.

이 정적 경로 분석이 주로 SSG에 유용하다고 생각했습니다. 즉, 사이트를 빌드 할 때 pages/about.js 파일이 존재하기 때문에 Next.js는 /about 경로가 존재한다는 것을 알고 명시 적으로 언급 한 적이 없더라도이 경로에 대한 html을 미리 렌더링해야합니다. 사전 렌더링에 대한 /about 경로가 있습니다.

SSR은 요청이 들어올 때만 수행하므로 미리 빌드 된 html이 필요하지 않습니다 (이 시점에서 코드를 실행하고 렌더링 할 경로가 하나 있음). 클라이언트가 렌더링 한 페이지에는 미리 렌더링 된 HTML이 전혀 없습니다. SSG 페이지가 동적이면 어쨌든 모든 경로를 선언해야합니다. 따라서 내 생각.

그리고 솔직히, 당신이 만드는 모든 것이 로그인 월 CSR 전용 앱이라면, Next _does_는 CRA에 비해 많은 단점이 있습니다 (SSR은 결코 CSR만큼 편리하지 않을 것입니다).

CSR 앱과 관련하여 Next.js에서 어떤 단점을 생각하고 있습니까? 앞서 언급 한 라우터 문제 외에.

내 이해에 Next.js는 SSR / SSG / CSR 경로의 전체 영역을 지원합니다. 따라서 로그인 벽으로 된 CSR 전용 앱을 작성하는 데 여전히 적합합니다.

개인적으로 내 관점은 때때로 SSR 및 SSG가 필요한 많은 CSR 앱을 작성하는 누군가로부터 내 모든 프로젝트에 대해 강력한 단일 툴킷을 원하고 그들이 필요한 SSR / SSG / CSR의 조합에 상관없이 원하는 것입니다.

내 경험상 CRA는 CSR 전용 앱 내에서도 Next.js의 CSR 페이지를 유리하게 만들 수있는 많은 단점을 가지고 있습니다. 꺼내지 않고 WebPack 구성 사용자 정의는 큰 문제입니다. i18n을 앱에 추가 할 때 단순히 globalize-compiler WebPack 플러그인을 사용할 수 없었을 때 이로 인해 많은 고통을 겪었습니다. 대부분의 페이지가 CSR 인 경우에도 특정 페이지에 대해 SSR / SSG를 옵트 인하는 기능도 장점입니다 (예 : 페이지의 99.9 %가 CSR이고 로그인 페이지 뒤에 있지만 랜딩 페이지가 있고 약관 / 연락처가있을 수 있음) SSG 또는 SSR을 원하는 페이지). CRA와 같은 것들로는 합리적으로 그런 일을 할 수 없습니다.

우리 중 일부는 코드 분할 처리에 문제가 없습니다.

우리 중 일부는 웹팩, react-dom / server 등을 처리 할 수 ​​있습니다. 지금까지 Next의 목표는 CRA처럼 이러한 배출을 더 희귀하고 희귀하게 만드는 것 같습니다.

솔직히, 경로 기반 코드 분할 (React.lazy 또는 직접 가져 오기 대신 대체 라이브러리를 통해 경로 구성 요소를 사용하도록 수정)을 수동으로 수행하는 것은 사용자 지정 WebPack 구성을 수동으로 관리하거나 작성하는 것과는 거리가 멀습니다. react-dom/server 자신의 SSR 처리기를 사용합니다.

전체 WebPack 구성 또는 사용자 지정 SSR 서버 (예 : Next.js와 같이 널리 사용되는 프레임 워크를 사용하려는 경우)를 수동으로 작성하고 싶지는 않지만, react-router를 사용하고 경로 기반 코드를 수동으로 수행하는 것은 괜찮습니다. 파편. 특히 자동 경로 기반 코드 분할을 선택하면 사용중인 널리 사용되는 라우터 라이브러리를 잃어 버리고 더 광범위하게 사용되는 라우터와는 매우 다른 API에 필요한 여러 기능이없는 라우터를 사용하는 경우에 더욱 그렇습니다.

사용자 지정 서버를 만들 필요가없는 NextJS와 react-router 을 (를) 통합하는 방법을 찾을 때 항상이 문제에 착수했습니다. 그래서 직접 시도해보기로 결정했습니다.

react-router v6 (베타)를 사용하여 사용자 지정 _app :

// _app.js || _app.tsx
import * as React from 'react'
import App from 'next/app'
import NextRouter from 'next/router'

export default class CustomApp extends App {
    render() {
        const { Component, pageProps } = this.props

        if (process.browser) {
            const { Router } = require('react-router-dom')
            const { createMemoryHistory } = require('history')
            const history = createMemoryHistory({
                initialEntries: [this.props.router.asPath],
            })

            history.listen(function ({ action, location }) {
                const url = {
                    hash: location.hash,
                    pathname: location.pathname,
                    search: location.search,
                }
                switch (action) {
                    case 'PUSH':
                        return NextRouter.push(url)
                    case 'REPLACE':
                        return NextRouter.replace(url)
                    default:
                        return void 0
                }
            })

            return (
                <Router location={history.location} navigator={history} action={history.action}>
                    <Component {...pageProps} />
                </Router>
            )
        } else {
            const { StaticRouter } = require('react-router-dom/server')
            return (
                <StaticRouter location={this.props.router.asPath}>
                    <Component {...pageProps} />
                </StaticRouter>
            )
        }
    }
}

왜

NextJS (예 : /foo/[[...bar]].js )에서 _optional catch all route_를 관리하는 것은 쉽지 않기 때문에 이러한 종류의 페이지에 대해 react-router 를 사용할 수있는 방법을 찾고 있습니다. 다른 사람들은 다른 이유를 가지고 있을지 모르지만 그것이 나의 주요 관심사이며 react-router 는 특히 현재 베타 버전 인 v6에서 멋진 API를 제공합니다.

작동 원리

그것은 단지 사용자에게 생성 MemoryRouter 대신 BrowserRouter 우리가 NextJS 라우터 및 NextJS 라우터를함으로써 브라우저 기록까지 엉망가 없습니다. PUSH 및 REPLACE 에 대한 메모리 기록 변경을 수신하므로 react-router 후크 또는 Link 를 사용하여 탐색 할 수 있지만 내부적으로는 NextJS 라우터 메서드 .push 및 .replace 호출.

NextJS 라우터 메서드를 호출해야합니다. 그렇지 않으면 경로 변경이 실제로 NextJS get*Props 메서드를 트리거하지 않습니다. 즉, NextJS Link 사용하는 shallow 옵션과 유사하게 작동합니다. 사용의 단점 react-router 의 Link 전혀 없다는 것이다 prefetch . 그러나 대신 NextJS Link 를 계속 사용할 수 있으며 react-router 는 여전히 경로 변경에 반응 할 수 있습니다.

멋진 점은 이제 NextJS dynamic 및 react-router 경로를 활용하고 다음과 같은 작업을 수행 할 수 있다는 것입니다.

// /foo/[[...bar]].js
import * as React from 'react'
import { Route, Routes } from 'react-router-dom'
import dynamic from 'next/dynamic'

const Home = dynamic(() => import('src/views/Home'))
const About = dynamic(() => import('src/views/About'))
const Navigation = dynamic(() => import('src/views/Navigation'))

export default function Root() {
    return (
        <>
            <Navigation />
            <Routes>
                <Route path="/foo/" element={<Home />} />
                <Route path="/foo/about" element={<About />} />
            </Routes>
        </>
    )
}

어쨌든 이것이 누군가에게 도움이되기를 바랍니다. 나는 이것을 프로덕션에서 사용하지 않았고이 코드는 내가 가지고있는 지역 놀이터에서 온 것이므로 아마도 개선 할 수있는 것이있을 것이지만 시작일 뿐이다.

Next.js 9.5 이상에서 React Router 사용

당신이해야 할 Next.js 9.5 이상 올바른 방법을 사용하는 경우이 함께 다시 쓰기 . _ 사용자 정의 서버를 사용하지 마십시오 _! 이 작업을 수행하는 방법에 대한 자세한 자습서가 있습니다 : https://colinhacks.com/essays/building-a-spa-with-nextjs

기본 아이디어 :

1. 사용자 지정 앱 만들기 ( /pages/_app.tsx )

2. 돌아 null 의 경우 typeof window === "undefined" . 이는 SSR 단계에서 react-router가 오류를 발생시키는 것을 방지하기 위해 필요합니다!

// pages/_app.tsx

import { AppProps } from 'next/app';

function App({ Component, pageProps }: AppProps) {
  return (
    <div suppressHydrationWarning>
      {typeof window === 'undefined' ? null : <Component {...pageProps} />}
    </div>
  );
}

export default App;

suppressHydrationWarning 속성은 서버에서 렌더링 한 콘텐츠가 클라이언트가 렌더링 한 콘텐츠와 일치하지 않을 때 React가 던지는 경고를 방지하는 것입니다.

1. 홈페이지에 모든 경로를 다시 작성

// next.config.js

module.exports = {
  async rewrites() {
    return [
      // Rewrite everything else to use `pages/index`
      {
        source: '/:path*',
        destination: '/',
      },
    ];
  },
};

그러면 평소처럼 React Router를 사용할 수 있습니다! 링크 된 튜토리얼에는 더 많은 컨텍스트 / 설명이 있지만 시작하는 데 도움이됩니다. https://vriad.com/essays/building-a-spa-with-nextjs

@colinhacks 멋진 솔루션이 작동하는지 확인할 수 있습니다. 생각해야 할 점은 앱을 app.js 또는 routes.js와 같은 자체 페이지로 이동하는 것입니다. 그런 다음 다시 쓰기

// next.config.js

module.exports = {
  async rewrites() {
    return [
      {
        source: '/app/:path*',
        destination: '/app',
      },
    ];
  },
};

생각해 볼만한 것이 바로 귀하의 솔루션이 제가 찾은 것 중 최고입니다.