-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
Update to Ember 4.12.2 #1076
base: main
Are you sure you want to change the base?
Update to Ember 4.12.2 #1076
Conversation
✅ Deploy Preview for ember-website ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
f2b8523
to
8befbf7
Compare
// Under prember this causes `Attempted to call store.adapterFor(), but the store instance has already been destroyed.` | ||
// So wait a bit | ||
return new Promise((resolve) => setTimeout(resolve, 10)); | ||
} |
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.
This is an ugly workaround for an issue with ember-data and FastBoot/prember. e-d calls flushAllPendingFetches
with setTimeout (which Ember's settledness does not capture, I believe that's the problem), but as the app is torn down immediately after rendering in prember, we are getting:
Assertion Failed: Attempted to call store.adapterFor(), but the store instance has already been destroyed.
I was not really willing to spend much time investigating a "proper" solution, as
- the issue might have been resolved in new releases maybe
- I think we should actually get rid of e-d here. I'll raise a separate issue to explain my thoughts...
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.
One concern I have is that with the current context in the code comment is that it makes it quite daunting to ever touch this part of the code. Is it possible to link to a bug ticket. (Is this even considered a bug, it seems intentional?) Or state when/how this workaround could be removed.
Removing ED would solve the problem as well, but is out of scope for this PR.
Another alternative could be downgrading Ember Data to 4.11 I assume, if this "issue" got introduced in 4.12?
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 didn't file an issue, because I wouldn't want to do so for a version that is out of date and without knowing that the problem is still present in the most recent one. But also ED has deprecated FastBoot support, so likely that could mean they wouldn't even consider it a bug?
Tbh, I don't really remember what happened when downgrading to ED to 4.11, but I am pretty sure I tried. This work is already two months old, which hits my brain's capacity limit 😅
The path I would be pursuing is to remove ED here, so the code you are concerned with wouldn't be around for too long!
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 also a bit concerned about this hack being merged 🤔 I accept your intention to potentially remove ember-data since it's such a simple request response mode, but the intention was for the website to be a good simple demonstration of the capabilities in the default Ember blueprint. I think we should dig a bit deeper into this issue and potentially draft some help from the Ember data team especially if this issue is potentially affecting other people relying on ember-data and prember
Thanks for this! I wanted to look into upgrading as well and only then noticed you had made a PR already 🎉 |
This updates the website to Ember 4.12.2, including:
Probably best reviewed by commit...