Rename router.dart to router.g.dart about auto_route_library HOT 21 CLOSED

Hey @kuhnroyal! as stated in the docs I shouldn't use the .g.dart extension unless I'm using a SharedPartBuilder, because other libraries might use the same file to generate their part of code.
I thought of renaming it to something like GRouter or GeneratedRouter to indicate that it's generated, but that still won't help with .gitignore part and that can be a pain if you don't manually ignore it.

from auto_route_library.

Yea you are right, that's why I suggested the code sample above which would make it a SharedPartBuilder.

I also noted another issue today which I didn't think of before. I am working a lot with build_runner watch. Now having a couple of pages/routes, anytime I change something unrelated to routing in one of these pages, it get's regenerated. Not sure how to solve this other then creating wrapper widgets for every page.

from auto_route_library.

@kuhnroyal watch mode literally watches the file system for changes.
What do you think of having all the Routes declaration in one file instead of annotating the actual route widgets?

I'm thinking something like a route-config file

@AutoRoutes(..global-config)
const List = [
InitialRoute(HomeScreen),
AutoRoute(SecondScreen, ....explicit route config),
]

from auto_route_library.

I think this would help a lot.
Maybe you can support both ways, and then just merge all and check for duplicates.

from auto_route_library.

I'm having second thoughts about this. The whole idea was to not get distracted from the working source file (Your Widget) but now you have to open the route-config file and edit it.

from auto_route_library.

With support for both ways, this would still be possible.
I love the whole idea of having the annotation on the class, but it is unusable with watch mode.

from auto_route_library.

Even with the single config file approach the watch mode problem still persists.

from auto_route_library.

Yea, since the generator checks for arguments. It probably needs to cache those and abort if there are no changes to the constructor signature.

from auto_route_library.

I just removed the generator, now the watch mode causes a re-run of all generators on changes but all my other generators notice that nothing needs to be done - it takes < 1 sec.

With the auto_route generator, when I change something completely unrelated, it re-runs several times and takes > 30sec.

from auto_route_library.

@kuhnroyal I was just focused on making it work, I'm working on a new approach now, maybe you can help me test it out. ...How many screens do you have? also how does this look?

@autorouter
class _$Router {
@initial
HomeScreen homeScreenRoute;
SecondScreen secondScreenRoute;
}

from auto_route_library.

@kuhnroyal please check out version 0.2.0 whenever you get the chance and share your thoughts.

from auto_route_library.

This looks really good, no more endless rebuilds.
Still not sure if this is a good way to go with having to import the generated router file.

from auto_route_library.

@kuhnroyal What do you have in mind?

from auto_route_library.

Looking at this I feel this should become a shared part builder but I am not sure how to solve the name conflict of the route declaration/string name and the imports of the generated routes argument classes.

from auto_route_library.

The main problem here is that part files can not import anything and as you can see I'm doing alot of importing in the generated file.

from auto_route_library.

Yea I have looked at it and I am not sure how to solve it. I will think about it a little more.

from auto_route_library.

I appreciate the effort. let me know if you come up with something.

from auto_route_library.

1

from auto_route_library.

@windrunner414 is it? can you please link me to a documentation or something?

from auto_route_library.

@Milad-Akarie sorry I was mistaken :) already edited

from auto_route_library.

@windrunner414 it's okay. I think it's time I closed this one anyways

from auto_route_library.