Comments (6)
The goal of SwiftUI Router was to provide an alternative to SwiftUI's NavigationView
and NavigationLink
. Never for them to work hand-in-hand together.
Both follow a different ideology: with NavigationLink
(specifically the isActive: Binding<Bool>
initializer) the state of the current screen is localized and the burden of deciding how and where to store the state falls on the user. The user also has to define the destination view when using a NavigationLink
(the destination
argument). The user also has very little say on the transition effects/animations.
SwiftUI Router, on the other hand, uses a global state (the path) and maintains it, removing the burden from the user. The user also isn't required to define the destination view in advance when using NavLink
, Navigate
and navigator.navigate()
. You just tell it what path to navigate to. SwiftUI Router also isn't exclusively for 'fullscreen screens', it works just as well for any view that should only render for certain paths (e.g. a floating menu, an action button, an advertisement). And you are in full control of the transitions and animations (well, as far as SwiftUI allows you)
Having SwiftUI Router support NavigationView
and NavigationLink
would make the library far too complex for its purpose. Both code-wise and UX-wise. In this case it would probably be better to write a separate library. 😄
from swiftui-router.
Hm I wonder whether making the PathMatcher
public is enough. There are several other puzzle pieces that need to be properly set for deeper Routes to work.
Will have to give this a proper think. It's times like these I wish Swift had something like abstract classes/structs 😛
from swiftui-router.
Thanks for the example.
The issue with the presentationMode
idea is that it significantly changes the way a Route works based on the argument. With the .navigation
value the Route now has a NavigationView
as a "dependency", requiring it be somewhere higher up in the view hierarchy to work at all. The Route also changes from an inline view (a view that's rendered where it's defined) to a view that simply communicates with a NavigationView
. This doesn't sit right with me. Instead of this I'd rather see a more explicit API. Maybe a separate NavigationRoute
(and SheetRoute
?) to better differentiate itself from a Route
.
Currently I have no plans for SwiftUI Router as-is to work hand-in-hand with NavigationView
and .sheet
et al 😄
I agree that it's a worthy feature to explore. But this would be better left for a SwiftUI Router 2.0, with a (major?) overhaul in its API. A great opportunity to explore ways to better integrate NavigationView
into SwiftUI Router. And maybe see if it could play nicely with iOS' TabView
as well!
Examples of a 2.0 could be:
- Turn
Router
into a wrapper around aNavigationView
(hiding the UI elements by default) - Make
Route
a more abstract view/object so other libraries can utilize it and build different presentation modes around it. Keeping SwiftUI Router very basic in its functionality, but easy to expand upon.
To me adding support for NavigationView
and .sheet
comes as a significant change that also fundamentally changes the way you think about setting up routes and the structure of your views/code in general. Rather than adding it to SwiftUI Router as it is now I'd rather see a more streamlined API. Something that feels consistent across the board.
I'm keeping this issue open - or may turn it into a discussion, as I think it's important to keep this all in mind for future developments of SwiftUI Router. Even if I've been pretty absent from the SwiftUI scene lately 😅
from swiftui-router.
@koraykoska @frzi While this makes sense, I'd have to disagree. Most if not all iOS apps use navigation of some kind, and if you decide to use this library, you'd need to completely build your own navigation bars and animations that you'd normally get for free. Especially if you are trying to adhere to Apple's Human Interface standards, out-of-the-box SwiftUI components will include the correct font sizing, typography, spacing, animations, etc.
I was about to open a RFC for the sheet/navigation support I added to my fork of this library when I found this issue. The only problem with my approach is you'd need to add a custom back button to your views that would call navigator.goBack()
seeing you can't easily listen for back events. If I could get approval on the approach, I was planning on opening a PR.
Here are my changes:
All this adds is a presentationMode
argument to the Route() constructor that tells it whether to open a sheet, push to the navigation view, or use the default mode of just instantly showing the view.
from swiftui-router.
Hey @frzi! Thanks so much for the detailed response. I actually did almost create a separate component, but didn't want to duplicate a bunch of logic 😂.
I have a proposal, in that case: the biggest reason I forked this repo and suggested an upstream change to the API is the fact that the logic that actually performs path matching is internal to the route component. I would have just as soon created a NavigationRoute
in my own codebase, but I would have had to extract a ton of logic that matches the path from the PathMatcher
class to create the NavigationLink
Binding
.
I previously had a NavigationLink
nested inside a Route
, but this would sometimes create issues with animation when pushing a view onto the stack. I'd prefer to implement it how it is implemented in my fork, as it ensures the NavigationLink
is always rendered and then just uses a binding to control the view.
Do you think it'd be possible to generalize the internal logic of the route matching and expose it? Then we could append the README to include an example of how you could leverage the path matching to push views via NavigationLink
. If we can agree on how we should expose it then I can get a PR open.
Perhaps creating a wrapper component such as PathMatcher
(changing the name of the current ObservableObject
of the same name), that accepts a validator and route and will pass a RouteInformation?
variable into its closure? It'd be separate from the Route
view in the sense that it would still render children regardless of whether the path was matched or not, and then Route
could leverage this component.
Alternatively, at a bare minimum, maybe just make the current PathMatcher
public? What do you think?
from swiftui-router.
@Nickersoft did you continue with this? I'm beginning a project now and like your ideas for this but don't know what else to use meanwhile
from swiftui-router.
Related Issues (20)
- Nested routes without parent being rerendered on child navigation HOT 2
- How to use? HOT 2
- Set path on app launch HOT 2
- view init twice when navigate
- How to navigate to any page HOT 2
- Navigate navigates into void sometimes HOT 3
- Routes with missing optional parameters do not work without a trailing slash (/) HOT 3
- Flexible nested navigation HOT 2
- Can't revisit a page HOT 2
- Full screen navigation without ignoring safe area
- Type safe routes HOT 4
- State of views from the back stack is not saved
- Able to switch to another tab then push to a certain view under navigation view then finally present a modal? HOT 1
- Switch between flows HOT 3
- Full screen navigation above tabView HOT 4
- `.opacity` transition not working HOT 2
- Keep paths loaded in memory for performance (e.g. in tab bar) HOT 2
- xcodebuild error HOT 2
- Navigating to a blank screen issue HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swiftui-router.