-
Notifications
You must be signed in to change notification settings - Fork 3.4k
[go_router_builder] Change mixin name #9626
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
base: main
Are you sure you want to change the base?
Conversation
d37a558
to
6d653a2
Compare
08d848d
to
decf49c
Compare
Works for me for the moment. :) |
decf49c
to
7d2dde5
Compare
7d2dde5
to
68c783e
Compare
68c783e
to
fc0d0cd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change makes sense to me. we should also update the readme
@chunhtai, so are you ok with the approach where the mixin will be public /private based on the routes configuration? or does it seem too inconsistent for you? If you are ok with the current approach, I will add a note in the readme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think let's just make this a breaking change. I see no reason to not make this a public mixin. WDYT?
String get _mixinName { | ||
// If the routeDataClass is in a different file, we need to make the mixin public | ||
final Uri routeUri = routeDataClass.source.uri; | ||
return routeUri != targetUri ? '\$$_className' : '_\$$_className'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thinking about it more, let's just do a breaking change and make this a public class. having dealing with cases in both seems counter intuitive since we are maintaining a versioned package.
@chunhtai My ideal scenario would be to improve the Generator to be able track the routes in different files without an annotation in every route file
in my ideal scenario, the generator would be able to generate I looked into this, and it seems that it will require so much work and possibly getting rid of |
any update? |
Fixes #170650
This PR fixes workflows that relied on putting child routes in files different than parent files, which resulted in the (private) mixin being generated in a different file than the route itself.
To avoid releasing a new major version in such a short period, this PR makes the mixin public only if needed. Admittedly makes the behavior somewhat unexpected for the user. @chunhtai @hannah-hyj I will leave that decision for you, whether that's ok or I should make it always public and release a major version instead.
Since this change just fixes a use-case that already didn't compile in 3.x.x, this PR doesn't bump the major version.
Pre-Review Checklist
[shared_preferences]
pubspec.yaml
with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under1.CHANGELOG.md
to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under1.///
).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2 ↩3