DEMO的页面push生硬
建议使用默认的 Navigator.pushName
这么生硬的DEMO很影响Flutter在开发者技术选型时的判断

🚀 Feature

(A clear and concise description of what the feature is.)

Have you spent some time to check if this issue has been raised before?

(Have you googled for a similar issue or checked our older issues for a similar bug)
Yes

Have you read the Code of Conduct?

Yes

Pitch

A common way to mana

New Issue Checklist

• [X ] I have searched for a similar issue in the project and found none

Issue Info

Description
The sidebar toggle (hamburger menu) has too much width on desktop devices and overlaps with the actual menu. This causes the user to accidentally collapse the menu when wishing to navigate to a new section.

Steps To Reproduce

1. Go to the bloclibrary.dev.
2. Click on the last visible menu item next to the sidebar toggle "icon".

Web socket as data Provider

todos_repository_simple explains nicely about the benefits of using repository as singleton. But no where it's mentioned how to handle the web sockets.

How can I use web socket (webSocket and fileStorage) instead of rest (webClient and fileStorage) ?

Some key points between web socket and rest.

• The name itself signify socket

看了fish-redux的todoList demo，发现里面连接全局状态的方法是使用visitor

visitor: (String path, Page<Object, dynamic> page) {
      /// 只有特定的范围的 Page 才需要建立和 AppStore 的连接关系
      /// 满足 Page<T> ，T 是 GlobalBaseState 的子类
      if (page.isTypeof<GlobalBaseState>()) {
        /// 建立 AppStore 驱动 PageStore 的单向数据连接
        /// 1. 参数1 AppStore
        /// 2. 参数2 当 AppStore.state 变化时, PageStore.state 该如何变化
     

thanks to this package we save our time to develop app.

Recently I developed applying Firebase dynamic links to our app.

I had a lot of time that how to test receiving Firebase Dynamic Links path and parameters on iOS TestFlight.
especially how can I test receiving dynamic links parameters after installing app.

But I couldn't understand how to test on it.

finally I thought there is a

What could be improved

Based on this issue: flame-engine/flame#954, I noticed that we could also go for the same approach for the packages' unit/widget tests execution,