Aurelia: [Feature] Access to routes information in compile time

Created on 25 Mar 2019  Â·  9Comments  Â·  Source: aurelia/aurelia

🙋 Feature Request

I have already asked this question in other posts but let me ask it again in a separated issue.
I want to access to all information about current routes in compile time.
Some information such as:

  1. Route names
  2. Relation between routes
  3. Related components
  4. and so on

🔦 Context

Create documentation of application is one of the use cases.

💻 Examples

You can find this in Angular Compodoc

image

Most helpful comment

So, after a quick look it seems they are using ts-simple-ast to parse the
modules for their dependencies, and maybe handlebars to parse the links. In
other words there doesn't seem to be anything related to Angular in this
code.

I skimmed it pretty quickly, but I'm guessing you could lift most of the
code right from that file. Since Aurelia doesn't use handlebars, you'd need
to use Aurelia's template parser instead. Still, it should work vCurrent
and vNext.

I hear you loud and clear on the ask: It would be nice if the Aurelia
router provided enhanced, useful information about routes in the
application. We've already got some specs that talk about how, but the
short answer is yes, we're going to provide more information about all the
routes in your application through something like the vCurrent nav model.
I'll tag you when that spec is underway.

On Tue, Mar 26, 2019, 06:53 Hamed Fathi notifications@github.com wrote:

@davismj https://github.com/davismj
Hello,
As you guess I found router-parser.util.ts
https://github.com/compodoc/compodoc/blob/f94d6645c41a1a3d1e10beeb8412fdf2ede39a56/src/utils/router-parser.util.ts
in Angular Composoc source code.

They use parser to do that.
Can I do this in Aurelia vNext in same way? (With children routes of
course)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/aurelia/issues/470#issuecomment-476573417,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADquv_ExZlnlJIlkHfSMY8-_3K1iVP7dks5vafwVgaJpZM4cGEuH
.

All 9 comments

Do you have the source, or information about how they solved this problem in the Angular Compodoc? Of course you can make this in Aurelia, but if you're looking for specific functionality, I'll need more information about what the functionality is.

For simple apps, this can be done today. What I've done in the past is place the routes in a single route.json file. Then import that file into the module that configures your router. If you use the same format as the router, you can just pass it to the router directly. Then, you can also write any tool you want that reads JSON to build out documentation.

With vNext, if it's possible to build out all parent and child routes in a single location, then this same technique could be used to greater success. The only challenge is the component references, which make it no longer pure JSON. However, there's no reason that NodeJS can't still import that module and iterate over the data to build docs.

@davismj

I don't know how they do but if I found something new I share it here.

Of course you can make this in Aurelia

Is your solution similar to that suggested by Mr. Eisenberg?

@EisenbergEffect

With vNext, if it's possible to build out all parent and child routes in a single location, then this same technique could be used to greater success.

I think we need more time to find the answer.

So there is no way to do this automatically.
Not good example but something like Reflection in C# to get information about objects or parse the source code to find information about Route classes. Is it possible in this scenario?

As a conclusion, users should use our predefined rules if they want to document route-related information.

Set the rules like: Write all your routes in the specified JSON file.

Not good example but something like Reflection in C# to get information about objects or parse the source code to find information about Route classes. Is it possible in this scenario?

The tricky part here is that while you can "reflect" on routes, it's the links that would pose an issue. There would need to be some method of parsing all of the templates ahead of time to find where links exist. Otherwise, routes have no notion of being linked to other routes; all routes are available at all times, generally.

What you've presented here is some UI. What you're asking for is some extra, built-in functionality to the framework that would make it easy to build the UI. I'm not sure that would be a good idea, and I wanted to hear out how the given example was built to see (a) is this part of the framework or just something they built custom and (b) if its part of the framework, how did they do it. My guess is that it's not part of the framework.

@EisenbergEffect 's approach is probably what we're seeing in the example given. That is, the routes and their links were not dynamically generated through code and markup, but were statically defined up front, passed to the router, and then also passed to the UI. That's how I would recommend approaching the problem today.

That said, if it was a part of their framework, I'd be interested in seeing how they approached it. Specifically, I'd want to know is their solution clean? They might build something that would be sloppy or difficult to use, in which case it would be better just to let Aurelia developers solve the problem in the way that best suits their application.

@davismj

My guess is that it's not part of the framework.

So am I

it would be better just to let Aurelia developers solve the problem in the way that best suits their application.

Make sense. That is correct.

However I think because of NgModules they can find easily application start point to trace/parse/reflect/track informations of routes.

Thank you so much. Let me close this issue.

I don't want to shut your idea down. It's a cool idea! I'm definitely opening to hearing more if you can present a good case for it. Feel free to keep the thread going if you come back to it.

@davismj
Hello,
As you guess I found router-parser.util.ts in Angular Compodoc source code.

They use parser to do that.
Can I do this in Aurelia vNext in same way? (With children routes of course)
What do you think?

So, after a quick look it seems they are using ts-simple-ast to parse the
modules for their dependencies, and maybe handlebars to parse the links. In
other words there doesn't seem to be anything related to Angular in this
code.

I skimmed it pretty quickly, but I'm guessing you could lift most of the
code right from that file. Since Aurelia doesn't use handlebars, you'd need
to use Aurelia's template parser instead. Still, it should work vCurrent
and vNext.

I hear you loud and clear on the ask: It would be nice if the Aurelia
router provided enhanced, useful information about routes in the
application. We've already got some specs that talk about how, but the
short answer is yes, we're going to provide more information about all the
routes in your application through something like the vCurrent nav model.
I'll tag you when that spec is underway.

On Tue, Mar 26, 2019, 06:53 Hamed Fathi notifications@github.com wrote:

@davismj https://github.com/davismj
Hello,
As you guess I found router-parser.util.ts
https://github.com/compodoc/compodoc/blob/f94d6645c41a1a3d1e10beeb8412fdf2ede39a56/src/utils/router-parser.util.ts
in Angular Composoc source code.

They use parser to do that.
Can I do this in Aurelia vNext in same way? (With children routes of
course)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aurelia/aurelia/issues/470#issuecomment-476573417,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADquv_ExZlnlJIlkHfSMY8-_3K1iVP7dks5vafwVgaJpZM4cGEuH
.

With AOT we will also be going pretty deep down the rabbit hole of analyzing cross-component references and trying to predict how the component structure might look like at runtime. All this in order to try to short-circuit/inline certain pieces of logic for better hot path performance.

Surely if the base infrastructure for that is in place, a large chunk of this logic could be reused to see where in the templates the routes are used and how they relate to each other, in order to figure out the possible routes at runtime. To some extent.

Was this page helpful?
0 / 5 - 0 ratings