auto_route_library
flutter route generator.
introduction
what is autoroute?
it’s a flutter navigation package, it allows for strongly-typed arguments passing, effortless deep-linking and it uses code generation to simplify routes setup, with that being said it requires a minimal amount of code to generate everything needed for navigation inside of your app.
why autoroute?
if your app requires deep-linking or guarded routes or just a clean routing setup you’ll need to use named/generated routes and you’ll end up writing a lot of boilerplate code for mediator argument classes, checking for required arguments, extracting arguments and a bunch of other stuff. autoroute does all that for you and much more.
installation
dependencies:
auto_route: [latest-version]
dev_dependencies:
auto_route_generator: [latest-version]
build_runner:
setup and usage
create a placeholder class and annotate it with @materialautorouter which takes a list of routes as a required argument.
note: the name of the router must be prefixed with $ so we have a generated class with the same name minus the $.
// @cupertinoautorouter
// @adaptiveautorouter
// @customautorouter
@materialautorouter(
replaceinroutename: 'page,route',
routes: <autoroute>[
autoroute(page: booklistpage, initial: true),
autoroute(page: bookdetailspage),
],
)
class $approuter {}
tip: you can shorten auto-generated route names from e.g. booklistpageroute to booklistroute using the replaceinroutename argument.
now simply run the generator
use the [watch] flag to watch the files’ system for edits and rebuild as necessary.
flutter packages pub run build_runner watch
if you want the generator to run one time and exits use
flutter packages pub run build_runner build
finalize the setup
after you run the generator your router class will be generated, hook it up with materialapp.
class app extends statlesswidget{
// make sure you don't initiate your router
// inside of the build function.
final _approuter = approuter();
widget build(buildcontext context){
return materialapp.router(
routerdelegate: autorouterdelegeate(_approuter),
// or
// routerdelegate: _approuter.delegate(),
routeinformationparser: _approuter.defaultrouteparser(),
),
}
generated routes
a pagerouteinfo object will be generated for every declared autoroute, these objects hold path information plus strongly-typed page arguments which are extracted from the page’s default constructor. think of them as string path segments on steroid.
class booklistroute extends pagerouteinfo {
const booklistroute() : super(name, path: '/books');
static const string name = 'booklistroute';
}
if the declared route has children autoroute will add a children parameter to its constructor to be used in nested navigation. more on that here.
class userroute extends pagerouteinfo {
userroute({list<pagerouteinfo> children}) :
super(
name,
path: '/user/:id',
initialchildren: children);
static const string name = 'userroute';
}
navigating between screens
autorouter offers the same known push, pop and friends methods to manipulate the pages stack using both the generated pagerouteinfo objects and paths.
// get the scoped router by calling
autorouter.of(context)
// or using the extension
context.router
// adds a new entry to the pages stack
router.push(const bookslistroute())
// or by using using paths
router.pushnamed('/books')
// removes last entry in stack and pushs provided route
// if last entry == provided route page will just be updated
router.replace(const bookslistroute())
// or by using using paths
router.replacenamed('/books')
// pops until provided route, if it already exists in stack
// else adds it to the stack (good for web apps).
router.navigate(const bookslistroute())
// or by using using paths
router.navigatenamed('/books')
// adds a list of routes to the pages stack at once
router.pushall([
bookslistroute(),
bookdetailsroute(id:1),
]);
// this's like providing a completely new stack as it rebuilds the stack
// with the list of passed routes
// entires might just update if alright exist
router.replaceall([
loginroute()
]);
// pops the last page unless stack has 1 entry
context.router.pop();
// keeps poping routes until predicate is satisfied
context.router.popuntil((route) => route.name == 'homeroute');
// a simplifed version of the above line
context.router.popuntilroutewithname('homeroute');
// pops all routes down to the root
context.router.popuntilroot();
// removes the top most page in stack even if it's the last
// remove != pop, it doesn't respect willpopscopes it just
// removes the entry.
context.router.removelast();
// removes any route in stack that satisfis the predicate
// this works exactly like removing items from a regualar list
// <pagerouteinfo>[...].removewhere((r)=>)
context.router.removewhere((route) => );
// you can also use the common helper methods from context extension to navigate
context.pushroute(const bookslistroute());
context.replaceroute(const bookslistroute());
context.navigateto(const bookslistroute());
context.navigatenamedto('/books');
context.poproute();
passing arguments
that’s the fun part! autoroute automatically detects and handles your page arguments for you, the generated route object will deliver all the arguments your page needs including path/query params.
e.g. the following page widget will take an argument of type book.
class bookdetailspage extends statelesswidget {
const bookdetailsroute({required this.book});
final book book;
...
note: default values are respected. required fields are also respected and handled properly.
the generated bookdetailsroute will deliver the same arguments to it’s corresponding page.
router.push(bookdetailsroute(book: book));
note: all args are generated as named parameters regardless of their original type.
returning results
you can return results by either using the pop completer or by passing a callback function as an argument the same way you’d pass an object.
1 – using the pop completer
var result = await router.push(loginroute());
then inside of your loginpage pop with results
router.pop(true);
as you’d notice we didn’t specify the result type, we’re playing with dynamic values here, which can be risky and i personally don’t recommend it.
to avoid working with dynamic values we specify what type of results we expect our page to return, which is a bool value.
autoroute<bool>(page: loginpage),
we push and specify the type of results we’re expecting
var result = await router.push<bool>(loginroute());
and of course we pop with the same type
router.pop<bool>(true);
2- passing a callback function as an argument.
we only have to add a callback function as a parameter to our page constructor like follows:
class bookdetailspage extends statelesswidget {
const bookdetailsroute({this.book, required this.onratebook});
final book book;
final void function(int) onratebook;
...
the generated bookdetailsroute will deliver the same arguments to it’s corresponding page.
context.router.push(
bookdetailsroute(
book: book,
onratebook: (rating) {
// handle result
}),
);
if you’re finishing with the results make sure you call the callback function as you pop the page
onratebook(result);
context.router.pop();
note: default values are respected. required fields are also respected and handled properly.
working with paths
working with paths in autoroute is optional because pagerouteinfo objects are matched by name unless pushed as a string using the initialdeeplink property in root delegate or pushnamed, replacenamed navigatenamed methods.
if you don’t specify a path it’s going to be generated from the page name e.g. booklistpage will have ‘book-list-page’ as a path, if initial arg is set to true the path will be / unless it’s relative then it will be an empty string ''.
when developing a web application or a native app that requires deep-linking you’d probably need to define paths with clear memorable names, and that’s done using the path argument in autoroute.
autoroute(path: '/books', page: booklistpage),
path parameters (dynamic segments)
you can define a dynamic segment by prefixing it with a colon
autoroute(path: '/books/:id', page: bookdetailspage),
the simplest way to extract path parameters from path and gain access to them is by annotating constructor param with @pathparam('optional-alias') with the same alias/name of the segment.
class bookdetailspage extends statelesswidget {
const bookdetailspage({@pathparam('id') this.bookid});
final int bookid;
...
now writing /books/1 in the browser will navigate you to bookdetailspage and automatically extract the bookid argument from path and inject it to your widget.
query parameters
query parameters are accessed the same way, simply annotate the constructor parameter to hold the value of the query param with @queryparam('optional-alias') and let autoroute do the rest.
you could also access path/query parameters using the scoped routedata object.
routedata.of(context).pathparams;
// or using the extension
context.route.queryparams
tip: if your parameter name is the same as the path/query parameter, you could use the const @pathparam or @queryparam and not pass a slug/alias.
class bookdetailspage extends statelesswidget {
const bookdetailspage({@pathparam this.id});
final int id;
...
redirecting paths
paths can be redirected using redirectroute. the following setup will navigate us to /books when / is matched.
<autoroute> [
redirectroute(path: '/', redirectto: '/books'),
autoroute(path: '/books', page: booklistpage),
]
when redirecting initial routes the above setup can be simplified by setting the /books path as initial and auto_route will automatically generate the required redirect code for you.
<autoroute> [
autoroute(path: '/books', page: booklistpage, initial: true),
]
note: redirectroutes are fully matched.
wildcards
auto_route supports wildcard matching to handle invalid or undefined paths.
autoroute(path: '*', page: unknownroutepage)
// it could be used with defined prefixes
autoroute(path: '/profile/*', page: profilepage)
// or it could be used with redirectroute
redirectroute(path: '*', redirectto: '/')
note: be sure to always add your wildcards at the end of your route list because routes are matched in order.
nested routes
nesting routes with autoroute is as easy as populating the children field of the parent route. in the following example both userprofilepage and userpostspage are nested children of userpage.
@materialautorouter(
replaceinroutename: 'page,route',
routes: <autoroute>[
autoroute(
path: '/user/:id',
page: userpage,
children: [
autoroute(path: 'profile', page: userprofilepage),
autoroute(path: 'posts', page: userpostspage),
],
),
],
)
class $approuter {}
the parent page userpage will be rendered inside of root router widget provided by materialapp.router but not its children, that’s why we need to place an autorouter widget inside of userpage where we need the nested routes to be rendered.
class userpage extends statelesswidget {
const userpage({key key, @pathparam this.id}) : super(key: key);
final int id;
@override
widget build(buildcontext context) {
return scaffold(
appbar: appbar(title: text('user $id')),
body: autorouter() // nested routes will be rendered here
);
}
}
now if we navigate to /user/1 we will be presented with a page that has an appbar title that says user 1 and an empty body, why? because we haven’t pushed any routes to our nested autorouter, but if we navigate to user/1/profile the userprofilepage will be pushed to the nested router and that’s what we will see.
what if want to show one of the child pages at /users/1? we can simply do that by giving the child page an empty path ''.
autoroute(
path: '/user/:id',
page: userpage,
children: [
autoroute(path: '', page: userprofilepage),
autoroute(path: 'posts', page: userpostspage),
],
),
or by using redirectroute
autoroute(
path: '/user/:id',
page: userpage,
children: [
redirectroute(path: '', redirectto: 'profile'),
autoroute(path: 'profile', page: userprofilepage),
autoroute(path: 'posts', page: userpostspage),
],
),
in both cases whenever we navigate to /user/1 we will be presented with the userprofilepage.
finding the right router
every nested autorouter has its own routing controller to manage the stack inside of it and the easiest way to obtain a scoped controller is by using context.
in the previous example userpage is a root level stack entry so calling autorouter.of(context) anywhere inside of it will get us the root routing controller.
autorouter widgets that are used to render nested routes insert a new router scope into the widgets tree, so when a nested route calls for the scoped controller they will get the closest parent controller in the widgets tree not the root controller.
class userpage extends statelesswidget {
const userpage({key key, @pathparam this.id}) : super(key: key);
final int id;
@override
widget build(buildcontext context) {
// this will get us the root routing controller
autorouter.of(context);
return scaffold(
appbar: appbar(title: text('user $id')),
// this inserts a new router scope into the widgets tree
body: autorouter()
);
}
}
here’s a simple diagram to help visualize this
as you can tell from the above diagram it’s possible to access parent routing controllers by calling router.parent<t>(), we’re using a generic function because we too different routing controllers stackrouter and tabsrouter, one of them could be the parent controller of the current router and that’s why we need to specify a type.
router.parent<stackrouter>() // this returns a the parent router as a stack routing controller
router.parent<tabsrouter>() // this returns a the parent router as a tabs routing controller
on the other hand obtaining the root controller does not require type casting because it’s always a stackrouter.
router.root // this returns the root router as a stack routing controller
you could also obtain inner-routers from outside their scope as long as you have access to the parent router.
// assuming this's the root router
autorouter.of(context).innerrouterof<stackrouter>(userroute.name)
// or use the short version
autorouter.innerrouterof(context, userroute.name);
accessing the userpage inner router from the previous example.
class userpage extends statelesswidget {
final int id;
const userpage({key key, @pathparam this.id}) : super(key: key);
@override
widget build(buildcontext context) {
return scaffold(
appbar: appbar(
title: text('user $id'),
actions: [
iconbutton(
icon: icon(icons.account_box),
onpressed: () {
// accessing the inner router from
// outside the scope
autorouter.innerrouterof(context, userroute.name).push(userpostsroute());
},
),
],
),
body: autorouter(), // we're trying to get access to this
);
}
}
note: nested routing controllers are created along with the parent route so accessing them without context is safe as long as it’s somewhere beneath the parent route ( the host page ).
route guards
think of route guards as middleware or interceptors, routes can not be added to the stack without going through their assigned guards, guards are useful for restricting access to certain routes.
we create a route guard by extending autorouteguard from the auto_route package
and implementing our logic inside of the onnavigation method.
class authguard extends autorouteguard {
@override
void onnavigation(navigationresolver resolver, stackrouter router) {
// the navigation is paused until resolver.next() is called with either
// true to resume/continue navigation or false to abort navigation
if(authenitcated){
// if user is autenticated we continue
resolver.next(true);
}else{
// we redirect the user to our login page
router.push(loginroute(onresult: (success){
// if success == true the navigation will be resumed
// else it will be aborted
resolver.next(success);
});
}
}
}
important: resolver.next() should only be called once.
the navigationresolver object contains the guarded route which you can access by calling the property resolver.route and a list of pending routes (if there are any) accessed by calling resolver.pendingroutes.
now we assign our guard to the routes we want to protect.
autoroute(page: profilescreen, guards: [authguard]);
after we run code generation, our router will have a required named argument called authguard or whatever your guard name is
// we pass our authgaurd to the generated router.
final _approuter = approuter(authguard: authguard());
customizations
materialautorouter | cupertinoautorouter | adaptiveautorouter
| property | default value | definition |
|---|---|---|
| preferrelativeimports [bool] | true | if true relative imports will be used when possible |
| replaceinroutename [string] | ” | used to replace conventional words in generated route name (whattoreplacepattern,replacment) |
customautorouter
| property | default value | definition |
|---|---|---|
| customroutebuilder | null | used to provide a custom route, it takes in buildcontext and a custompage and returns a pageroute |
| transitionsbuilder | null | extension for the transitionsbuilder property in pageroutebuilder |
| opaque | true | extension for the opaque property in pageroutebuilder |
| barrierdismissible | false | extension for the barrierdismissible property in pageroutebuilder |
| durationinmilliseconds | null | extension for the transitionduration(millieseconds) property in pageroutebuilder |
| reversedurationinmilliseconds | null | extension for the reversedurationinmilliseconds(millieseconds) property in pageroutebuilder |
materialroute | cupertinoroute | adaptiveroute | customroute
| property | default value | definition |
|---|---|---|
| initial | false | sets path to ‘/’ or ” unless path is provided then it generates auto redirect to it. |
| path | null | an auto generated path will be used if not provided |
| name | null | this will be the name of the generated route, if not provided a generated name will be used |
| usepathaskey | false | if true path is used as page key instead of name |
| fullscreendialog | false | extension for the fullscreendialog property in pageroute |
| maintainstate | true | extension for the maintainstate property in pageroute |
cupertinoroute specific => cupertinopageroute
| property | default value | definition |
|---|---|---|
| title | null | extension for the title property in cupertinopageroute |
customroute specific => pageroutebuilder
| property | default value | definition |
|---|---|---|
| transitionsbuilder | null | extension for the transitionsbuilder property in pageroutebuilder |
| customroutebuilder | null | used to provide a custom route, it takes in buildcontext and a custompage and returns a pageroute |
| opaque | true | extension for the opaque property in pageroutebuilder |
| barrierdismissible | false | extension for the barrierdismissible property in pageroutebuilder |
| durationinmilliseconds | null | extension for the transitionduration(millieseconds) property in pageroutebuilder |
| reversedurationinmilliseconds | null | extension for the reversedurationinmilliseconds(millieseconds) property in pageroutebuilder |
custom route transitions
to use custom route transitions use a customroute and pass in your preferences.
the transitionsbuilder function needs to be passed as a static/const reference that has the same signature as the transitionsbuilder function of the pageroutebuilder class.
customroute(
page: loginscreen,
//transitionsbuilders class contains a preset of common transitions builders.
transitionsbuilder: transitionbuilders.slidebottom,
durationinmilliseconds: 400)
tip use @customautorouter() to define global custom route transitions.
you can of course use your own transitionsbuilder function as long as it has the same function signature.
the function has to take in exactly a buildcontext, animation<double>, animation<double> and a child widget and it needs to return a widget, typically you would wrap your child with one of flutter’s transition widgets as follows.
widget zoomintransition(buildcontext context, animation<double> animation, animation<double> secondaryanimation, widget child) {
// you get an animation object and a widget
// make your own transition
return scaletransition(scale: animation, child: child);
}
now pass the reference of your function to customroute .
customroute(page: zoominscreen, transitionsbuilder: zoomintransition)
custom route builder
you can use your own custom route by passing a customroutebuilder function to customroute, there isn’t a simple way to strongly-type a static function in code generation, so make sure your custom builder signature matches the following.
typedef customroutebuilder = route<t> function<t>(
buildcontext context, widget child, custompage page);
now we implement our builder function the same way we did with the transitionsbuilder function,
the most important part here is passing the page argument to our custom route.
route<t> mycustomroutebuilder<t>(buildcontext context, widget child, custompage<t> page){
return pageroutebuilder(
fullscreendialog: page.fullscreendialog,
// this is important
settings: page,
pagebuilder: (,__,___)=> child);
}
we finish by passing a reference of our custom function to our customroute.
customroute(page: custompage, customroutebuilder: mycustomroutebuilder)
more docs are coming soon
support auto_route
you can support auto_route by liking it on pub and staring it on github, sharing ideas on how we can enhance a certain functionality or by reporting any problems you encounter and of course buying a couple coffees will help speed up the development process.
Comments are closed.