-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
deprecate App::data
and App::data_factory
#2271
Conversation
App::data
and App::data_factory`
App::data
and App::data_factory`App::data
and App::data_factory
Won't people just start doing |
This comment has been minimized.
This comment has been minimized.
Hopefully the deprecation notice will accurately guide existing users to the new code setup. For new users, I suspect it will be far easier to document on I think there are more steps we can take to help, too. For example, the Very willing to debate this further and hash out the complete set of implications; consider this my opening statement. |
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'm OK with changes and actually it makes sense and looks good.
However, now tests for these methods have warnings, and due to many jobs it makes the diff bloated and hard to watch. Wouldn't it be better to add #[allow(deprecated)]
to these tests?
Since this will be a major version release, why don't you just remove instead of deprecate? |
It would be overly distruptive to migration since it would affect almost all AW apps. |
I second the removal as well. We kind of expect breaking changes when doing major upgrades so it allows the removal of old code. We could mark it as deprecated if releasing it on a minor or patch versions. |
Nah, I think that it'd be too radical. While I'm all in for removing things, but for a mature framework that is already being used in production by many teams, it's better to do things gradually. It's OK to clean up the code, but it's less OK to be not predictable and sudden. Given the fact that 4.0 is not so far away, it'll reduce amount of people who will be able to quickly switch to a new version. |
PR Type
Deprecation
PR Checklist
Overview
Partially addresses the problem we have with
.app_data(val)
vs.data(val)
vs.app_data(Data::new(val))
by deprecating.data(val)
and encouraging use of.app_data(Data::new(val))
as a replacement.Also deprecates
App::data_factory()
because of it's limited use. There is a plan to introduce a similar typeLazyData
post-v4 that would be used in the same way asData
and more useful because it allows the app to start serving requests before it resolves.