Deprecate initializers and instance initializers #1120
Conversation
| // | ||
| // These can be awaited, which was not possible before | ||
| console.log(instance); | ||
| ``` |
There was a problem hiding this comment.
Where is that file located? What's the proposed filename?
Second, a thing currently missing (ok, badly located) is to programmatically configure your app (currently beforeModel() hook in application route). This seems like the place to do that config as well (when the instance is available then). When thinking about this as runtime configuration, that - to me - brings all that in one place I was hoping for years to have.
There was a problem hiding this comment.
Ah, sorry, it's the index.html' i'll clarify that
Second, yeah, perhaps i'll add an example for that
| > [!IMPORTANT] | ||
| > The above 3 line entrypoint for ember applications will remain the default. This RFC is primarily about updates to documentation showing how we can achieve a new way of "initializers" while also slimming the default experience for new projects. | ||
|
|
||
| The new pattern provides explicit control over application lifecycle in the main application entry point (still within the index.html): |
There was a problem hiding this comment.
I think you'd want to propose the new pattern before deprecating initializers. Can the following pattern be done in classic build apps? (I know the RFC says to assume the v2 app blueprint but it wasn't clear if that was for examples or for the entire proposal -- if it is the later, we would need a replacement for classic builds as well in order to deprecate initializers).
There was a problem hiding this comment.
the new pattern cannot be done in classic apps because Application.create() is not in userland code anywhere
There was a problem hiding this comment.
need a replacement for classic builds
I don't think this is worth doing, personally
There was a problem hiding this comment.
I agree -- we should instead tie this deprecation timeline to when classic builds will be deprecated
| Developers can extract the contents of the script tag to a `boot.ts` or `boot.js`, with the same contents. | ||
|
|
||
| > [!DANGER] | ||
| > Since initializers would no longer be tied to the application instance itself, initializers would not normally run during tests. |
There was a problem hiding this comment.
This seems like a major foot-gun. It would keep me from ever using this replacement and ever suggesting it to others. I would continue to put initialization code that needs async in the beforeModel of the application route.
I think it would be bad form for us to suggest users add code that does not, by default, run in tests.
There was a problem hiding this comment.
🤔
I think we have to go with one of the alternatives then (still not available in classic), but would retain initializer code in ember, and would also remove the ability to have async initializers
-- but this proposal could propose a change to make them async as well, I suppose
Propose deprecating initializers and instance initializers
Important
For those that do use initializers, not only do you have a path to continue doing so, you will can already use async initializers today
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP