Issue 400 #445
Merged
Issue 400 #445
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@neoziro Do you think this approach is going to end up getting merged in, or are you planning on waiting on webpack to expose a more reliable sync-load method? |
mikaelgramont
added a commit
to surfingdirt/web
that referenced
this pull request
Oct 24, 2019
…Loadable. WIP though, as SSR doesn't work yet, waiting for this PR to land: gregberge/loadable-components#445
gregberge
approved these changes
Oct 30, 2019
|
👍 |
|
|
|
@theKashey should the tests be fixed? |
|
Sorry, forgot to push updated snapshots |
|
@neoziro - only you can merge and publish |
|
@neoziro @theKashey any chance this can get merged soonish? The main disadvantage for monorepos is that you can't install directly by git commit. |
|
Hi everyone! |
toolness
added a commit
to JustFixNYC/tenants2
that referenced
this pull request
Apr 27, 2021
This upgrades our `@loadable` packages to their latest versions. This started as an attempt at trying to figure out what upgrade broke the tests in #2055 (a full upgrade to webpack 5 and all webpack plugins, including `@loadable` packages). Specifically, the ultimate effect of the breakage was that all our static pages returned "Loading locale data..." instead of their actual content, which suggested that the loadable locale bundles weren't being loaded on the server-side when rendering static markup. I debugged the problem by individually upgrading each `@loadable` package until the breakage manifested itself. I narrowed it down to something in between `@loadable/babel-plugin` 5.10.3 and 5.11.0. It looked like this was due to gregberge/loadable-components#445. After looking at `@loadable`'s [`createLoadable.js`](https://github.com/gregberge/loadable-components/blob/b640c82a742ffbccc423439e2e205d1becdf5491/packages/component/src/createLoadable.js), I noticed that it was detecting whether it was running on the server-side (and therefore whether to import synchronously vs. asynchronously) based on whether it was being rendered in the context of a `ChunkExtractorManager`. I then noticed that our static markup rendering logic wasn't actually wrapping the rendering in one of those. Once I changed this, the tests passed. Additionally, this upgrades our `browserslist` package, because it happened to be convenient.
fivethreeo
pushed a commit
to fivethreeo/loadable-components
that referenced
this pull request
Nov 16, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Track the loading state for
isReady, should solve #400The logic so:
__webpack_modules__[key]- load async__webpack_modules__[key]- load sync, only if you are still not loading asyncIn other words - don't load while you load.
Test plan
Hard to reproduce, you have to load component, which would require more than one chunk to load, and the first one to be loaded before second.