Navigator 2.0 Remaining Work

[goderbauer]

• Integrate Navigator 2.0 with the web engine (Router widget web engine integration #64494), PR: Implement browser history class for router widget engine#20794
• Migrate the Stocks app as an example, in progress: stock app rewrite using router #63424
• Deep link support:
  • iOS, Cannot deep link into the iOS with URL #66294
  • Android, Cannot deep link into the android with uri intent #66148
• examples, codelabs, tutorials (Makes Router more accessible to developers #63429), in progress

Punted:

• Integrate Navigator 2.0 and state restoration for the web (Integrate Navigator 2.0 and state restoration for the web #65777)
  • dependent on ☂️ State Restoration Remaining Work #62916
  • see Navigator 2.0 Remaining Work #65776 (comment)

[goderbauer]

/cc @johnpryan @chunhtai

[goderbauer]

In a discussion with @mdebbar, @yjbanov, and @chunhtai we decided to punt on #65777. We believe that if users really need to restore state, they can do so manually for now by adding stuff to the history entry (just like you can do in other web frameworks or native web as well, so this is not a regression in Flutter). If we receive feedback that people would like to see this done by the state restoration framework, we can revisit that decision and implement #65777 at a later point. At that point, we will also have to solve #33615.

[chunhtai]

Had a conversation with @johnpryan , Our currently plan is to post a blog post about how to use the router widget, and there is no plan to provide opinionated class at this time.

That means we will have a several code samples along with a tutorial blog post, and the stock app rewrite with the Router. @csells Is there anything else that is required to release the Router?

[orestesgaolin]

@chunhtai is the Router approach going to be the recommended one? What about simple Pages API approach where we would just provide a list of pages to the Navigator. Would you also describe this in the blog post as an alternative? From the discussions with folks after the meetup people seem to feel much more comfortable with just Pages API.

[chunhtai]

@orestesgaolin Yes we will recommend Router. In the case where developer only wants to use page API, we should make the Route information parsing in Router API optional. For example, something like this should work

import 'package:flutter/material.dart';
void main() {
  runApp(MaterialApp.router(routerDelegate: MyRouterDelegate(),));
}

class MyRouterDelegate extends RouterDelegate<void> with ChangeNotifier, PopNavigatorRouterDelegateMixin {
  @override
  GlobalKey<NavigatorState> navigatorKey = GlobalKey<NavigatorState>();
  @override
  Future<void> setNewRoutePath(void data) => Future<void>.value(null);

  @override
  Widget build(BuildContext context) {
    return Navigator(
      key: navigatorKey,
      pages: <Page>[MaterialPage(builder: (BuildContext context) => Placeholder())],
      onPopPage: (_,__) =>false,
    );
  }
}

This is currently not working because the RouteInformationParser is a required parameter. We should probably update that.

[johnpryan]

@orestesgaolin The main reason to use Router is to handle routes from the host platform. If you just want to have declarative navigation, then using the pages API alone should work.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.