hitchhiker部署_《 Hitchhiker的React Router v4指南》：路由配置的隱藏值

hitchhiker部署

Welcome to the Hitchhiker’s Guide to React Router v4, Part IV!

歡迎來到《 React Router v4旅行者指南》，第四部分！

Now that we’ve learned about recursive routes, let’s get back to our initial boilerplate, to avoid mixing concerns, and learn how to create a route configuration array.

既然我們已經了解了遞歸路由，那么讓我們回到最初的樣板中，避免混淆的問題，并學習如何創建路由配置數組。

So, just to recap a bit what we did in the beginning, let’s take a look at our initial routes.js file:

因此，讓我們回顧一下開始時所做的事情，讓我們看一下我們最初的routes.js文件：

Our Routes component is returning a div with a NavBar and a Switch where we’ve defined all the routes of our App.

我們的Routes組件將返回一個帶有NavBar和Switch的div ，在其中定義了應用程序的所有路由。

Our first step in this Part 4 will be to define a routes array.

在第4部分中，我們的第一步將是定義一個路由數組。

路線數組 (Routes Array)

I’ve taken a look at our routes and created this array that defines each route and sub-route we had in our application.

我看了看我們的路線，并創建了這個數組，該數組定義了我們在應用程序中擁有的每個路線和子路線。

Nice! Now what?!? ?

真好！怎么辦？！？？

重構舊的硬編碼路由 (Refactor the Old Hardcoded Routes)

Now let’s clean our hardcoded routes and the Switch!

現在，讓我們清理我們的硬編碼路由和Switch！

Yeah! Goodbye all those lines of code. What are we really doing?

是的再見所有這些代碼行。我們到底在做什么？

Well, we’re mapping over the map array using an ES6 (fat arrow) callback to return an abstract component called <MakeRouteWithSubRoutes />. We are passing into it a key (just for React indexing purposes) and we are spreading the route info also into it.

好吧，我們正在使用ES6(胖箭頭)回調在map數組上進行映射，以返回名為<MakeRouteWithSubRoutes />的抽象組件。我們在其中傳遞了一個密鑰(僅用于React索引目的)，并且還在其中傳播了路線信息。

<MakeRouteWitheSubRoutes />組件 (<MakeRouteWitheSubRoutes /> Component)

In the meantime, we need to create that component. I’ve decided to create it apart and import it into the routes.js file.

同時，我們需要創建該組件。我決定分開創建它，并將其導入routes.js文件。

Okay, this <MakeRouteWithSubRoutes/> Component is picking up each route you pass into it and returning a React Router <Route/> Component.

好的，這個<MakeRouteWithSubRoutes />組件將拾取傳遞給它的每條路由，并返回一個React Router <Route />組件。

As props, we have the path and the render method, which will invoke the route.component you want to render (then passing into it the spread props and the sub-routes that it needs to know).

作為道具，我們具有路徑和render方法，它們將調用您要渲染的route.component (然后將傳播的道具和它需要知道的子路線傳遞到其中)。

This routes are coming from the route config array — got it? Nice! ?

該路由來自路由配置數組-知道嗎？真好！？

TopicList(子路由) (TopicList (Sub-Routing))

This being said, let’s take a loot at the TopicList component because it’s the one receiving sub-routes from the route config array:

話雖這么說，讓我們來看看TopicList組件，因為它是從路由配置數組中接收子路由的一個：

So, what’s happening here? Our TopicList now is importing the <MakeRouteWithSubRoutes/> component and reusing with routes it has received.

那么，這是怎么回事？我們的題目列表現在導入<MakeRouteWithSubRoutes />成分和與它已經接收的路由重新使用。

It also does a routes.map over the sub-routes and repeats the process done in the routes.js file.

它還在子路由上執行一個route.map ，并重復在route.js文件中完成的過程。

Take a minute to understand it and play with it!

花一點時間來理解它并玩它！

越來越多的子路由 (More and More Sub-Routing)

As you can see, this works quite well. It’s abstracted, there’s separation of concerns. The <MakeRoutesWithSubRoutes/> is a quite easy to use stateless component or function which doesn’t care about the routing content. It just routes whatever you feed to it.

如您所見，這很好。它是抽象的，關注點分離。 <MakeRoutesWithSubRoutes />是一個非常容易使用的無狀態組件或函數，不需要關心路由內容。它只是路由您提供的任何內容。

What if we wanted to do more sub-routing?

如果我們想做更多的子路由怎么辦？

Easy peasy! Just keep growing or redesigning your routes configuration array!

十分簡單！只要保持增長或重新設計您的路線配置陣列即可！

See? The routes of the /Topics/:topicId could simply be an array like its parent routes. But I’ve decided to do better and invoke a function that calls an API and returns a new array of routes (just imagine it fetches the API ?).

看到？ / Topics /：topicId的路由可以像其父路由一樣簡單地是一個數組。但是我決定做得更好，并調用一個函數，該函數調用API并返回新的路由數組(想像一下它獲取了API？)。

So how can we check that in the App?

那么我們如何在App中檢查呢？

Let’s put a console.log inside the TopicDetail component and check what it is receiving:

讓我們將console.log放入TopicDetail組件中，并檢查其接收的內容：

I’m invoking routes() in console.log because now this sub-route is a function! Remember? All good! ?

我正在console.log中調用route() ，因為現在此子路由是一個函數！記得？都好！？

Yeah Ma! We’ve done it! We’re receiving the routes dynamically and propagating those into our sub-routes and components. This is so great!

是的，馬！我們做到了！我們正在動態接收路線，并將其傳播到我們的子路線和組件中。太好了！

NoMatch和歧義路線 (NoMatch And Ambiguous Routes)

Wait! Where’s our NoMatch Component?

等待！我們的NoMatch組件在哪里？

Okay, let’s introduce it into our route config array:

好的，讓我們將其介紹給我們的路由配置數組：

Observe that :WhereTheHeckIsThat is a variable because it has the colon before it.

觀察到：WhereTheHeckIs那是一個變量，因為它前面有冒號。

What should we expect?

我們應該期待什么？

Let’s see it in action:

讓我們來看看它的作用：

Wow! As a matter of fact it’s rendering the NoMatch but it’s also rendering the Home View. Why?

哇！事實上，它正在渲染NoMatch，但同時也在渲染Home View 。為什么？

Well, what’s happening is that in our initial boilerplate we had a <Switch /> that was picking up the first <Route /> that matches the path remember?

好吧，發生的事情是，在我們的初始樣板中，我們有一個<Switch /> ，它正在拾取與所記住的路徑相匹配的第一個<Route /> ？

So now, as we do not have the switch, it can match more than one path at a time!

所以現在，由于我們沒有開關，因此它一次可以匹配多個路徑！

These are called Ambiguous Routes. Router matched the /Home and at the same time /:WhereTheHeckIsThat because it’s kind of a wildcard that accepts everything.

這些稱為歧義路線。 Router匹配了/ Home并同時匹配了/ ：WhereTheHeckIsThat，因為它有點像通配符，可以接受所有內容。

How to we correct that?

我們該如何糾正？

Simple: grab <Switch /> back!

簡單：搶回<Switch /> ！

As you can see above, now the /Home is rendered alone, because <Switch /> found it and returned it immediately.

正如您在上面看到的，現在/ Home是單獨呈現的，因為<Switch />找到了它并立即返回了它。

If you put some unknown path in the URL, it triggers the :/WhereTheHeckIsThat and renders the NoMatch component as a default.

如果在URL中放置一些未知路徑，它將觸發：/ WhereTheHeckIsThat并將NoMatch組件呈現為默認值。

Great job! Everything is working as we’d expected and now we have a powerful route array configuration which allows us to have a lot of flexibility.

很好！一切都按預期工作，現在我們擁有功能強大的路由陣列配置 ，使我們擁有很大的靈活性。

This really is the hidden value of having an abstraction and defining a route configuration array!

這確實是具有抽象并定義路由配置數組的隱藏價值！

最后但并非最不重要的 (Last but not least)

This is the end of the Hitchhiker’s Guide To React Router v4.0!

Hitchhiker的React Router v4.0指南到此結束！

There is still are some stuff to pay attention to, but I prefer to let you deep dive a little bit in the boilerplates we’ve built and look for what you need in the React router website.

仍然有一些東西要注意，但是我更喜歡讓您深入研究我們制作的樣板并在React Router 網站上尋找您需要的東西。

I had so much fun doing this Guide that I think I’m going to start writing more and more :)

我在執行本指南時非常開心，以至于我將開始越來越多地撰寫:)

It was good not only because I was able to teach you something but also because I’ve also learned a lot in this process.

這很好，不僅因為我能夠教你一些東西，而且因為我在此過程中也學到了很多東西。

GitHub回購 (GitHub Repo)

The changes I’ve made to the application, to produce this article, can be found in my GitHub repo for Part 4.

在本文的第4部分的GitHub存儲庫中，可以找到我對應用程序所做的更改(以生成本文)。

參考書目 (Bibliography)

To make this article I’ve used the React Router documentation that you can find here.

為了撰寫本文，我使用了React Router文檔，您可以在這里找到。

All the other sites I’ve used are linked along the document to add info or provide context to what I’ve tried to explain to you.

我使用過的所有其他網站都與文檔鏈接在一起，以添加信息或提供與我嘗試向您解釋的內容的上下文。

This article is part 4 of a series called “Hitchhiker’s Guide to React Router v4”

本文是稱為“ Hitchhiker的React Router v4指南”系列的第4部分。

Part I: Grok React Router in 20minutes
第一部分：20分鐘內的Grok React Router
Part II: [match, location, history] — your best friends!
第二部分：[比賽，位置，歷史]-您最好的朋友！
Part III: recursive paths, to the infinity and beyond!
第三部分：無窮遠的遞歸路徑！

? Thank you very much!

？非常感謝你！