Skip to content
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

SplitChunks #3

Open
chrisbrooks opened this issue Sep 4, 2019 · 15 comments
Open

SplitChunks #3

chrisbrooks opened this issue Sep 4, 2019 · 15 comments

Comments

@chrisbrooks
Copy link

Hi, Did you ever actually get splitChunks working with AMD targetLibrary? I'm having the same problem. It works with a single chunk but not when you split out the vendor chunks. Thanks

@Beej126
Copy link
Owner

Beej126 commented Sep 6, 2019

haven't come to that just yet but it seems like we might be planning that solve into an upcoming sprint so i'll try to remember to report back on how that turns out

@samuelcastro
Copy link

Any update on this topic?

@jackfox10
Copy link

I'm having this problem as well. Would be interested to hear if anyone has been able to get it working.

@Beej126
Copy link
Owner

Beej126 commented Dec 18, 2019

sorry we're still getting by on having the full bundle.js... not seeing any downsides... are you running into any downsides you can report or does it just feel icky.

i have a sense that it'd be a matter of WebPack Public Path setting via rescripts... notice those docs reference "child chunks"

thread 102 in single-spa has some breadcrumbs for us, especially this post... reading that again and knowing what i know now a few months later this is worth trying next time i catch my breath... i will report back anything i see... please do the same

@jackfox10
Copy link

jackfox10 commented Dec 19, 2019

Hi all. I'm just posting back to let you know that code splitting is possible and works without ejecting.

My application is essentially a lightweight parent application that renders a navigation bar and has a couple of child applications. I didn't really see any downside in using the full bundle but my child applications are using suspense to lazy load a bunch of components and I didn't want to give that up.

It took me a while and a bit of trial and error but as @Beej126 suspected, the trick is to set the __webpack_public_path__ used by the child component. This can be done in the rootComponent.

I read a few comments on different pages saying that you need to remove the html plugin if using CRA but I didn't have to do this.

@Beej126
Copy link
Owner

Beej126 commented Dec 19, 2019 via email

@Beej126
Copy link
Owner

Beej126 commented Dec 20, 2019

Going by @jackfox10's lead, googling "singleSpaReact __webpack_public_path__", and wouldn't you know, 2nd hit was handy concrete code sample... see how they hooked setting __webpack_public_path__ inside of "bootstrap", which sounds like same general area as @jackfox10 describes

https://programmer.help/blogs/micro-front-end-menu-project-1-react.html

Also, this post on wepback.config build time publicPath vs runtime __webpack_public_path__ was clarifying... I like the sound of buildtime and will commit anything I get working

facebook/create-react-app#6024 (comment)

@Beej126
Copy link
Owner

Beej126 commented Dec 20, 2019

Yes, going back to post 102, webpack.config should be a trivial change, will hopefully get time to try tomorrow

single-spa/single-spa#102 (comment)

@jackfox10
Copy link

Yes it should be trivial. If you don't have time tomorrow, I will submit a PR next week with a lazy example next week.

I think here was something that had to be tweaked to load the assets also (by assets I mean fonts, images, media etc) for the child application but this was trivial also.

@Beej126
Copy link
Owner

Beej126 commented Dec 23, 2019

thanks @jackfox10, i got back into this a little... i forgot what i had previously run into along the way... i think there is something else besides the public path needed to make the initial bundle.js a usable module... the webpack settings in .rescriptsrc.js are the chunk related configs i got working thru blunt trial & error... when i remove any of these and wind up with either a main.{hash}.js or otherwise bundle.js, they don't wind up being something systemjs can load anymore even though they look like AMD from the initial define signature, i.e. the module object returned from systemjs.import winds up being empty... i'd love to see your PR for clarity on a known working scenario if you're doing the same general systemjs remote url bundle retrieval as this repo.

@Beej126
Copy link
Owner

Beej126 commented Jan 18, 2020

Yes it should be trivial. If you don't have time tomorrow, I will submit a PR next week with a lazy example next week.

@jackfox10, just a friendly nudge if you could find a moment to paste your working example anywhere

@jackfox10
Copy link

Sorry, I've been swamped recently. Will get this up on Friday or Saturday.

@Beej126
Copy link
Owner

Beej126 commented Jan 26, 2020

Thanks @jackfox10, i will appreciate whenever you can scratch out a moment, definitely know how it goes =)

besides the public_path piece, I'm missing something crucial with the chunked module format... after putting webpack back to default chunk gen, systemjs can no longer load the first chunk ... I was expecting that first chunk load to be the same as a single bundle and then that first chunk would initiate other chunks via public_path?

@KeshavGeek
Copy link

Hi Everyone,

I hope you guys are doing good. Is there any update on this issue?

@Beej126
Copy link
Owner

Beej126 commented Oct 30, 2020

On my project we've moved away from the micro-spa idea with a re-visioning of the project's complexities that hindered development velocity. I'd say we were looking at micro-spas for three primary benefits: 1) segmenting for download optimization, 2) deployment isolation and 3) multiple web framework cohabitation... Along with "embracing the monolith" =) we're expecting the built-in React code splitting with lazy & suspense to provide a more manageable equivalent of #1... #2 really turned out to be more of a burden than payoff given the single focused nature of our deliverable... i can see how larger projects would need this more than we do... on #3, we mostly had Blazor on the mind and that could still be something that brings us back to this space eventually but for now our codebase is homogeneous react typescript... i haven't tried the very latest .net 5 rc blazor bits yet but just prior to that it was re-rendering way too slow for our needs... a traditional internal LoB application requiring high information density (e.g. lots of input fields and grids) versus fluffy public facing stuff. Best of luck to all who carry on in this direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants