-
Notifications
You must be signed in to change notification settings - Fork 8
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
How to use it properly #49
Comments
oh, it's weird because types file should be a separate unit which only imports can you add a commit to reproduce circular dependencies in your example repo? |
@retarsis Sure, it's this commit. When you open up a-overview.component.ts in VSCode, the nx linting rule will tell you about the circular dependency. The problem in detailIn a monorepo setup like nx, features (libs) can be reused in multiple apps and don't know anything about the app they're used in. So storing the generated typings on app level is not going to work in my depicted scenario: if you want to use a route path of a feature in another feature and vice versa. On the other hand, storing the routes in the feature lib itself also won't work as this can introduce circular dependencies as I explained in the example above. So I don't see any other solution than storing the route typings in a separate lib with no reference to the feature lib (to keep it loosely coupled). So the feature lib and all other features/apps can use the generated routes without introducing circular dependencies. This introduces a small problem: the generated routes typings can get out of sync with its source. In the project I'm working on right now, we just have a separate lib with all routes/magic strings and use this lib in both the components (for routerLinks) and in modules for the routing declaration. This has also the downside of this lib sometimes not being used and the lib with the routes being out of sync with the reality. SidetrackWhile preparing this comment, I also came across a bug regarding lazy loaded modules and empty paths. The types are not correct for those. They are called 'root' while they're just an empty string. When you use those with the routerLink directive they obviously won't work because there is no route with a 'root' path. The correct route path is an empty string. |
@JoepKockelkorn i'll answer for sidetracks In general, it is so conceived, to have a "root" key for empty paths {
location: {
root: TypedRoute<[
'/',
'location'
]>;
map: TypedRoute<[
'/',
'location',
'map'
]>;
}
} as you can see, location has a property sorry for this, I'll take some time to brainstorm this, otherwise I'll add additional documentation about this does it makes sense? did my answer help? about the main question - I think the problem is solvable, give me a little more time to figure out what is wrong and how it can be done better |
I think I then stumbled upon a bug in the Btw, I get the way you intended it now. The idea is quite okay 😄 but it might clash when the dev actually has a route named 'root'. It might be more dev friendly if |
Correct (we keep {
location: {
root: TypedRoute<[
'/',
'location'
]>;
map: TypedRoute<[
'/',
'location',
'map'
]>;
}
} Wrong ( {
location: {
root: TypedRoute<[
'/',
'location'
]>;
}
} If route has no siblings, then it will be structured in that way: {
location: TypedRoute<[ '/', 'location']>;
} |
@retarsis Yes it's available in my repo. Just navigate to |
@JoepKockelkorn thanks a lot, again 😅 I will come back to this issue tomorrow as there is a lot of other work to be done. |
So, both issues are identified and I started working on it. |
@JoepKockelkorn I have news The fix is in sorry for keeping you waiting but there is more good news |
@retarsis Nice, thanks! Regarding the waiting, no problem as I don't use it yet. I have to figure out how in a nx setup. |
@JoepKockelkorn about and starting from the next release you generated files will be located in the |
How is the circular dependency not real? Even though they're just typings, it's definitely a reference in both ways.
So what happens if you have two apps and you generate the typings for both of them? |
if I'm not mistaken typescript destroys types on compilation
Each generated |
just released 0.8.0 |
@retarsis Looking good, nice to see my comments being taken seriously. However, I'm not convinced of the If this package would have the following features then the devs can decide for themselves how to use it properly:
If this tool would have these options I would use it as following in a nx repo:
Generating the typed routings of a feature module is currently not possible as it throws this error: |
@JoepKockelkorn I do appreciate your efforts, therefore we try to help in response You say interesting ideas, but meanwhile, they are not quite included in the project plans for the 1.0.0 release, and I want to spend time improving the parser and other basic features that are necessary for the 1.0.0 release. What you propose sounds interesting, and it really makes sense, since I already had experience with workspaces. Therefore, in order not to miss anything, and to separate the problem from the request, I propose to proceed as follows:
@JoepKockelkorn does that suit you? |
@retarsis Yeah of course! My priority is not yours, I understand that completely 🙂 |
Closing this issue, created an RFC #73 |
Imagine in my example repo that I were to:
nx g @routerkit/core:parse --project app
I would then stumble upon two circular dependency issues, as the libs 'feature-a' and 'feature-b' cannot depend on the project 'app' so I cannot use the typings. Even if you would generate the typings for the feature libs and expose them from the lib itself, you would have a circular dependency between libs 'feature-a' and 'feature-b' as they need to reference the generated typings from each other. When not using the generated typings, this pictured scenario is perfectly possible because they are loosely coupled using some 'magic' strings. How will I still be able to use the typings in this setup (monorepo nx style)?
The text was updated successfully, but these errors were encountered: