-
Notifications
You must be signed in to change notification settings - Fork 27.6k
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
A way to stop loading the same module multiple times. #253
Comments
Yeah this one is interesting. I would definitely expect the module to be initialized only once. |
In other words, I don't think we need a way to prevent it, we just need to make it work as expected. |
FYI: This is not happening with normal Webpack based code splitting. Still, they they load duplicate modules but only load the module once. May be it's time we should try to use Webpack2 and @nkzawa what are blocks for us to use that. Otherwise, we may have to write a lot of stuff. |
webpack2 is still beta, so I worry it might be unstable and can be incompatible with external plugins. I think there is no feature we needed on webpack2, or does it help to solve the issue? About |
I'm +1 on moving to webpack2, since it also gives us tree shaking |
I assume Webpack 2 is ready. They just wanted to just ship the new website. I assume moving to Webpack 2 let us to worry about important stuff while Webpack do what best it is. When it's time to configure, we can simply ask them to refer website docs. APIs. For an example, optimitizing code splitting is pretty important and it's hard to guess that in the framework level. See: https://webpack.js.org/plugins/commons-chunk-plugin/#move-common-modules-into-the-parent-chunk |
Additionally, we should do it in a way where the developer doesn't need to worry about |
Yeah. This is connection to a big improvement we can make for route code evaluation. So, let's say today you have:
Let's say both Ideally, the JSON response would look like this for
In addition, ideally we load the scripts in parallel (injecting them as |
I think we can create another issue for moving to webpack2. @rauchg I think that would be really slow in some cases if it's not HTTP/2. A solution is that we fetch next page as a chunk like we do now, but reuse modules within the chunk if there are caches on client. It's not ideal but there is no downside compared to the current situation. |
Yeah, another option is to advertise what bundles the client already has in the request, but that can add up to be huge. We have to balance the cost / benefit of the extra roundtrip. If most people (like us) will deploy using pre-fetching, it's not bad. |
@arunoda I couldn't see any solution, This issue has been fixed? I have seen many issues related to it (Top Level Component/ Common Layout), some of them are open and some of them are closed due to a long talk. please share if it has been fixed and merged in any release, thanks for your kind work :) |
I'd be interested to hear updates on this. Discovering that multiple 'instances' of the same modules can exist is completely different to the expected behaviour of nearly every JavaScript module implementation. Seemingly it makes it impossible to create a singleton for example. |
@djskinner It would have the END here |
How did this get fixed? If my // api.js
let token;
export const setToken (t) => {
token = t;
}
export default const api = () => {
console.log('Sending request with token: ', token);
} // _app.jsx
import { setToken } from './api.js';
export default MyApp extends App {
static getInitialProps ({ ctx }) {
setToken(ctx.req? ctx.req.cookies['token'] : Cookies.get('token'));
....
}
...
} // page.jsx
import api from './api';
class Page extends Component {
static getInitialProps () {
api(); // should log correct auth token
}
} However, at least in development on the server, I get the auth module duplicated in both
|
This has been fixed. Will be available in the upcoming canary release. |
@timneutkens I just faced the same problem as @joaovieira. |
The fix is on |
@timneutkens, so if I import the same module to the _app and page component, in the page component it will be reinitialize. Am I right? |
@timneutkens thx a lot for the fix, i confirm that it's fix my similar issue, but since i upgrade my next version from 6.1.1 to 6.1.1-canary.4 the HMR seems to not working anymore, are you aware of this ? |
Hi @timneutkens , the fix doesn't seems to be included in the 6.1.2, do you know when it will be merge in a non-canary version ? Thanks a lot |
When next 7 comes out. |
Thanks a lot @timneutkens for your quick reply. |
Stats from current PRDefault Server ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Client Pages
Client Pages Modern
Client Build Manifests
Rendered Page Sizes
Serverless ModeGeneral
Client Bundles (main, webpack, commons)
Client Bundles (main, webpack, commons) Modern
Client Pages
Client Pages Modern
Client Build Manifests
Serverless bundles
Commit: b5da739 |
Have a look at the following two pages:
pages/index.js
pages/about.js
And here's the Counter component
components/Counter.js
Here's the situation:
Counter
module gets loads for the first timeCounter
module loads again.This gives us two issues:
Possible solution
The text was updated successfully, but these errors were encountered: