설문 조사 : 선택적 매개 변수에 대한 관심을 표현하려면이 주석에 "+1"을 입력하십시오.

참고 : 선택적 매개 변수는이 RFC에서 이미 가능하며 명시적인 구문이 없습니다 ( 주의 사항 섹션 참조).

설문 조사 : 포괄적 인 매개 변수 에 대한 관심을 표현하려면이 주석에 "+1"을 입력하십시오.

참고 :이 스레드에서 포괄적 인 매개 변수 에 대한 사용 사례를 공유하십시오! 우리는 문제 공간을 더 이해하고 싶습니다.

예약 됨 3

ricardo.ch에서는 라우팅을 조금 더 복잡하게 만드는 각 경로에 로케일 접두사를 사용합니다.

유효한 경로의 예 :

• / -자동 감지 된 로케일이있는 홈페이지
• /:locale -강제 로케일이있는 홈페이지
• /:locale/search -검색 페이지
• /:locale/article/:id -기사 페이지

그러한 접두사 매개 변수가 지원 될 수 있다고 생각하십니까?

현재 https://www.npmjs.com/package/next-routes 를 사용합니다.

또 다른 한가지 : 기사 페이지의 경우 ID가 123이되는 /de/article/example-article-123 와 같은 ID 앞에 슬러그를 지원합니다. 이것은 next-routes 사용하는 매우 복잡한 정규식을 통해 수행되며 저는 그렇지 않습니다. 이것이 파일 시스템 API로 어떻게 표현 될 수 있는지보십시오.

@ValentinH 제공된 경로는 제공된 경로가 주어지면 파일 시스템 API를 사용하여 모두 가능합니다.

• / => pages/index.js
• /:locale => pages/$locale/index.js
• /:locale/search => pages/$locale/search.js
• /:locale/article/:id => pages/$locale/article/$id.js

또한 ID가 123이되는 / de / article / example-article-123과 같은 ID 앞에 슬러그를 지원합니다.

이 사용 사례는 위에 설명되어 있습니다.

명명 된 매개 변수는 경로 이름 중간에 나타날 수 없습니다.

이는 blog-$id.js 가 문자 그대로 해석되고 /blog-1 와 일치하지 않음을 의미합니다. 페이지를 /blog/$id.js 재구성하거나 전체 URL 세그먼트를 명명 된 매개 변수로 바꾸고 애플리케이션 코드에서 blog- 제거를 처리 할 수 ​​있습니다.

이 솔루션이 귀하의 요구를 충족하지 않습니까? 귀하의 특정 요구 사항에 대해 자세히 알고 싶습니다.

답변 해 주셔서 감사합니다.

$locale/index.js 폴더와 파일로 모두 사용하는 것에 대해 생각하지 않았습니다. 정말 깔끔합니다!

"중간에 명명 된 매개 변수"에 대해서는 슬러그가 다이나믹하다는 생각이 달라서 간과했습니다. 그러나 당신은 완전히 옳으며 이것은 당신이 언급 한 단락에 의해 다루어집니다. 응용 프로그램 코드에서 슬러그를 스트라이핑하는 것이 갈 길입니다 🙂

이와 같은 것 (.hidden .files / .folders의 구문 분석 매개 변수)이 가능합니까?

pages/
├── .root.js
├── blog/
│ ├── .id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── .customer/
│ │ ├── .post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

또는 $를 그대로두면 파일을 찾을 수 있습니다. D하지만 항상 $ folder를 사용하여 매개 변수를 표시합니까?

pages/
├── $root.js
├── blog/
│ ├── $id/
│ │ ├── index.js
│ │ └── comments.js <-- optional?
├── customers/
│ ├── $customer/
│ │ ├── $post/
│ │ │ └── index.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

npm 패키지로 작동하는 앱의 선택적 매개 변수에 대해이 사용 사례를 사용했습니다. 선택적으로 범위를 가질 수 있습니다. 다음과 같은 경로가 있습니다.

• /packages/express
• /packages/express/dependencies
• /packages/@babel/core
• /packages/@babel/core/dependencies

따라서 기본적으로 범위 매개 변수는 선택 사항이지만 @ 시작하는 경우에만 범위입니다.
따라서 /packages/express/dependencies 및 /packages/@babel/core 의 세그먼트 양은 동일하지만 한 경우에는 /dependencies 의 express 이고 다른 경우에는 /index / @babel/core .

결국 다음 경로를 사용하여 react-router 에서 해결되었습니다.

<Switch>
  <Route path={`/packages/`} exact component={PackagesOverview} />
  <Route path={`/packages/:name(@[^/]+/[^/]+)`} component={PackageView} />
  <Route path={`/packages/:name`} component={PackageView} />
</Switch>

이 RFC에서이 사용 사례에 대한 솔루션이 있는지 잘 모르겠습니다.

포괄 사용 사례의 경우 폴더 구조, 트 리뷰, 트리 맵과 같은 재귀 적으로 중첩 된 데이터에 대한 딥 링크를 생각하고 있습니다.

내 2 센트 : 파일 이름의 달러 기호는 쉘에서 인장으로 사용되기 때문에 나쁜 생각입니다. rm $root.js 를 실행하려는 사람들을 혼란스럽게 할 것입니다. 밑줄은 괜찮은 대안처럼 보입니다.

보다 광범위하게 : 많은 사람들과 마찬가지로 과거에도 파일 시스템을 이에 대한 솔루션으로 활용하려고했습니다. 궁극적으로 파일 시스템은 당신이 찾고있는 완전한 표현력을 제공하지 못할 것이라고 생각합니다. 예를 들어, 선언적 라우터를 사용하면 일반적으로 동적 매개 변수에 대한 유효성 검사 패턴을 지정할 수 있습니다. 이 경우 스키마의 일부는 파일 시스템에 있고 다른 부분은 코드에 있습니다. 관심사 분리는 좋은 일이지만이 경우에는 다른 무엇보다 기술적 한계입니다.

@ValentinH 와 마찬가지로 $ locale 변수를 사용하지만 선택 사항입니다.

/page.ts 및 /page/$locale/page.ts를 사용해야합니까?

"기본"로케일 또는 사전 정의 된 로케일 (사용자 설정)을 사용할 수 있기 때문에이 경우 $ locale 매개 변수를 사용하지 않습니다.

하지만 더 많은 사용 사례가 있습니다 : / car / search / $ optional-filter-1 / $ optional-filter-2 / $ optional-filter-3

optional-filter-1 : color-red, optional-filter-2 : brand-ford 등 ...

선택적 매개 변수의 경우 / $ required-param / 및 / $$ optional-param /?

이것이 로드맵에 올라오고 있다는 것이 대단합니다!

그래도 @timdp 를 지원하는 데 차임해야합니다. touch $file 조차 할 수 없을 때 이것은 많은 혼란으로 이어질 것입니다. 모든 상호 작용에서 탈출을 기억해야합니다. touch \$file; vim $file 는 파일없이 vim을 엽니 다 ($ file은 정의 된 변수가 아니기 때문에).
마찬가지로 쉘에서 탭 완성은 모든 변수를 나열하여 다시 한 번 혼란을 야기합니다.

올바른 연관성을 제공하고 쉘에서 작동해야한다고 생각하는 두 가지 대안을 제안하고 있습니다.

• = =customer page is a customer 로 읽을 수 있습니다. 이름이 지정된 매개 변수의 가장 일반적인 형태와 비슷하게 뻗어있는 콜론이되도록 정신적으로 바꿀 수도 있습니다.
• @ 도 꽤 잘 읽습니다. a customer 에 @customer

또 다른 옵션은 중괄호를 사용하는 것입니다 (일부 파일 시스템에서 예약 된 문자가 아닌 경우). 이 매개 변수 구문은 "선행 기술"이며 다른 많은 라우터에서 사용됩니다.

pages/
├── {root}.js
├── blog/
│ └── {id}.js
├── customers/
│ ├── {customer}/
│ │ ├── {post}.js
│ │ ├── index.js
│ │ └── profile.js
│ ├── index.js
│ └── new.js
├── index.js
└── terms.js

이렇게하면 매개 변수가 시작되는 위치와 끝나는 위치 (예 : /product-{productId}-{productColor} 가 명확 해 지므로 경로 세그먼트의 중간에 매개 변수가 있고 세그먼트 당 여러 매개 변수를 가질 수 있습니다.

Next.js에 동적 경로가 제공된다는 사실에 매우 기쁩니다!

명명 된 매개 변수의 구문과 관련하여 Spectrum에서 논의 된 내용입니다 : https://spectrum.chat/next-js/general/rfc-move-parameterized-routing-to-the-file-system~ce289c5e-ff66 -4a5b-8e49-08548adfa9c7. 여기에서 토론을위한 입력으로 사용할 가치가 있습니다. 개인적으로 저는 Sapper가 [brackets] 사용하는 방식을 좋아합니다. 이것은 또한 Nuxt가 버전 3에서 구현할 것입니다. 다른 프레임 워크가 동적 파일 시스템 기반 경로에 대해 동일한 형식을 사용하는 것은 좋은 것 같습니다.

<Link /> 사용과 관련하여 개발자는 href 및 as 속성을 모두 설정하는 것을 쉽게 잊을 것입니다. 브레이킹 체인지를 도입 할 것이기 때문에 href 속성에 "병합"할 수 없다는 것을 알지만 더 우아한 방식으로 해결할 수있을 것 같습니다.

중괄호는 안타깝게도 Bash에서 명령을 그룹화하는 데 사용됩니다.

<Link /> 사용과 관련하여 @ stephan281094 에 동의합니다. 실수의 원인이됩니다.

동적 라우팅은 매우 유용한 기능이므로 여러분이 살펴보고 솔루션, 거대한 소품을 생각해 낸 것이 정말 대단합니다!

이 주제에 대해서는 와일드 카드 경로도 제안에 추가 할 가치가 있습니다. 앞으로 조사 할 항목으로 포괄 매개 변수를 언급했지만 N 개의 레벨을 가질 수있는 /category/* 와 같은 작업을 수행하고 싶은 경우는 다루지 않습니다. category 페이지를 렌더링합니다.

: 안전하게 사용할 수 있습니까? 그렇다면 모두가 이미 Express의 대회에 대해 잘 알고 있기 때문입니다.

$ 셸 변수와 충돌하기 때문에 개인적으로 강력히 반대합니다.

: 안전하게 사용할 수 있습니까? 그렇다면 모두가 이미 Express의 대회에 대해 잘 알고 있기 때문입니다.

분명히 : 는 Windows에서 금지 된 문자이므로 안전하지 않을 수 있습니다. URL에서 밑줄을 사용할 수 있기 때문에 _ 것도 이상적이지 않습니다. 내가 [brackets] 이 좋은 해결책이라고 생각하는 이유는 그것이 더 미래의 증거이기 때문입니다. Next.js가 향후 post-12345 와 같은 경로를 지원하려는 경우이 구문을 사용하면 브레이킹 체인지없이 수행 할 수 있습니다.

따라서 피해야 할 문자 목록은 다음과 같습니다.

• 파일 시스템과의 충돌 : : , * , " , < , > , |
• 쉘 변수와의 충돌 : $
• bash 중괄호 확장 { , } 와 충돌

다른 건 없나요?

다음과 같은 몇 가지 이유로 중앙 집중식 라우트 파일이 필요하지 않습니다.

• 자동으로 생성 된 사이트 맵이 있으며 파일 시스템만으로는이를 정의하기에 충분하지 않습니다.
• 우리는 명명 된 경로를 사용했으며 대상 "페이지"는 빌드시 알 수있는 것이 아니라 데이터에 의해 결정됩니다. 이름과 매개 변수를 기반으로로드 할 페이지를 파악하는 논리는 경로 구성에 따라 결정됩니다.

또한 다음과 같은 이유로 페이지 폴더를 생성합니다.

• 우리는 Relay를 사용하며 이는 GraphQL과 관련된 모듈이 고유하게 명명되어야 함을 의미합니다. 이런 이유로 우리는 종종 라우트 세그먼트 이름이 모듈 이름과 같을 수 없습니다. index.js 확실히 고유하지 않으며 edit 와 같은 여러 공통 세그먼트가있는 곳을 봅니다.
• 우리는 페이지 모듈 자체의 형제로서 일회성 페이지 특정 구성 요소를 함께 배치하는 것을 선호하며, 이는 Next.js가 페이지 폴더 내에서 허용하지 않습니다.

기본적으로 우리의 패턴은 중앙 집중식 경로 구성을 사용하여 코드베이스의 다른 곳에서 모듈을 가져 오기 / 내보내기 만하는 파일을 포함하는 페이지 폴더를 생성하는 것입니다.

이를 위해 저는이 제안이 기존 페이지 생성 프로세스를위한 향상된 출력 형식으로 간단히 작동 할 수 있는지 여부에 더 중점을두고 있습니다. 그래야 사용자 정의 서버가 필요하지 않은 이점을 얻을 수 있습니다.

다른 곳에서 내 사용 사례 중 일부를 살펴 보았습니다 : https://gist.github.com/AndrewIngram/8d4c4ccd9bd10415a375caacade9f5ca

내가 보지 못하는 주요한 것은 URL 재정의와 같이 파일 시스템에 표현되지 않은 암시 적 매개 변수를 지원하는 것입니다.

다음과 같은 URL이 있다고 가정 해 보겠습니다.

/some-vanity-url/

현재 Next.js 용어에서 여러 쿼리 매개 변수 (예 : Product.js?id=foo&language=en 가있는 제품 페이지에 매핑하려고합니다.

마찬가지로, 우리 웹 사이트에서 대부분의 국가 "사이트"는 최상위 세그먼트 (예 : es 또는 ie )로 범위가 지정되지만 gb 사이트는 해당 세그먼트없이 마운트됩니다. 즉, 모든 gb 페이지에는 암시 적 country 매개 변수가 있지만 다른 모든 국가에서는 명시 적입니다.

다른 단점은 우리의 경우 동일한 '페이지'가 URL 아키텍처의 여러 마운트 지점에 존재할 수 있기 때문에 실제로 우리보다 더 많은 수의 번들 (즉, 여러 개의 중복 진입 점)을 갖게 될 것입니다. 실제로 필요합니다.

전반적으로이 제안은 대부분의 일반적인 사용 사례에서 잘 작동하는 것처럼 보이지만 _all_ 사례에서 경로 구성 또는 사용자 지정 서버의 필요성을 제거하지는 않습니다. 그러나 이것이 내가 현재하는 방식으로 프레임 워크를 사용하는 능력을 대체하지 않는다고 가정하면 이것이 선호되는 happy-path API라는 사실에 대해 어떠한 진짜 반대도하지 않습니다.

{id} 제안을지지합니다. 여러 매개 변수를 허용하고 훨씬 더 좋아 보인다고 생각합니다. 또한 React와 더 잘 맞습니다.

나는 file/&param.js 캐릭터를 선호합니다. URL에서 직접 가져 오며 파일 시스템이나 bash와 충돌하는 것처럼 보이지 않습니다.

나는 _ 하고 다른 것을 정말로 필요로하는 사람들을 위해 next.config.js 에서 재정의를 허용 할 것입니다.

이것에 대한 작업에 감사드립니다. 잠시 동안 그것을 원했습니다! ❤️

놀랄 만한! 🎉🎉🎉

여기서 유일한 문제는 Link href 및 as 매개 변수가 모두 필요하다는 것입니다.

<Link to="blog/123" /> : Nextjs는 페이지 폴더의 파일을 기반으로 한 모든 경로를 이미 알고 있으므로 "/blog/$id" 로 쉽게 변환 할 수 있습니다.

따라서 피해야 할 문자 목록은 다음과 같습니다.

& 는 비동기 서브 쉘에서 인수의 왼쪽을 실행하는 bash의 제어 연산자입니다. 일반 텍스트 : open pages/&customer 는 백그라운드에서 open pages/ 를 실행하고 포 그라운드 셸에서 customer 명령을 실행합니다.

이것은 정말 멋져 보입니다.

이렇게하면 상당한 수의 단일 파일 디렉토리가 생성되는 것 같습니다 (원래 예제의 /blog/$id 처럼). 두 개의 후행 라우트 매개 변수 (예 : /git/compare/$hash1/$hash2 )를 원하는 경우 이것은 훨씬 더 복잡해집니다.

또한 블로그 게시물을 렌더링하는 파일 이름이 $id.js 것을 좋아하지 않습니다. 이름을 blog.js 것이 훨씬 더 설명 적입니다.

@customRoute 데코레이터와 결합 할 수 있습니까?

// pages/blog.js
import {useRouter, @customRoute} from 'next/router'

@customRoute('/blog/:id')
function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

export default BlogPost

이것은 제안 된 포괄 매개 변수에 대한 더 깨끗한 솔루션을 제공하는 것 같습니다.

데코레이터는 함수에 적용 할 수 없으며 (마지막으로 읽은 이후로 변경되었을 수 있습니까?) 제안은 어차피 멀리 떨어져있을 것입니다.

글쎄, 당신이 그 길을 가고 있다고 가정하면 아마 지금 AMP가 구성된 방식으로 할 것입니다.

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

하지만 나중에 유용 할 것 같으면 나중에 추가 할 수 있다고 생각합니다. RFC에 설명 된대로 기본 지원부터 시작하고 싶습니다. 그것으로 실제 사용법을 얻은 다음 중단되는 부분을 수정하십시오. 또한 피해야 할 유일한 문자는 파일 시스템 문자라고 생각합니다. 그것들은이 기능을 구축하기위한 진짜 차단제입니다.

서버리스 솔루션에 친숙한 캐릭터를 사용하세요! (Aws에는 문제를 일으킬 수있는 캐릭터가 있습니다.)

구성 요소 키로 구성 개체를 내보내는 것은 내가 싫어하지 않는 것입니다.

HOC를 사용할 수도 있습니다.

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

페이지에 정적 필드 (예 : getInitialProps)를 추가하면 어떻게됩니까?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

@ dmytro-lymarenko 브라우저에서 /blog 로 이동하면 어떻게됩니까? 404?

이것은 컴파일 타임에 결정되어야하기 때문에 정적으로 분석 할 수있는 무언가가 필요하다고 생각합니다. HOC 또는 정적 속성은 그렇지 않습니다.

정적으로 분석 할 수있는 것이 필요합니다. HOC 또는 정적 속성은

지금까지 제공된 모든 정적 속성 예제는 정적으로 분석 할 수 있습니다 (물론 쉽게 깨뜨릴 수 있음). 함수를 내보내고 정적으로 분석 할 수있는 방식으로 경로 속성을 설정해야한다고 주장 할 수 있습니다. 런타임은 런타임에 설정되었지만 정적 분석기에 의해 포착되지 않은 경로 속성을 확인하고 경고를 발행하거나 오류를 발생시킬 수 있습니다.

브라우저에서 / blog로 이동하면 어떻게 되나요? 404?

@kingdaro -IMO, 예. /blog 및 /blog/:blogId 경로를 모두 사용하려면 디렉터리를 사용합니다. 해당 경로에 과부하가 걸리므로 디렉토리 구조가 정당합니다.

pages/
├── blog/
│ ├── $id.js
│ └── index.js

지금까지 언급 된 모든 캐릭터 옵션에 대한 간략한 검토 :

출현 순서

Char | 단점
--- | ---
$ | 파일 이름의 달러 기호는 쉘에서시길로 사용되기 때문에 나쁜 생각입니다.
_ | 일반적으로 내부 경로를 나타냄
= |
@ | PowerShell의 표시 연산자
{...} | Bash에서 그룹 명령에 사용
[...] | zsh 에서 파일 이름 생성
: | 유효한 파일 이름이 아닙니다.
& | 비동기 서브 쉘에서 인수의 왼쪽을 실행하는 bash의 제어 연산자입니다.

글쎄, 당신이 그 길을 가고 있다고 가정하면 아마 지금 AMP가 구성된 방식으로 할 것입니다.

// /pages/blog.js
export const config = {
  amp: true,
  dynamicRoute: true // adds a [blog] property to the query object
  // dynamicRoute: /\d+/ // could even support regex if you want
};

하지만 나중에 유용 할 것 같으면 나중에 추가 할 수 있다고 생각합니다. RFC에 설명 된대로 기본 지원부터 시작하고 싶습니다. 그것으로 실제 사용법을 얻은 다음 중단되는 부분을 수정하십시오. 또한 피해야 할 유일한 문자는 파일 시스템 문자라고 생각합니다. 그것들은이 기능을 구축하기위한 진짜 차단제입니다.

실제로 동적인지 확인하려면 여러 파일을 거쳐야하기 때문에 config를 사용하는 것은 나쁜 생각이라고 생각합니다. 파일 시스템에 설정하면 한눈에 볼 수 있습니다.

하나 이상의 표준 라우팅 솔루션을 고려해야할지 궁금합니다.

간단한 파일 기반 라우팅은 Next / React를 처음 사용하는 사용자 나 간단한 앱을 빠르게 시작하고 실행하려는 모든 사용자에게 훌륭한 판매 포인트이지만 제한적일 수 있습니다. 그리고이 패턴에 동적 라우팅을 적용하려는 시도는 모든 것을 파일 기반으로 유지한다는 이름으로 단순성을 망치고 불필요한 복잡성을 유발할 수있는 것 같습니다.

이 토론을 읽고 Next.js 사용에 대해 생각한 후, 대체 (보조) 라우팅 시스템에 대한 일급 지원이이 문제를 해결하는 가장 좋은 방법이 될 수 있다고 생각합니다.

나는이 스레드 (예 : 데코레이터 사용 제안)에서 기본적으로 생각하는 것 중 일부를 좋아하지만 그 아이디어에는 분명히 자체 문제가 있습니다. 우리가 멋진 것을 생각 해낼 수 있기를 바랍니다.

구성 요소 키로 구성 개체를 내보내는 것은 내가 싫어하지 않는 것입니다.

HOC를 사용할 수도 있습니다.

function BlogPost(props) {
    return <div />
}

export default withCustomRoute(BlogPost, "/blog/:id")

꽤 멋지지만 경로 정보가 다음과 같은 많은 파일로 분할되어 있는지 궁금합니다.
이것은 관리하기 어려울 수 있습니다.

로컬 구성 (파일 내)과 전역 구성 ( route.js )을 제안하는 나의 원래 생각은 내 첫 번째 주석에서 언급 한 특정 시나리오 (디렉토리에있는 유일한 파일 인 깊이 중첩 된 파일, 의미없는 파일 이름 및 catch-all-params).

이러한 컨텍스트에서 엄격하게 사용되는 경우 URL이 파일 시스템에 직접 매핑되고 "추가"매개 변수 만 로컬 구성에 의해 처리되기 때문에 훨씬 덜 혼란 스럽습니다.

즉, 사용자가 원하는대로 수행하지 못하도록 제한하려고 할 수도 있습니다. 계산 된 라우팅 테이블을 콘솔에 예쁘게 인쇄하거나 미리 결정된 파일에 저장할 수도 있습니다. 문제 해결 경로를 지원하기에 충분합니다.

@merelinguist 요약 표에 작성한 것처럼 Windows에서 = 가 금지되어 있다고 생각하지 않습니다. : 가 금지되는 방법으로 다시 연결되지만 Microsoft Windows 파일 이름 지정 문서에 따르면 동일한 문자가 허용됩니다.

저는 이미 프로덕션에서 사용하는 프로젝트에서 동적 경로를 사용하여 포팅하고 있습니다 (이번 주에 사용할 수 있기를 바랍니다).

하지만 구체적인 질문은 새로운 next @ canary API 기능이 _ 또한 _ 동적 라우팅을 지원합니까?

{ path: '/api/:customer', page: '/api/$customer/index.js' }

[email protected]로 방금 시도했는데 404를 찾을 수 없으므로 아직 거기에없는 것 같습니다. 이 두 기능 (API + 동적 경로)이 URL 라우팅에 패리티를 갖는 것이 합리적입니다.

@remy 아직 구현되지 않았습니다. 곧 내 목록에 있습니다.

또한 Windows 및 Linux 시스템뿐만 아니라 다른 시스템도 고려해야합니다.
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

제안에 대한 추가 정보를 추가하고 싶습니다.

페이지에 정적 필드 (예 : getInitialProps)를 추가하면 어떻게됩니까?

// pages/blog.js
import {useRouter} from 'next/router'

function BlogPost() {
  const router = useRouter()
  // `blogId` will be `'how-to-use-dynamic-routes'` when rendering
  // `/blog/how-to-use-dynamic-routes`
  const blogId = router.query.id
  return <main>This is blog post {blogId}.</main>
}

// By default it would be as it is now
BlogPost.route = '/blog/:id';

export default BlogPost

1. 개발자는 해당 경로 속성에 런타임 변수를 사용할 수 없습니다.

const route = `/blog/${somethingElse}`;
BlogPost.route = route; // is not allowed

1. 이 현재 RFC (폴더에 동적임을 식별하는 문자가 포함되어 있음)를 사용하여 페이지 매니페스트를 빌드 할 때 파일을 읽고이 페이지 매니페스트를 빌드하고 페이지에서 정적 경로 속성을 찾으면 차이점을 알 수 없습니다. Lingui가 작동하는 것과 같은 방식으로 Trans 가 동적이되도록 id를 허용하지 않습니다.

<Trans id="msg.docs" /* id can only be static string */>
   Read the <a href="https://lingui.js.org">documentation</a>
   for more info.
 </Trans>

이미 나열된 접두사 목록으로 이동- @ 기호 접두사를 사용하는 _not_ 강력한 이유가 있는지 궁금합니다.

가치가 있는지 의심 스럽지만 Nuxt와 동등 해집니다. 즉, 누군가가 하나 또는 다른 것에서 전환하면 즉시 작동 방식을 알 수 있습니다.

또는 접두사를 사용자 옵션으로 만드는 것에 대해 생각한 사람이 있습니까? 사람들이 한 프로젝트를 다른 프로젝트에서 이해하기 어렵게 만들지 만, 원한다면 접두사 query__{...} 만들 수 있다는 뜻입니다.

그냥 생각.

@remy 의 제안에 따라 Next가 파일 시스템에서 경로를 구문 분석하는 방법에 대한 API를 완전히 열어 보는 것은

@ scf4 PoC 인 라이브러리가 있는데 now.json 경로 구성을 사용하여 여기 에서도 nextjs로 범용 라우팅을 수행

Zeit 팀도 클라이언트 측 라이브러리에서 경로 파서를 오픈 소스하기를 바랍니다.

Nuxt를 보면 _id.js 도 나쁘지 않다고 생각합니다. 예, 말씀하신대로 이미 _app 및 _document.js 을 (를) 사용하고 있으며 공개적으로 라우팅 할 수 없습니다. 그러나 동적 경로는 많은 페이지에 대한 템플릿이므로 라우팅 할 수없는 것으로 볼 수도 있습니다.

정적 사이트 내보내기의 경우 어떻게 처리됩니까?

(이건 신경 쓰지 마)

또한 Next.js가 생성 된 경로를 단일 파일 (기본적으로 숨겨져있을 수 있음)에 인쇄하는 것이 도움이 될 것이라고 생각합니다. 최소한 프로젝트에서 작업하는 사람들에게 유용한 참고 자료가 될 수 있지만 나중에 강력한 동적 라우팅을위한 문을 열 수도 있습니다.

즉, 런타임시 경로 처리에 해당 파일을 사용하면 사용자가 파일 시스템 기반 API의 이점을 잃지 않고 경로를 추가 / 변경 (예 : 복잡한 패턴 일치)하는 것이 매우 쉽습니다.

이것은 수동으로 변경된 경로를 추적하는 방법과 관련하여 몇 가지 문제를 야기 할 수 있지만 해결된다면 지금까지 최고의 솔루션이 될 것이라고 생각합니다.

@ scf4 Next.js에는 이미 사용자 정의 서버 옵션을 사용하여 복잡한 경로를 수행 할 수있는 기능이 있습니다. 제안하는 것은 이미 사용 가능한 도구를 사용하여 거의 동일한 양의 코드로 달성됩니다.

아 그래, 충분히 공평 해.

편집 할 수있는 단일 경로 파일을 갖는 것이 어쨌든 훨씬 더 나은 옵션이라고 생각합니다!

파일 시스템을 사용한 라우팅에 대한 몇 가지

• [param] 가 가장 안전 해 보입니다 (Sapper에서 사용됨).
• : 은 (는) Express 사용자에게 익숙하지만 _sworn_ Windows FS에 문제가있었습니다.
• $ 및 {param} 는 쉘에서 변수 및 중괄호 확장에 사용되므로 CLI에서 더 문제가 될 수 있습니다.
• _ _ 가능 _하지만 "비공개"표시기로서 너무 일반적입니다.

개인적으로 라우트 ( /^index\. )와 블랙리스트 ( /^_/ )에 대한 화이트리스트 파일에 대해 더 나은 경험을했지만 /pages 의 하위 호환성 문제가 될 것입니다.

API 경로 (# 7297)를 지원하기위한 최근 논의를 통해 /pages 의 새 홈에서 /routes /api 및 /pages 모두를 지원할 수있는 기회가 될 수 있습니다.

그러나 _ 강력한 "그러나"_, Next.js 생태계는 _ 증가적인 _ 기능 추가를 보증 할만큼 충분히 큽니다. "이런, 우리가이 작업을 다시 수행해야한다면 _이 방식"설계를 할 것입니다.

대괄호 ( [example] )는 zsh에서 패턴 일치를 위해 사용하므로 실행 가능하지 않습니다.

파일 이름 생성의 예보기

대괄호 [] 는 패턴 일치를 위해 zsh에서 사용되므로 실행 가능하지 않습니다.

https://github.com/zeit/next.js/pull/7623 에서 방금 만든 것 같습니다.

알려 주셔서 감사합니다. 나도 거기에 댓글을 올렸다.

[id] 시도했지만 경로에서 사용하는 것은 고통 스럽습니다 (예 : cd \[id\]/view.js ). 이중 밑줄 __id (예 : cd __id/view.js )도 잘 작동하며 내부 파일 / 폴더 (예 : _app.js )와 구별 할 수 있습니다 (약간 혼란 스러울 수 있음).

@AaronDDM zsh 있습니까? bash에서 [ 또는 ] 를 이스케이프 할 필요가 없습니다.

예, 이것은 zsh 와 함께 나에게도 발생합니다-이러한 디렉토리와 상호 작용하는 것은 매우 성가신 일입니다.

$ mkdir [asdf]
zsh: no matches found: [asdf]
$ mkdir \[asdf\]
$ cd [asdf]
zsh: no matches found: [asdf]
$ cd \[asdf\]

그리고 zsh 는 macOS Catalina에서 기본 셸이 될 것이기 때문에 결국 이것에 대해 뭔가를해야 할 것입니다 ...

__id.js 동의

흠, 정말 __ 을 (를) 좋아하지 마세요. 나에게 좋지 않은 것 같습니다.

@merelinguist em, Jest는 기본 테스트 폴더에 __tests__ 를 사용합니다. 어떤 경우에는 __ 이 의미가 있다고 생각합니다.

@YUFENGWANG 아마도 가능하면 하나의 캐릭터를 선호합니다. 궁극적으로 최상의 솔루션은 다음과 같습니다.

1. = 와 같은 합리적인 크로스 플랫폼 기본값
2. 사용되는 특수 경로 문자를 사용자 정의하는 next.config.js 옵션
3. 어떤 캐릭터가 어떤 상황에서 문제가 되는가에 대한 문서

단일 캐릭터에 동의했지만 제로 구성을 선호합니다. 그리고 제 생각에는 많은 사람들이 문서에 설명하더라도 모든 문제를 겪을 것입니다.

= 는 zsh에 의해 예약되어 있습니다. 문서에서 :

단어가 인용되지 않은 '='로 시작하고 EQUALS 옵션이 설정된 경우, 나머지 단어는 명령의 이름으로 사용됩니다. 해당 이름의 명령이있는 경우 해당 단어는 명령의 전체 경로 이름으로 대체됩니다.

그냥 아이디어; 접미사를 사용하는 것은 어떻습니까? 예를 들어 [email protected] 등으로 충분할 수 있습니다. 이것은 문자가 유효한 한 쉘 및 파일 시스템에서 이스케이프하고 작업해야하는 문제를 해결할 수 있습니다.

지금까지 이스케이프 할 필요없이 zsh 및 bash에서 작동합니다.

[email protected]
example~.js
example=.js

오. 접미사가 아니라 후행 URL 매개 변수를 나타내는 방법입니다.

따라서 [email protected] 는 blog/:id 됩니다.

compare@[email protected] 는 compare/:a/:b 됩니다.

이것은 위에서 반대했던 깊게 중첩 된 단일 파일 디렉토리를 해결하고 전체 라우팅 정의 파일 시스템을 기반으로 유지할 수 있습니다.

화려하지는 않지만 다음과 같은 라인은 어떻습니까?

/blogs/_var_blog-id/index.js
/blogs/_var_blog-id.js

접두사 _var_ JS 변수 선언을 모방하려는 시도. 아니면 매우 짧고 한 캐릭터 여야합니까?

~ 캐릭터는 어떻습니까?

/blogs/~id 처럼.

~ 를 접두어로 사용하는 것도 POSIX 호환 쉘의 홈 폴더로 확장하는 데 사용되기 때문에 실행 불가능합니다.

[0-9a-zA-Z-._] (정규식)과 일치하지 않는 문자는 운영 체제, 셸 및 파일 시스템에서 접두사로 안전한 것으로 간주 할 수 없습니다.

일부 문자는 안전한 인라인도 아닙니다. 대체에 대한 zsh

또한 화려하게 보이도록 노력하는 것이 아니라 직관적이고 읽기 쉽고 의사 소통하기 쉬워야한다고 생각합니다.

• [params].js 대괄호를 사용하는 것이 더 우아하고 널리 사용되는 것처럼 보입니다. (sapper, nuxt v3?).
• 밑줄 접두사 pages/_helper.js 보통 private 함수에 사용되며 렌더링되지 않아야합니다. 이를 통해 페이지 폴더 내에 도우미 구성 요소를 만들 수 있습니다.

imho : 이것은 더 큰 문제에 대한 일시적인 해결책처럼 느껴집니다. 파일 구조를 기반으로하는 경로를 갖는 것은 시작하기에는 매우 좋지만 수백 개의 경로, 매개 변수 등이있을 때는 확장이 잘되지 않습니다. 경로 구성 파일이있는 경우 (각 디렉토리에 routes.js 파일이있을 수 있음) 더 나은 장기적인 솔루션입니다. 나는 개인적으로 nextjs가 제공하는 기능 (SSR, 속도 등)으로 인해 파일에서 경로를 생성하는 것이 쉽지 않기 때문에 끌립니다.

@mmahalwy 당신은 머리에 못을 쳤습니다.

Next.js는 이미 경로 구성을 생성합니다 (파일 시스템 기반). 이 구성을보다 명시 적으로 만들고 사용자가 원하는 경우 "제거"하도록 허용하는 것이 여기서 가장 원활한 솔루션이라고 생각합니다.

@mmahalwy @ scf4 FWIW, 파일 시스템 경로에 대한 중요한 정당성은 중앙 집중식 파일을 가질 필요를 제거하는 것입니다. 실제로 Next.js의 링크 및 라우팅 용 API 전체가이 제약을 중심으로 설계되었다고 쉽게 주장 할 수 있습니다.

라우트 구성의 문제점은 결국 클라이언트로 전송해야한다는 것입니다. 이는 수백에서 수천에 이르는 라우트 번호가있는 경우 상당히 많은 코드 번들을 의미 할 수 있습니다.

그러나 (지난 몇 달 동안 @timneutkens 와 여러 번이 문제를 없이는 해결할 수없는 일반적인 사용 사례가 많이 있습니다. 나는 그들 중 일부를 이전 의견에 나열했지만 더 있습니다.

가장 간단한 방법은 작성자가 사이트의 페이지에 대한 링크를 만들 수있는 CMS 기반 블로그를 만드는 것입니다. 그들은 기본 페이지 모듈이 무엇인지 알지 못하는 평범한 이전 URL로 링크를 생성합니다. 중앙 집중식 경로 구성을 사용하면 URL을 역방향으로 일치시키고로드 할 페이지를 결정하는 것이 매우 쉽습니다 (내 라이브러리, next-route-resolver 는이 사용 사례를 지원하도록 설계되었으며 다른 모든 사용자가 제안한 것). .

라우트 구성없이 작업중인 사이트를 어떻게 만들 수 있는지 알 수 없기 때문에 파일 크기 허용 범위 내에서 라우트 구성을 유지하는 방법을 찾는 데 집중했습니다. 다른 사람들에게는 파일 시스템 라우팅만으로 충분할 수 있습니다. 모든 것을 해결하는 단일 솔루션이있는 경우 라우팅이 문제가 아니라고 생각합니다.

이전에 언급했듯이이 제안에 관한 한 라우팅 문제를 완전히 해결하는 것으로 판매되는 한 괜찮아 보입니다. 왜냐하면 약간 오해의 소지가 있기 때문입니다. :)

@AndrewIngram 나는 당신이 어디에서

@mmahalwy 나는 당신이 내 요점을 오해했다고 생각합니다. 나는 당신과 동의합니다. 파일 시스템 라우팅이 해결 된 라우팅 문제를 호출하기에 충분하지 않다고 생각하며 그렇게 제시된다면 실망 할 것입니다. 특정 유스 케이스 세트에 대한 개선을 제공한다고 생각하지만, 다른 트레이드 오프 세트 (예 : 귀하와 나)를 기꺼이 선택하려는 사람들을위한 일종의 경로 매니페스트 형식도 있어야한다고 생각합니다. .

중앙 집중식 또는 고급 라우팅 구성을 원하는 사람들을 위해 사용자 지정 서버 및 / 또는 외부 패키지를 사용하여 잘 처리되지 않습니까? 여기에 추가되기를 바라는 것은 무엇입니까?

이 RFC에서 모두 주제에서 벗어난 것 같습니다. 나는 OP를 포함하여 누구도 이것이 라우팅에 대한 모든 솔루션이라고 제안하지 않았다고 생각합니다. 이것은 파일 시스템 기반 라우팅을 향상시킵니다.

나는 지난 몇 주 동안 미니 프로젝트에 동적 경로를 사용했습니다 ( $ 했지만 3 일 전에 카나리아 저장소에서 [param] 로 이동했지만 어쨌든 어쨌든).

방금 getRequestHandler 사용을 시작했고 서버 측에서 동적 라우팅을 선택하지 않는 것 같습니다.

버그인가, 의도적인가 (예 : getRequestHandler ), 아니면 getRequestHandler 를 사용하여 동적 라우팅을 완전히 끄는가 (이제 생각하면 이해가갑니다…) ?

중앙 집중식 또는 고급 라우팅 구성을 원하는 사람들을 위해 사용자 지정 서버 및 / 또는 외부 패키지를 사용하여 잘 처리되지 않습니까? 여기에 추가되기를 바라는 것은 무엇입니까?

여기서 목표 중 하나는 Now (현재 모든 동적 경로가 해당 구성의 일부가되어야 함)와 같은 서비스를 더 쉽게 사용할 수 있도록 사용자 지정 서버를 만들 필요를 피하는 것입니다.

이 RFC에서 모두 주제에서 벗어난 것 같습니다. 나는 OP를 포함하여 누구도 이것이 라우팅에 대한 모든 솔루션이라고 제안하지 않았다고 생각합니다. 이것은 파일 시스템 기반 라우팅을 향상시킵니다.

실제로 여기에 몇 가지 추가 컨텍스트가 있습니다. 이 제안은 오랜 시간이 걸렸고, 내가 본 많은 토론 (내가 직접 참여한 토론 포함)을 기반으로이 경로를 사용할 필요성을 제거하는 것으로 어느 정도 과장되었습니다. 다음 경로 및 내 자신과 같은 관리 라이브러리. 이 RFC로 충족 되지 않는 사용 사례를 강조하는 것은 주제에서 벗어난 것이라고 생각하지 않습니다. 그들 중 일부는 제안에 대한 일부 변경으로 실현 될 수 있지만 다른 일부는 그렇지 않을 수 있습니다. 그러나 어느 쪽이든, 제안되는 것의 한계에 대한 인식을 높이는 것이 확실히 가치가 있습니까?

FWIW는 Pinterest에서 [param] 스타일 FS 기반 경로를 사용합니다 (Next는 아님). 지금까지 정말 잘 확장되었습니다. 가장 큰 비판은 Jest가 [] 을 regexp 쌍으로 해석하므로 param-ful 핸들러에 대한 테스트를 대상으로 지정하기가 어려울 수 있다는 것입니다.

@chrislloyd 다른 환경에서 경로 / 파일에 대해이 형식을 사용하여 파일을 만들고 관리하는 경험은 무엇입니까? 누군가 zsh를 사용하거나이를 다르게 해석하는 도구를 사용하고 있습니까?

[] 가 zsh에서 패턴 일치를 위해 사용하는 것으로 보이며 (Jest에서 말했듯이) 이러한 경로를 이스케이프해야합니다. 이것을 알고 있다면 이것은 큰 문제가 아니지만 초보자가 사용할 수 있고 이해할 수 있어야한다는 점을 감안할 때 이것이 올바른 형식인지 의심 스럽습니다.

내가 사용하는 방법에 대한 아이디어가 ! 와 같이 필요한 매개 변수를 /pages/id!.js 및 ? 처럼 선택적 매개 변수에 대한, /pages/posts/id?.js .

위의 설명과 같이 접두어에 문제가 없으며 ! 가 필수 매개 변수를 나타내는 방법과 ? 가 선택적 매개 변수를 나타내는 방법에 익숙합니다.

Windows는 파일 이름에 물음표를 허용하지 않으며? 그리고! Bash에서 특별한 의미가 있습니다.

API 경로는 이제 동적 매개 변수를 지원합니다. # 7629 🚀

@remy getRequestHandler 은 (는) 동적 라우팅을 처리 할 것으로 예상됩니다. 방금 확인했습니다. 조사 할 수 있도록 재현 단계와 함께 별도의 버그 / 문제를 제출해 주시겠습니까? :빌다:

안녕하세요 여러분! 이 RFC에 대한 놀라운 응답에 감사드립니다.

이 RFC는 Next.js 9에서 안정적으로 구현 및 릴리스되었습니다.
블로그 게시물에서 자세한 내용을 읽을 수 있습니다.

여기에 제공된 모든 고급 피드백을 해결하기 위해 향후 새로운 RFC를 게시 할 예정입니다. 업데이트가 가능하면 여기에 게시하겠습니다.