Router agnostification - POC

[rclai]

This is an untested effort (should still work with Iron Router though) to make this package router agnostic by first making the router dependencies weak, then creating an API Platform.withRouter() that lets you handle router-dependent logic in the components.

I haven't quite parsed the data context to allow for dev-friendly data-context-passing into FlowRouter.path() when creating URLs in certain components but will do this later so that it's easier.

Let me know if anyone actually likes this before I start testing that it works on Flow Router and doing more stuff to it.

Or if anyone wants to try it out, you can always clone the fork branch.

[rclai]

@nickw, let me know what you think of this idea and whether I should keep going at it when you have the time 😄

[rclai]

Thanks for the feedback guys.

[arunoda]

There is no meteorhacks:[email protected].
It should be kadira:[email protected].

I think we can drop meteorhacks:flow-router at all.

[rclai]

Yeah, that is going to change, thanks.

[arunoda]

How about moving all router specific logic into a separate file. Then if we need to work on a new router, then it's just changing that file.

[rclai]

@arunoda, that sounds like a great idea, but I can't envision how to do that since there is router logic in different components. Can you show me a small example?

[arunoda]

I mean we can create a set of methods like isActive() and abstract the router related logic. Then, when we need to add a support for a new router, simply change the isActive() code and we don't need to change anything inside the ionic logic related codebase.

[rclai]

Ah okay, sounds good. I'll give that a try.

[nickw]

We'd also need to figure out how to handle rendering into regions:

https://github.com/meteoric/meteor-ionic/blob/master/components/ionNavBar/ionNavBar.html#L3-L5

[dalerka]

Apologies if this is not the proper place to mention, but...
Just in case, the option of creating a Router-layer package (to allow using various routers) is discussed here. So, if someone has the necessary skills to build such a package, please take the lead.

[arunoda]

@nickw for that we can simply use Meteor's dynamic templates. I think that works for both routers.
Or if that's not possible, we can build two templates. One for IR and one for BlazeLayout (from Flow).

Otherwise we can simply use BlazeLayout in both flow and IR.

[nicolaslopezj]

I started a router-layer project

https://github.com/nicolaslopezj/meteor-router-layer

[rclai]

Oh wow, router-layer might just be the answer. I'll check it out later.

[rclai]

@nicolaslopezj, are we able to use the Layout template to render things into regions to tackle the issue that @nickw mentioned for this?

Given that it is {{> yield "regionName"}}, how does that translate in Router Layer.

[nicolaslopezj]

{{> yield "regionName"}} currently is not interpreted in Router Layer, only {{> yield }} works