Add support for template definition inside of view configuration (ui-router)

[avishnyak]

ui-router supports defining templates as subviews.

See views.

This supports components, inline templates and inline URLs in 2 flavors (as a config object and as a string):

.state('userlist', {
  url: '/users',
  views: {
    body: {
      controller: "bodyCtrl",
      template: "<component-name></component-name>"  // inline-template as a config object
    },
    header: {
      controller: "headerCtrl",
      templateUrl: "header.html" // templateUrl as a config object
    },
    'top@menu': {
      component: "menuComponent"  // component name as a config object
    },
    footer: "footerComponent"  // component name as a string
  }
}

It seems that to accomodate this, the route infrastructure would need to be refactored to understand multiple templates per route. I can make the PR but would like to get your input first since this would be an architectural change.

[ipatalas]

I don't know this feature of ui-router, gotta catch up but the docs are not very clear for me.

Looking just at the code above it looks like each view is like an embedded component. My first thought would be to extend Route class with views field to accommodate the views:

https://github.com/ipatalas/ngComponentUtility/blob/8e2b0d5c29bca6e4ba27dd859545d112ff9415d7/src/utils/route/route.ts#L9-L18

From what I see in the docs view definition is compatible with IComponentBase interface that's already being used in many places so model changes should be quite easy and backward compatible.

The more difficult part will be to use these views data in all the places where they can potentially be used but for that I'd need to catch up how this actually works and some simple scenario how would you see these views to be used by any of ngComponentUtility features. If this will be in any way difficult for different features it's a good candidate to split and introduce it for one feature first and then the rest would follow later. I prefer to release smaller features more often if they bring value for the users.

I can assist you if necessary during the development but it's pretty busy time for me now like I mentioned in your PR so please be patient.

[avishnyak]

The ui-router feature allows a child route to fill in slots on a parent route.

Adding the views field to Route makes sense to me. I think the first feature that I would like to enable as part of this is more accurate "unused components" just by scanning all of the relevant templates. Secondly, I would like to make sure that these are considered in "find usages" as well.

I'll start working on a PR and send something for review when I can.

[ipatalas]

Ok, I think I get it now.

For these features it should be relatively easy to implement. Good luck and can't wait to see some results.

[ipatalas]

Does the PR you've implemented brings any meaningful value? Not sure if it's enough for a release or we should rather wait for Find unused components or/and Find Usages feature to use it.