Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Route with parameters #3

Closed
siuying opened this issue Jan 13, 2016 · 3 comments
Closed

Route with parameters #3

siuying opened this issue Jan 13, 2016 · 3 comments
Labels

Comments

@siuying
Copy link

siuying commented Jan 13, 2016

When I use SwiftFlowRouter in a real-ish app, I figure I'd need to send parameters with route. For instance "/users/123" or "/posts/2345/comments"

I could use route ["Users:123"], ["Posts:2345", "Comments"] to represent them, but the swift way to do them is probably instead of string, use a StateType where have a name and parameter state as route?

I have also see subRouteState field, but I have no idea what it is and what it does.

@Ben-G
Copy link
Member

Ben-G commented Jan 16, 2016

Hi @siuying. Really good questions! Passing arguments as part of routes is one of the most important next steps for this router - I've been thinking about it a little, but haven't implemented anything yet.

I want to note that I think in most cases, it is simpler to set the state for the next scene separately, before you change the route - then you don't rely on this feature at all. You can have one action that sets the selectedUser (which would be part of your state struct) and then another action that triggers a transition to a detail scene that actually displays that selected user. I've been mostly using this approach.

You however do need the possibility to pass data along with routes, when you have a recursive navigation stack. E.g., you select a user and the next view again allows you to select a user, it simply pushes a new view controller of exactly the same type. In such a case you can't simply add an individual field to your application state - that's why I've started to look into a solution for this.

The subRouteState field was my original concept; the idea is that you can store arbitrary application state for any specific route. You can imagine this to be associated data for a route. Originally I thought it would be best to access that data through the index of the current route, e.g. if you're the 5th element of the current route, your associated data will be stored in the 5th slot of subroute states.

I however am trying out a different slightly approach know, you can see it here. In this approach the key for storing route specific state is the string that represents the current route. The code is still really ugly, but the idea should work. When I implement this API for the router you will be able to store associated data for any route - we can then wrap this into a nicer API.

I hope this answers your question! I'd also love to hear alternative suggestions!

I'll keep this issue open until implementation, documentation and tests for this feature exist.

Thanks for your contribution!

@siuying
Copy link
Author

siuying commented Jan 21, 2016

Thanks! I think using separate state for next scene is simplest and cleanest for now.

In the example you show, I'd say routes have their own state would be much simpler.

Instead of:

store.dispatch( SearchTwitterScene.SetSelectedTwitterUser(twitterUser) )
store.dispatch( pushRouteSegement(GreetTwitterViewController.identifier) )

We can simply:

store.dispatch( pushRouteSegement(GreetTwitterViewController.Route(twitterUser)) )

where internally no more store.dispatch(SetRouteSpecificData(route: newRoute, data: twitterSceneState.twitterSceneState.selectedTwitterUser!)) -- route specific data should stay inside route object itself.

@Ben-G
Copy link
Member

Ben-G commented Mar 17, 2016

This should be fixed via #18. Please reopen if anything about the new feature is unclear!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants