Octopus는 상태 관리와 중첩 탐색을 강조하는 크로스플랫폼, 선언적 라우팅 솔루션입니다. 단순성과 확장성을 고려해 설계되었으며, 안드로이드, iOS, 웹, macOS, 윈도우, 리눅스에서 구조적이고 반응형으로 경로를 정의할 수 있게 해줍니다. PlugFox가 ❤️ 로 제작한 Octopus는 복잡한 네비게이션 흐름을 간소화하면서 앱 수명 주기 동안 깔끔한 코드와 일관된 상태 처리를 유지합니다.
Octopus is a declarative router for Flutter. Its main concept and distinction from other solutions is dynamic navigation through state mutations. It is a TRULY DECLARATIVE router, where you don’t change the state imperatively using push and pop commands. Instead, you (or the user) specify the desired outcome through state mutations or the address bar, and the router delivers a predictably expected result.
Most solutions use templating for navigation, pre-describing all possible router states with hardcoding (and code generation). While this is an expected and predictable approach in traditional BE SSR (where the page is assembled server-side), it has several serious drawbacks on the client side:
You cannot predict all possible states in advance.
There is no ability to implement routes of arbitrary depth (e.g., /shop/category~id=1/category~id=12/category~id=123/product~id=1234).
Understanding what happens in cases with nested routes can be quite complex.
Loss of state in nested routes, as such routers typically display only the active route, even though the nested state continues to exist.
What does the current solution offer?
Changing state through mutation.
Nested navigation, both through the out-of-the-box solution and your custom implementation.
A router state machine and case implementation based on state changes. For example, it’s very easy to implement breadcrumbs or integrate a tab/sidebar with router state arguments.
A history of states, allowing you to implement a time machine or, after reauthentication, return the user to where they started. Or simply log this for analytics purposes.
A user-friendly API with a "foolproof" design, where mutable states are clear and methods for changing them are provided, and immutable states are also clearly indicated.
A strong focus on Guards. Since the user can now obtain any desired configuration, you might want to "clip their wings." Ensure that the "Home" page is always at the root except for logged-out users, change states during navigation or upon reaching certain conditions, for example, showing login for unauthorized users. Recheck all navigation states on a specific event, just pass the subscription to your guard.
Implementation of dialogs through declarative navigation. No more showing dialogs from the navigator and mixing anonymous imperative dialogs with declarative navigation.
Preserve and display the entire navigation tree in the URL and deep links, not just the active route!
Clear debugging and the representation of the state as a string will simplify development.
Concurrency support a out of the box.
With a declarative approach, the only limit is your imagination!
Set up your routes.
You can use an enum, make a few sealed classes, or both.
This doesn't matter. A recommended and simple way is to get started with enums.
Override a builder function to link your nodes and widgets.
Optionally, set up a "title" field for any route.
Create an Octopus router instance.
During main initialization or state of the root App widget.
To do so, pass a list of all possible routes.
Optionally, set a defaultRoute as a route by default.
Use the context.octopus.setState((state) => ...) method as a basic navigation method.
And realize any navigation logic inside the callback as you please.
context.octopus.setState((state) =>
state
..findByName('catalog-tab')?.add(Routes.category.node(
arguments: <String, String>{'id': category.id},
)));
Of course, there are other ways to navigate, primarily shortcuts for the most common cases.
context.octopus.push(Routes.shop)
But you can truly do anything you want.
Just change the state, children, nodes, and arguments as you please.
Everything is in your hands and just works fine, that's a declarative approach as it should be.
Guards are a powerful tool for controlling navigation.
They allow you to check the state of the router and mutate/cancel navigation if necessary.
For example, you can check the user's authorization and redirect them to the login page if they are not authorized.
State - the overall state of the router can be mutable (while the user mutates the new desired state and in guards) or immutable (all other times). The state can include a hash table of arguments, which are global arguments of the current state. These can be used at your discretion.
Node - the components that constitute the state form a tree structure in the case of nested navigation. Each node has a name and arguments (usually parameters passed to a screen, like an identifier). At each level, within each list of nodes, the combination of name and arguments must be unique, as this forms the unique key of the node.
Route - router has a list of possible routes that can be used in the project. The router matches nodes and routes by their names. Routes contain information on how to construct a page for the navigator.
Take a look closer. That's a tree structure.
Each component of that tree has a List<OctopusNode> children for children nodes and arguments for the current node.
States have arguments, too; it's your global arguments.
Each node also has a name; by this name, you can identify this node and link it with your routes table.
If we try to represent this state as a location string, we get something like that:
/home/shop/.catalog-tab/..catalog/..category~id=electronics/..category~id=smartphones/..product~id=3/.basket-tab/..basket/..checkout?shop=catalog
We appreciate any form of support, whether it's a financial donation or just a star on GitHub. It helps us to continue developing and improving our library. Thank you for your support!