-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
SSR Loadable example #19
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
Conversation
* feat: implementation of server-side rendering * docs: update README.md
# Conflicts: # comprehensive-demo/app-01/package.json # comprehensive-demo/app-01/public/index.html # comprehensive-demo/app-01/src/bootstrap.jsx # comprehensive-demo/app-01/src/index.jsx # comprehensive-demo/app-02/package.json # comprehensive-demo/app-02/src/bootstrap.jsx # comprehensive-demo/app-02/src/index.js # comprehensive-demo/app-03/webpack.config.js
Yep, the remote is here. It works with bootstrap import in the host and normal entry in remote so I will leave it like that. Why is it good to use bootstrap though? With this setup I'm getting 2 chunks via jsonp: 197 contains So they are necessary parts. Main question: how to predict that these chunks will be needed on client? Loadable uses "namedChunkGroups": {
"main": {
"name": "main",
"chunks": [
179
],
"assets": [
"main.1d6d0191b0eb01a2689e.js"
/* I belive there should be 197.dd5598a4dea5d61081a6.js*/
],
"auxiliaryAssets": [
"main.1d6d0191b0eb01a2689e.js.map"
],
"children": {},
"childAssets": {},
"isOverSizeLimit": false
},
"Async": {
"name": "Async",
"chunks": [
648
],
"assets": [
"Async.708b8060e1f55bbe4db0.js"
],
"auxiliaryAssets": [
"Async.708b8060e1f55bbe4db0.js.map"
],
"children": {},
"childAssets": {},
"isOverSizeLimit": false
}
} |
You’d need to federate the loadable stats as well so the host is aware |
I’ll take a look :) |
BTW I figured out why async-node breaks with loadable components. It works with chunks in sync way. @theKashey any ideas about how we can solve it? |
Hey guys, long time no see 😁 Meanwhile - |
@theKashey I tried but got the same error. I want to check the example in loadable repo. Maybe I was wrong and the problem exists there too. |
I can confirm that example in loadable repo fails too. I believe it's better to track in loadable repo so I will file the issue and will add the example |
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 looks awesome. Question on the merged stats file. It seems like website1 is referencing website2's stats directly from source, is that correct?
@SapienTech you can import/fetch it from any source, for example from S3 |
@7rulnik there is already a issue filed in loadable repo for this issue gregberge/loadable-components#558
👍 |
server-side-rendering? It fails due to moment-js "default export" transformation, which is a bit different case. |
@theKashey I tried without moment too. Same error. |
Ok, but we are talking about the same example. I was running it with changes in the PR I've mentioned above just a few days ago, and it was working (except loadable.lib). |
can you specify steps to reproduce it in |
I created PR with repro failing with |
@7rulnik - I'll borrow your example for imported-component as well. |
Async node uses fs+vm vs node which uses require |
@ScriptedAlchemy so we need these assets in webpack stats or in separate federation stats. I want to contribute it, but maybe you could point me where I should start? |
@7rulnik - please check this PR - gregberge/loadable-components#573 - might be it changes something in a way you need it. |
Why did you close it? @ScriptedAlchemy |
Rewrite git history |
can you branch off master, then merge this back into a new branch that's fresh from baster |
* feat: use mock s3 to stream federated code * refactor: use SSR demo as base app
I tried to lunch it but no luck.
With target
async-node
I'm gettingTypeError: Cannot read property 'call' of undefined
on the server side. Butnode
it works.There are some problems with rehydration, but I believe it's because of wrong stats.
I think it's a good idea to try
async-node
in a different project without module federation.UPD: changed target to async-node in this example https://github.com/gregberge/loadable-components/tree/master/examples/server-side-rendering and everything is alright.