Transcripts
1. Introduction: Hey, welcome to this class
all about the view router and more specifically
the package which is compatible with
view version three, which is the View
Router version four. The view route package
at its core will allow us to switch between
pages in our applications, but there is also a lot
more to it than just that. This is an introduction
class which includes most of the essential topics you
will need to get going. We start at the
beginning by creating a new VGS version
three project with the routes package covering the requirements we
need to get going. Then we cover the contents, including the route of files, what all of these files mean, and where to set up
the routes which allows to switch
between these pages. Continuing on, you
will learn how to set up the links to
switch between pages, and also discover how
we have full control over where the page
content is played. We'll learn how to create
dynamic page URLs so we can include variables such as the current user
into our routes. Working with parameters and query strings are important
too when switching between pages and the
view router package also has us covered, enabling us to pass information
between routes and also covering extracting information
passed into form inputs. Routing is not
always as simple as just a set of links
which map to each page. We may also have the need for nested route two and we
also have this covered. In our examples, we cover CSS styling to apply
to not only our links, but also based on if the
current route is active. We cover fall back
pages and how to enable routing inside of
Javascript. Who am I? My name is Chris,
and I have been involved in web development from a young age and
also been teaching online and in person
for over a decade. I use GS and the route
in my own projects. I have firsthand experience, although ViewGS knowledge
is not strictly required, a little exposure to this will
really help you understand this class as we do not cover the view part
in any great detail. If coming from a different front end framework such as react, you should also be fine
to follow along to. Finally, I thank you for taking the time to
view this class and I hope you
find it useful for learning the view
router package.
2. Setup & Router Package Overview: Welcome to the series
where we're going to take a look at the
view route package. In particular we'll take a
look at how to add the router and make use of it using
view version free. If you've never used
a router before in any other frameworks
or libraries, it's basically a package
which we can use to switch between
pages of views. Why do we need a package to
do this in the first place? Well, generally, when building applications or
websites with UGS, we're building something called a single page application. A single page application
can sound pretty deceptive. It doesn't mean our website
is only one single page. What it means is
behind the scenes, when we first visit
a website or app, one single Javascript file
is generally downloaded. This is one big bundle of Javascript which comes
from the server. Then on the front end,
we need to handle how we need to switch
between various pages or components in this bundle using more traditional based
web technologies such as Php or Ruby on Rails. What we generally do
when clicking on at different pages or
navigation links, this will request a new
page from the server. But with single
page applications, we already have all of the
Java scripts bundled on. The first request, we
need to switch between these various parts when
dealing with a router package, such as the view router. It's not just about switching
between pages, though. There are generally
a lot more features which we can discover too, and we'll see a lot of these
throughout this series. The View Router package
is also officially supported and maintained
by the core View GS team. It's deeply integrated,
supported, and kept up to date. If you want to keep
things really simple, there is also a CDN link which you can use
for the view router. But for this demonstration, I'm going to make
use of a build tool. I'm going to make use
of the Vt package. Vt is effectively
going to allow us to scaffold or create a new
view dress application. And it will give us a lot of nice features such as
hot module replacements, which will automatically
update the browser. Each time we make changes to our project without
any further talking, we'll get on with
creating a new project. For this, I'm going to make
use of visual studio code. Jump into the terminal, which is built in here. We can see on the
VGS documentation. To create a new
view application, we need to use MPM in view. At latest, you must make
sure that you have the latest or a current version
of node JS installed. You can test this by typing
MPM v for version in, it's currently on version eight. Then we can use the
CD command to change into any directory which
you want to move to. In my case, I'm
going to change into the desktop to
install this project. And then we can run
the init command. This is MPM view at latest. The convenient thing
about creating a new view free
project is we can also install the view router
package at this stage. If we need to install any additional packages,
that's fine. The project name just say
view router. A typescript? No, we don't need JSX. We can add the view
router because that's the purpose
of the series. We don't need any state
management or testing. Okay, and let's open
this up inside of visual studio code,
drag this in. You may also need to
reopen the terminal. And from here, just before
we move on any further, we need to run MPM install to install all the
no packages which we need. Okay? The last step
which we need is MPM run dev to run our
development server. So we can see our project
inside the browser. Copy this link or command and control click
to open this up. We've now successfully created
a new view free project. One of the things which you will instantly notice
if you installed the view route at this stage is we have two links
to switch between. We have the home link
and also the about page. We have some routing
functionality out of the box, but we also need to
add our own routes and our own features too. Let's take a look
behind the scenes and see how this happens. If we go into the source folder, in the router folder,
we have this index. You'll see at the very top
of this file we already have the view router
package installed since we added this when
we set up the project. This is importing two
things from this package. The first one is Create router, which you can see just here. This creates a new router object with all of our routes
and configuration. You can see inside,
we can choose between history or we can
also set up hash mode. And we'll take a
look at this later, but probably the time where
you'll spend most of the work with the router is inside
of this route array. If we take a look insider here, each one of our routes
is set up as an object. For the most simple one here, we set up a file path. And this is just
the home directory. This is the one we
see when we simply go to our project URL. This is a name or
an alias which we give to each one of
these routes and we can references later when we set up our links component,
which we want to display. When we're on this page, we've imported something
called the home view. We can see at the
top, this home view is pulled in from
the views folder. Take a look at sidebar, open up the views and we have our
home and our about view. If we open up any of these two route of
views inside of here, we'll look pretty
familiar if you've done any work with VGS in the past and these are set up exactly the same as a
regular view GS component. We have the template which
adds our HML code to the page. We can have an optional
style section, and also we can have
a script section two. These look exactly the same as our components, which
we can see here. The only difference in
terms of structure is we are organizing these
into a views folder. We know which ones we need to switch between
with the router. Just to clarify, a
component can be any single piece or any
single section of our page, but we make sure that our
views folder contains the routes which you want to switch between
with the router. Back to the route index page, we can scroll down and see
our second router object. This has the path
forward slash about. We can also type this in, it's enter, and we then
take into the about page. This also has a router name, but the difference between
our two route here is the first one
directly reference to components and the second one is doing something
called an import. As we can see here, we
have some comments above. This is telling us
that rather than directly importing
our components, including this with the
rest of the package, we are segregating
our about's view. So we can make use of
something called lazy loading. This is one of the
other features of the view router package. It's also capable of
this lazy loading. As mentioned before,
when we first visit a single page application
and type in the URL, this will download the full Javascript bundle
from the server. However, though sometimes we
don't want this big bundle, it could be a really
big application. What we can do
rather than having one single jar script
file is we can split these into separate files. This is what's happened here. We've segregated the about
view into a separate file. This is only downloaded from the server when we click
on the about link. If you want to, we could also change to be a regular
component just like above, let's say About view. We would also need to import
this just like above. We'll import the about view. This is alongside the home view. We just need to change the name. Say this. Vt will automatically
refresh the page. We can still switch
between these two routes. Finally, we need to include this router inside
of our view package. So we export this at the bottom and then
into the main file. This exported
router file is then imported into our
main Javascript file. The rest is regular views. We create a new view
GS application, which is stored inside of app. Then we can add this
router package to our application before it's
then mounted to the dom.
3. RouterLink & RouterView: Previously we set up
a view free project. We installed the
view router package. We briefly looked at
the router options. The router's index page
has its pass inside of our route objects which map
to a particular component. For example, fold about will render this view
called About view. We can see this if we look on our two links here
over on the right, we switch between our two views. But currently,
there still may be a little bit of mystery behind how exactly both of these links are
switching these URL's. This is because these two
links are being added by defaults when we
set up our project. Let's take a look
behind the scenes and see how we can set these up ourselves and also add additional ones to
for this project. Our links have automatically
been set up in the app view, but they can also live
in any other component. Two, we can see at the top, we need to import something
from the view router package. And that's something
which we need is a router link component. This is all the code we've seen. On the left hand side, we have the view logo,
which you see here. We have the Hello World
components with the message. Then we have our two nav links. Down at the bottom here, we'll make use of the
router link components which we imported from
the view router package. You can see this has
an attribute called 22 is the location
which we want to link to when this is clicked on and we have the text of home and about which links
to these two URLs. You may also be wondering
why not just use the regular HML a element to
link between pages inside. Here we can make use
of a forward slash or we could also
say about, well, it's preferred to use
the router link over the traditional A elements when using view GS
for multiple reasons. One of the big
differences is when we're using history mode
like we currently are, the view router package needs to intercept the click from any one of these links and prevent the browser from
refreshing the page, which it does automatically. When using view GS or a
single page application. We don't need this page refresh since we automatically
have all of the jarvscript code available in the bundle which we
can switch between. Let's remove this. Also, just
as a quick side note two, if you use the view router
package based on view two, you may have used the tag prop which looks just like this. We used to use this to set exactly what type of HML element we wanted
this to be rendered as, but this is no longer available
to use in this package. Also, when using route to link, we are not just
limited to passing in a static string to our two
prop just like we are here. We can also pass in any dynamic
data which you want to. For example, we may
have a user and want to link to a
particular user ID. Let's go to our script. We'll set up a
constant called user, which is going to be an object. But before we do this,
we'll wrap this in ref. We need to import ref from the view package if you've
not seen this before. This is a view
free feature which means that all of the contents inside will be kept reactive. And therefore, any component which relies on this data will be updated each time there
is a change from here, we can pass in our data as an object and we'll
say something like name the user ID. Since we are making
use of script set up, our user will be automatically
returned back from our script and made available
to use. No template. We can open this in
the double de braces, there's a data which we need, but we can also make use of
this inside of the two prop. Let's duplicate this, we'll
take a look at an example. We still need double quotes
to surround all of this, but we can make use
of the Javascript bactics to introduce
Javascript variables. We may want to go to something
like forward slash user. Then using the dollar symbol
and the curly braces, we can out our dynamic
data such as our user ID. Let's just say user. But if we were to go up to the
browser and try this out, this would cause an
issue. Let's try this. Click on the user.
Inside of this link key, we see the user ID rather
than the dynamic value. We just like with anything
else in View free, when we're using dynamic data, we also need to use the V bind
syntax, which is a colon. And this tells View GS not
to render this as a string, but instead to take into account the values
of the availables which we pass inside now
if we click on the user. This will now include the
dynamic data which we need. This starts to give
us some idea of the flexibility we have
with the view router. We can also extend even further
by passing in an object. Again, since we're making use of dynamic data or Java Script, we need to include the
colon remove this. We can then our string passing the Javascript
object. It's most simple. This Javascript object
can simply contain the path which we just
looked at, forward slash. The same for the about link, passing an object for the path, but this one was forward about. This should still work
exactly the same as before. We'll see how two links
are working at the top. W would have spell
this correctly. This works fine, but this
is just a simple example, and we don't have any
additional functionality from what we had before. But we can instead pass to
this object a reference to the names which we already gave these routes
in the router file. If you remember from
the previous video inside the routers index page, each one of these routes had a unique name property
we had home and about. We can references
inside of our object, this one passing
the name of home. In fact, this was lower
cases must match. And also for about,
let's try this one out. You may be wondering
why we've gone to all this effort when it works exactly the same
as it did originally. Well, one of the reasons
and one of the benefits of using name is re, usability. If you think about
this, if we had this about us router link
in multiple locations in our project and
then one day we may be decided rather than having the link to be
forward slash about, we may want to change
it to something like forward slash about us. Well, rather than
going into each one of our views or components
and changing this link, all we need to do is to go into our router file and change
the path to about us. This name would be
still relevant and it would still work in
all of our components. That's just changes back. Okay, the next thing to discover is something
called Route of View. We've discovered how
we can switch between our pages using the router
link, which we have here. But we've also imported
something called Route of view. This route of view
is responsible for rendering our
page onto the screen. Inside the app, we have
this head section, which, because of
the default styling, has placed this
over on the left. Then over on the
right, the contents of our two views are displayed. The reason this happens
is because we've placed the route of view at the
bottom of this file. This is the outlet
for our content. For example, if you
wanted to remove this and place this in
a different location, it now moves to the left. This gives us the
full flexibility of where we render the
contents of our pages.
4. Params & Queries: The view routes package
also has much more to offer than just switching
between components. It can also be used to pass data in the form of params and also query strings to
when working with URL's, just like we are here, we
are currently working with the home and the
forward about link. We also may want to add
additional pieces of information such as
Pam, just like a user. And often we may want pieces
of additional information, such as queries, past URL, these have a question
mark like this. And then we'll see
some additional information such as this. Now we want to
take a look at how we can work with both params, inquiries inside of
the view router. Let's go over to our app view where we have our
two router links. First we'll take a look at
params or parameters which are like variables for a given
route in the router link. We can add these inside
of our two prop. Remember earlier we looked at adding variables just
like we had here. And this is the
commented out example. What we want to do is to
remove the name route. In fact, we'll just comment this out and then duplicate this. So we're going to keep
this fully intact. We can set up the path
just like we had earlier. This is going to link to
a particular user ID, which we have stored
in this object. The path, since we're
using variables, we can set these
with the bactics. We'll say forward user, then we may want to
have the user ID like we have here using job script places in with user ID changes
to the user link. Then we can see we've got
this user link now updated. And if we click on this,
we'll see our user. And then the variable
which is just afterwards, this is our ID of 1234, but we don't currently have a corresponding
component to render. What we're going to do is
to change the about view, we'll say user view.
We're changing this. We also need to go
over to our router. And then the index JS, we'll change the about
view, the user view. This is being updated here too. The second component,
the name of user. Now we also need to change
this to be forward slash user. Now if we click on
this, we'll still see, even though we own
forward slash user, that we have an issue
inside the console. We don't have any matches
for forward slash user, then forward our user ID. This is because we
are not taking into account the full
URL With this path, we're going to
have a variable we could if we wanted to add forward 1234, keep
this hard coded. And then we see we are taken to the about page and it
changes to user page, it's consistent, we can still see we are taken
to the correct page. But the problem we may have is if we have a different user ID, if we have somebody else login, this route is not
going to be found. Instead, we need to
be able to capture any different URL which is added and effectively treat
this section as a variable. The way to do this
in the routers index page is rather than having a hard
coded value like this, we can use the colon capture the value inside of a
variable called ID. Now the view router package now understands
that this section, or this segment of the URL
is a variable and could change and it will still
render our user view. Now we can type in
anything we want to, and this is always displayed. The next thing to think
of is how can we get this user information into
our page or components? Well, if we think about this, if this is a user and we want
to grab the unique user ID, we may want to display this or something like the user
name in the components. The way to do this is by using this variable name which
we gave inside the path. Remember we've called this ID. If we go to the user view, we can access the current
route information inside the double calibraces
using $1 symbol route. Say this refresh. We can see all of the current route information
is displayed. We have the full path which is exactly what we see
inside the URL bar. We have the name which we
set up in the router file. We also have the params
where we can see the ID is currently
matching what we have here. This is exactly
how we can access this ID information
inside of our component. We are currently
displaying the route. Since this is an
object, we can say DopamD to capture this
value which is entered. Let's try this route. Peramsd. Now any value which we add in its ID segment is going to be displayed inside
of the template. Also, just as a side note two. As well as using
dollar symbol route, we can also access
dollar symbol router. This gives us a little
bit more information about all of the
router features. We can see things such as the options where we have
the history mode set. We can see the current route. We can see all of our routes
which is set up as an array. Here we have the home and also the second route
which is our user. This is all the same
route information we have set up inside of
our router page. Once again, dollar
symbol router will give you more information about
the full router package. Dollar symbol route
will only display information about the current route which we are visiting. This isn't always the way
we want to go if we want to access variables or
information in our template. We may also want to include
these in our Jar script. To the way we can do this if we're using
the composition API, which we currently
are, Let's say we have a script and we'll make
use of script set up. We can also import these from the router package use route. We can see here by
the information, this is the equivalent of dollar symbol route which we just used. This is all the
information about our current route including
the params if you wanted to. You could also
import use router. This is the equivalent
of dollar symbol router. We want to import these from
the view router package. Then we access these
just like we would do with any other
composables in view. We use route, we call them as a function and store the return value
inside of a variable. Let's say cont route
is equal to this. Then if we duplicate this, we can also access
the router place. In a console log route we rush and we can
see the information is placed inside
of our tag object. We have the name, the params, the queries which we're
going to look at soon, the full path which
we are currently on. Now we are free to
use any pieces of these information
inside of our code. It's also worth noting too, you can have multiple
dynamic segments inside the URL as well as this. You could also say forward and insert a new
variable insider here. Then all you need
to do is to go to the routers index page and set up a new variable to
capture this information. Now this will be available
using this name. As well as this,
the view router can also handle query strings. Two, if you've not used
a query string before, they get a way of passing some additional
information in a URL, just like we looked at early on. You may have seen a URL
which looks just like this. Let's go back to our
first or our home URL. You may see something which looks like this with
a question mark. And then we can say user is equal to any
particular string. Then we can add multiple pieces of information separated by the ampersand say plan
equal to monthly, the name. We can go on and on and
add as many of these as we want to so we
can access our user. We can access our plan
and we can access our name because these are separated after
this question mark. Let's take a look at
how we can use these. These pre strings
can be accessed locally or they can also
be sent to the server. A typical use case for this
would be with HTML form. Let's go over to view. Let's place in a
form remove action. Since we want view
GS to handle this, we'll quickly set up a form
with an input type of text. The name is going to
be equal to user. This name section, when
working with queries, is going to be really important. We'll see this inside
the query string. Let's just set up one more. We'll say the
location, an input, the name of location. Then finally a button to submit. This form of submit any text inside of here
is fine to see this. Go over to the browser, make
sure we are on the user out, fill in the name, the
location, and hit Send. You can see instantly
as soon as you do this, separated by a question mark, We have our two pieces
of information. We have the user equal to Chris and also the
location equal to UK. And both of these are
captured since we've added the name attribute to
each one of our inputs, both the user and also
the location will be sent to the server with
the form when we submit. If you don't know anything about forms or sending
forms to the server, don't worry about
that information. All we need to know here is with this example and
when using forms, these queries or
these query strings added to our URL automatically. But when working with
the view router package, we can also add these
manually two and access them inside of all
pages or components. Let's go over to our app View, which has our router links. For this one we'll place
it inside the home link, inside the object
separated by a comma, we can set up our query
which is equal to an object. Then inside of here, just
like any other object, we'll add our object key
and our object values. For this example, let's
place it in a token, which can be any string of text. You can also insert
variables inside of here if you want to give a save. Now access is token
inside of our components. Since we on the
home link jump into the home view from here
inside the double calibraces, Again, we can access
dollar symbol route for the current route
into the home link. That's all of our information
And you can see inside of here we have this query
which is equal to our token. We can narrow this
downward route query, which gives us our token, and we can also just access
the value with token. If you also take a
look at the URL, you can see how token
has now been applied. This is a convenient
way of passing small pieces of information
between our route. Something such as access, tokens use ID's or any
small piece of information.
5. Nested Routes: As mentioned earlier
on in these lessons, the view router is
really flexible. Currently though,
we are not using the full flexibility it offers. All we have is inside
of this app view, we have our two router links
to switch between our paths. We are out putting these inside of a single route of view. This isn't very flexible. This is just simply
saying that we have our two links and all of the content from any
additional links will always be in
the same location. But let's change things
around a little bit and see how we can deal with
some different situations. Let's reinstate the user
a simple path also. We'll duplicate this and create the user account
area inside the path. This is still going
to be dynamic, so we can say forward account, then we can place
in our user ID. Have this up at the
top, so it's user ID. We also need to set this up
inside of our routers index. For this copy, any one
of these routes pace in the name of account and will also create a new component
called account view. Remember, we changed
the user section so we can remove the
dynamic segments, but we do need to add this
onto our account area. This is forward accounts, we'll select the user ID creates a new view inside
of our views folder. Duplicate any one of these. This one is the account view. Clear all of this up,
some text inside of here. We also do need to import
this inside the rout to file, copy and paste. And this one is
the account view. Should all be working fine. Now we have the home, the
user, and also the account. This is also pointing
to how we use ID and displaying the new component
which we just created. Going back to the
purpose of this video, we're going to take a
look at nested routes. The idea behind nested
routes is using these links. Currently, we're replacing
all of this section on the left because of
our route of view. But what about if
we didn't want to, for example, replace
the full account page? Instead, we maybe want to
place some views below this, such as some previous orders
or even the user's profile. To see this as an example, let's go back into our views and we'll create two new views. Copy and paste this. One is use orders. Just change the
text to be orders. Then copy and paste this one. And this can be update profile, change the text, make sure both of these are
saved into the app view. And we can link both of these down at the bottom
with a router link. The first one is going to be update profile and the second one for our new view
which is previous orders. As mentioned before,
we don't want these two links to
simply override all of the additional content above and display inside of
our routes of view. Instead, since both of these new routes are
linked to our accounts, it may make sense to
have both of these as child routes of this
account look like this. We can copy this full two
section, paste this in. But instead of going to forward slash account, then user ID, we then link to update
for our previous orders. This will look similar, but this one would be
forward slash orders. Save this, and then go to our routers index where you
can import our two new views. Duplicate this twice. This
one is update profile, cover this and add
it to the path. And the second one
is for use orders. This now leaves us in
a position where we have two new routes to handle. We have one path, which will be forward slash accounts,
and then forward slash. We want to grab the user ID, so we want to use
the colon for this. We can stall this
inside a variable, then forward slash update. The second one which you
want to handle is the same, forward slash orders. One option is to create two new route objects here
for both of these URL's. This, however, is not ideal because as we've
already talked about, going to, any one
of these new views will replace the account page. But we want to have
these placed inside. To deal with this inside of
our account route object, we can add a children array. This children array will
declare which components should be nested inside of
this top level account page. This is how it looks just after our components will place
in the children array. Each one of these children is an object which is going to take in the path and
also the component. All we need to do is
to add forward update. But instead of adding
this at the top level, we add this inside
of the child path. When we land on this URL, we're going to display
the component which is update profile
separated by comma. We can also do forward orders which will render
our we use orders. We got two route handled and
we can now remove these. This should be already. Now to test this out, we've got two new links at the bottom. Click on Update profile,
We can see straightway. We'll go to Fold account, then fold the user ID, which is this section just here. Then fold update also. Let's test out the
previous orders. Click on this, again,
the same account, the user ID, and then fold
orders is added to the end. Okay, you may be
thinking, great. We inside the account view, we can see this
text on the left, but we don't see
any reference to our two children components. Well, for this, we
need to tell VGS exactly where we want these
components to display. If we go into the account view, the view router doesn't
have any idea where about we want to display this
inside of the template. We need to tell it by adding
an additional router view. Okay, let's go to our accounts without any of the
additional contents. Below, click on Update Profile. We see this text
of Update profile, which is just here. Finally, click on
Previous Orders. There's our orders text, which we have set up here. Both of these are now displayed inside of the route of
view from our account. The formatting
looks a little bit strange at the minute
because of the CSS. In fact, we can probably see this a little bit better if we go into the source assets. We can remove all the
styling from here. It should now look a
little bit more clear. We've got the account page at the top and then use no
route of view just below. We can then see our
nested child routes.
6. Router Classes: Next we're going to take a
look at active classes and how view JS router applies these
automatically to our links. If you look closely,
we are currently on the home link and this has
the slightly darker color. Click on the user.
This darker color should now be
applied to the user. This happens for each
one of our links. This is useful if we wanted to adjust the styling
for any one of our links and let the user know which route
they're currently on. The way it does
this if we go into the developer tools and
right click and inspect, keeping the elements tab and use the inspector to
click on one of our links. Currently we are
on the home route. If we take a look at the class, we can see this is
router link active. And also a second class of
router link exact active. This is not currently on
any of the following links, but if we click on the user, these classes are now moved
over to the user link. The same for account,
this is our account link. And they are no longer
applied to the first two. But something
different happens if we click on Update Profile. As with the previous links, update profile gets the
two additional classes of router link active and also
router link exact active. However, the difference
is this account section also has this single class
of router link active. The same happens if we
click on previous orders. The previous orders link gets
our two additional classes. And also the account page
has this single class added. First of all, these classes are added automatically
by the view router. And this can allow us to update the styling for
the current page. What's the difference
between router link active and router
link exact active? Well, the difference lies
in this account page. If you've watched
the previous videos, you'll know that the
account page has both the update profile and the previous orders
nested as child routes. The account links us to forward slash account,
then the user ID. If we click on update profile, the same URL is in place, but with update at the
end with previous orders, this is also added to the end. What happens here is
with the previous orders and update profile. This begins with
forward slash accounts. Therefore, the forward
slash account link just here is considered
a partial match. If any of our links
are a partial match, we'll get the class of
router link active. Since this technically
is currently active. But as the name suggests
with the other links, the class of router
link exact active is only applied if there is
an exact match with ORL. This is the current case
for update profile. If we click on Orders, this link here is an
exact match for our URL. This also gets the
exact class and also the same for any other
links, we click on the user. Not only is this
a partial match, but it's also an exact match. We see both classes applied. The reason these
are styled the way they are is because by default, when we set up the view router
inside of the app view, it applies some styling
to the bottom section. If we scroll down, we
have our nav links, the A elements and also a different
color for the class of router link exact, active. This is how we can
add styling to our active links both for a full and also a partial match.
7. Fallback Pages: It's also important
to handle what happens if the user lands on the wrong part of our app or
a page which doesn't exist. For example, if we just added anything onto
the end of this, this account is fine
because we have a section inside of our route to file which handles
any variable piece of information just
after our account. But if we replace the full
section with something random, we don't see any content
rendered in our route of view. For this, we can set
up a general catch all component such as a 44 page, which will display if no
other routes are a match. For this, let's go
over to our components and create a new file
called not Found of view. Then a simple template
insider here is fine, with the heading
of page not found. Okay, to use this
over in our router, we need to import this at
the very top of the file. Import not found. This is in components not found. Then at the end of
our route array, I'm going to create a new
object to handle this. Set this up just like
the object above. We must set up a path
as we always do. But we'll come back to
this in just a moment. We'll add a name not found, then we'll render our component. If you've used the route
of a view two in the past, we used to be able to catch
all other routes which aren't matched above by
simply adding a star. But now using view version three and the view
route of four, we need to instead use
a custom parameter. We do this just like
the dynamic segments we added just above. Instead of the star,
we'll add a forward and then a dynamic segment which will capture in the
variable called path name. This name of path name can be
anything which you choose. The difference between View
router 2.3 is also that we now need to add a regular
expression which is the star. And this will match
any given route name. Now if we're typing
any URL which is not recognized by
any other routes, we'll see our page not found. Let's try one more.
This is fine. Click on our Recognized links and it still renders
the correct component. If we wanted to, we
could also access any one of these params
which is entered, such as this string of text. And we can do this inside
the not found component, just like we've
previously looked out. We can access the
dollar symbol route. We have access to our path name, which is the same name which
we gave inside the router. But what about if we
had multiple segments? If the user entered
something like this? We can see the Pam is still output inside of the template. However, the router
displays this as a string of text rather than two separate parameters if you wanted to break them up into multiple values to
have access to them, such as this section
and also this section, we can instead create an array
of params to set this up. Jump back into our router. We add an additional start
at the end of the path. Now if we save and go back, rather than having a string of parameters like
we had before, we now have an array containing
two separate values. This now gives us
the option to use these parameters individually
if we needed to. Also, the view router
is really flexible. We don't just have to have
one single page not found. We could have 44 pages for
different incorrect segments. For example, if this was admin and the last
segment was incorrect, we maybe want to show
a different 44 page for any admin related errors. The way to do this is to
go back over to our outer, let's duplicate this
last section, Pac above. We could then select
the path forward admin. Then any unrecognized section
which is added afterwards, will be stored in its
parameter called path name. Or you could also rename this to be more descriptive
if you wanted to. But the idea here is simply
the path name will only store this segment rather than the full URL which
we had before. We could then customize our not found page to
suit this exact route. Let's just remove this
example from before go into, we'll add this inside
of the P element and we'll say no
admin page found for then we can output
our dynamic section, we'll say dollar symbol route. Then we can access the
path property which we are currently on its enter, there's our error message
down at the bottom. This is an example
of how we can create one single 44 page
not found component. Or we can also be more
specific and tailor these messages to suit
our particular route.
8. Programmatic Navigation: But now we've been looking
at how we can change between our pages or components
using the router link. The router link will place
a button on our page, which we can click on to
display the desired component. But there's also other
ways we can use to switch between pages
inside of our app. We can also do it
programmatically rather than relying
on these buttons. Earlier we briefly
looked at accessing the routers instance using
dollar symbol router. This can be accessed inside of our script or inside
of our template and it gives us
access to things such as params in our code. This also exposes many
other things too, such as the ability to navigate using
methods such as push. This means we can also build in navigation into things
like our methods in the script or also into any click listeners
inside of our template. For example, let's place in a level one heading anywhere
inside of our wrap, I'll just say site title. What we can do here is
listen off for a click on this element where we can access our dollar symbol router. And a method called push, which is going to push us
to a desired location. If this is a title, it
would make sense to maybe link this back
to our home URL. Let's see how this works
inside the browser. Go to any other page. It's a bit messy now, but
click on the site title. This then takes us
back to the home URL. We'll try one more.
Go to the user, click the site title,
and this all works fine. Also, we can make use
of the push method and all the other methods
which we're going to look at inside of our script. And also the set up function
if we go into our user view inside of here we
can also access router push and make use of
this inside of our script. We'll try this out. Let's say we'll push to any made
upRL such as test. Then what we'll do to
try this out is we'll wrap this inside
of a set time out, passing any function which
will run after 2 seconds. So we can cut this code out, paste this into our time out. Let's go over to the page
and jump into the user view. Then 2 seconds later
our function is run and we're pushed
to forward test. This thing may be
useful for pushing a user to the counter
area after logging in, Since we can also access this
inside of our methods too. Let's now remove this set
time out and also go back to our app dot view
where we can take a look at another
method called replace. This one is doll
symbol replace this. Just like the router push and
all the other methods we'll discover can also be used
inside of the script set up. Let's give this a safe click on the account or any other
page in the site title. Again, just like
the push method, we're also taken back
to the home URL. This works very similar
to the push method, but there is a difference. When navigating
inside the browser, each one of the pages
which we visit is added to the previous
history of entries. This is how we can use these back and forward
buttons inside the browser. But the difference
between these two methods is when using the push method, all of these entries are still added to the history
of the browser. However, as it sounds,
with the replace method, it will replace the current
entry rather than adding two. To say this, let's refresh
to clear the history. Click on the account. Now click on the site title to take
us back to the home page. Now if we click on
the back button, you would expect to be
taken back to the account. We don't, because this
replace has replaced the previous route rather
than added to the history. We can see the difference.
If we go to push again, refresh, we'll go to
the account page, click the site title. But if we click the back button, since all of the history
is saved in the browser, this is then taken back to
the previous account page. Another router method
we have access to is, and this will navigate through the browser entries as
we've just learned there. When we go through various pages inside of our application, all of these pages are stored in order inside the
browser history. We can then navigate
back or forward through as many of these history
entries as we want to. If we wanted to go back to
pages, when we click on this, we can use Router do go passing a value of negative
two. Let's try this out. We'll go back to the home route. We'll go to the user, we'll go to the account,
we'll go to Profile. Now, two steps backwards
would be our user, click on the site
title and we're taking back to the user route. If we were only going back
or forward one single page. It is also two methods we can
use which is back and also forward have access to forward and this doesn't need any arguments passed to this. We also have, as
you would expect, if we clear the history, go to the home account. This takes us back one step to the previous history
item, which is the user. There's also other router
methods available too. If you're interested
in finding out more, you can find out
more information on the view router
documentation page. But for now though,
these are some of the more common methods which you can use
in your project.
9. Thank You: Congratulations,
You've now reached the end of this class. I hope you've enjoyed
this class and also now have a deeper
understanding of the view router package and what it can do for your
view GS projects. We now know that routing is
not always just as simple as picking on a link and
redirecting to a new page. We've covered a lot of
the view router packages, features such as passing
information between routes. We've used query strings,
we've used parameters. We've used dynamic
routes to allow us to use variables inside
of our URL's. We've covered how to set
up nested navigation, how to apply styling to various link states,
and so much more. So a big thank you for me for taking the time
to view this class. I hope you've enjoyed it and I will see you in
another class soon.