Code splitting

[alfonsogarciacaro]

I think I found an easy way to split code with Fable! Latest Fable.React beta includes LazyComponent.FromExternalFunction which allows you to lazy load a component while keeping the type-safe reference. Can you please give it a try and check if it works? When you click on a question it should download another chunk (0.js).

[alfonsogarciacaro]

Unfortunately the benefit is not so big because there's still a static dependency to the update function of the component. I wonder how we could prevent that, maybe we could also load the update function indirectly or somehow pass the update function together with the message?

[alfonsogarciacaro]

At least, by moving the showdown import to Answer.View as this commit does the code for the markdown converter is removed from the vendors chunk and it's only loaded when loading Question.Show.

[alfonsogarciacaro]

Webpack production bundles (hashes omitted):

No code splitting
app.js	135 KiB
vendors~app.js	329 KiB

Code splitting
2.js	6.31 KiB
3.js	70.8 KiB
app.js	172 KiB
vendors~app.js	259 KiB

2.js is the part taken away from app.js. Interestingly, app.js becomes bigger, I assume it's because tree shaking cannot be too aggressive when splitting chunks. The main benefit from code splitting in this case is 3.js, which contains the showdown library and is split from vendors~app.js. It won't be downloaded until is actually needed (when the user selects a question).

[MangelMaxime]

Hello @alfonsogarciacaro ,

sorry for the delay. Indeed being able to move some of the library load out of the vendors.js file is interesting.

I am just a bit worried if the increase of app.js is really due to tree shaking being less effective. Then for "real" world application it could become a problem and perhaps the vendor size reduction would be negate by the increase of app.js

[alfonsogarciacaro]

Yes, it's not a fit-all solution. We can just keep the PR as an example. If I've time I'll try to investigate more the difference in the bundles.