-
Notifications
You must be signed in to change notification settings - Fork 12
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
Make sure lazy engines with async routes are handled #150
Conversation
There is a failing test which I will look into if this is generally the right thing to do. |
It looks like all tests pass but there is some weird issue where running yarn does not generate node_modules for the linked lazy-engine. https://travis-ci.org/nickiaconis/ember-prefetch/jobs/586819795 I also see this issue locally. however if I simply run yarn again everything works out fine. any ideas where I might be going wrong? |
8106dce
to
d3df4d5
Compare
Ok, a little tinkering with the travis configs and I finally got everything working. |
bfd6223
to
ab03a39
Compare
after some extra experimenting I'm not so sure this the right thing to do. but at least it is here to get feedback and start a discussion about it. |
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.
Changes generally seem good to me, there are a few things to resolve (some have inline comments as well):
- Split out into a couple separate PR's for:
- Dropping Node 6, 9, and 11 support
- Updating CI config to use
yarn
instead ofnpm
- The runtime functionality change (probably keep in this PR)
- Confirm that CI is running against [email protected],3.8,3.12
- Change the promise handling around a bit (using
RSVP.Promise.resolve
instead ofRSVP.resolve
) - Confirm that we do not expect to synchronously have a
route._prefetch
in the case of non-lazy engines. I suspect this is an assumption that we have, which this PR is invalidating. To address, we would need to setroute._prefetched
synchronously when theroute
wasn't a promise and set it async when it is.
ab03a39
to
92eef42
Compare
92eef42
to
a86f092
Compare
a86f092
to
3721621
Compare
b054022
to
56eb602
Compare
In preparation for adding ember-engines for testing lazy routes, this sets node version for CI to 8 and updates node engines to reflect that 8 is the lowest supported version. Also updates to use yarn for installing depdencies. The flags are added to prevent install failures related to having "link" dependencies in package.json. I referred to ember-engines repo for these changes. https://github.com/ember-engines/ember-engines/blob/v0.8.2/package.json#L43 https://github.com/ember-engines/ember-engines/blob/v0.8.2/.travis.yml#L54 Related PR: #150
Ready for a rebase now that #151 is landed. |
56eb602
to
097b088
Compare
@rwjblue Thanks for all of your previous feedback! bump, whenever you get a chance. This is actually a blocker for us atm. Thank you!! |
sorry for the delay, will try to re-review today... |
1e20ee7
to
c878262
Compare
ok cool, I also noticed a bug as soon as I looked at the code again so I updated it and added an additional test to make sure prefetch actually works for a routeable lazy engine. however, now there is some funky eslint issue... looking into it |
it looks like
|
however, I see a completely different error in the CI log:
|
well, i came across this ember-cli/rfcs#121 |
created a separate PR for updating the linting packages #154 |
I ran eslint with these changes on top of the eslint changes and confirmed that it runs successfully locally. |
Lazy engine routes are initially promises which resolve to route instances once the modules are loaded. In these cases prefetch current throws an error 'TypeError: route.prefetch is not a function' since it tries to call prefetch directly on the promise. It seems this used to be handled properly but was lost in a more recent refactor. This is just adding the functionality back. It's important to note that we do not preload the lazy engine assets in the test environment here because preloaded engine routes are not promises but the actual route instance. - Adds ember-engines to dev dependencies for testing. - Create a lazy engine in the dummy app. - Make sure we can visit this engine without preloading its assets.
Thank you for all the work here @jackson-dean! This was ultimately replaced by #159 which was released in v4.0.1. Please, let me know if there are other changes/fixes that you are still needing... |
👍 I took a look. It does seem it will fix the issue of prefetch not getting called on a lazy engine, but it still seems we could end up passing unexpected transition and fullParams when the route resolves since those values are extracted in a loop outside of the promise callback. Whether it is actually a problem in practice I'm not sure. If not, it really does not matter that much. |
Thanks @jackson-dean for pointing out! Is this the code you're referring to? https://github.com/tildeio/router.js/blob/v6.2.5/lib/router/route-info.ts#L240 However the serialization happens after waiting model hook I think it’s fine to not wait the serialized params, but a bit documentation about https://api.emberjs.com/ember/3.13/classes/Route/methods/serialize?anchor=serialize would not be called for the |
Hey @xg-wang my concern was just misplaced. I was talking about here https://github.com/nickiaconis/ember-prefetch/pull/159/files#diff-54a7d68a8480ef36da94321be6541ca1R29 but my instinct was completely incorrect and just a consequence of working with js before However, if this code is transpiled with babel to old |
actually, on yet another look, it looks it will even be fine in any case because the outer promise immediately invokes its resolver with the outer route and fullParams. So, yes, at the end I don't have any concern about it. I had also initially missed this line https://github.com/nickiaconis/ember-prefetch/pull/159/files#diff-54a7d68a8480ef36da94321be6541ca1R23 which also mitigates any concern. nice work, and thanks for fixing this! 😄 |
I was running into this error when loading a lazy engine route:
route
in this case was actually a promise which resolved to a route with prefetch method.This converts the change set in the current iteration to a promise to ensure the correct fullParams are used and then normalizes the route to always be a promise so they are treated the same for both cases.