Huge component size

[cristijora]

Just noticed that the overall component has 400+ kb in size.
I must say that's pretty huge for a component that generates fields.
After taking a look at the source code I noticed that moment.js is used in several places for very basic functionalities. I think you can get rid of it to save some space.

Only by removing all moment js dependencies (4) the size shrinked from 400kb to 176kb.
There is also one component fieldVueMultiSelect which for some reason uses the whole Vue library. I don't think there is need to bring the whole library just to instantiate that component. There should be another way of doing it. By removing the vue dep the final file further reduces to 126kb.

Taking down lodash util function brings the file down under 100kb.
To sum it up, by removing only external dependencies (moment, vue and lodash) I managed to bring the library down from 400+ kb to 55kb and by removing external components it goes down to 29kb.

The size here is huge factor for people deciding whether to use such a component or not. I would say we could shrink this one down to 100-150kb very easily and then with some effort it can be brought under 100kb.

[icebob]

Thank you for your explain. Could you make a PR with this changes?

[cristijora]

Yes, I will make one today with some simple changes which should reduce the size in half :)

[icebob]

This is the current bundle stat:

The source is only 2.8%. The others: vue (28%), moment (35%), lodash (42%)

[cristijora]

Interesting. What did you use to get those stats?

These are the 2 files you get when installing the component via npm (402 kb)

[icebob]

I used this tool: https://chrisbateman.github.io/webpack-visualizer/
If you make a build, there will be a stats.json in root of repo. And you need to drop this file to the visualizer site.

[lionel-bijaoui]

Hi, this issue has the same goal as my other one #67
I absolutely agree with @cristijora and at the time, I already got impressive result.

I think the generator should be on it's own and people should just pick and choose which one they want.
I don't know if each field should have it's own sub repo (eg. vfg-checkbox) or if we could provide the same flexibility with only one repo.

What are your thought ?

[cristijora]

Agree witht that @lionel-bijaoui . What's the impact of externals ? Don't quite understand it.

[lionel-bijaoui]

@cristijora with external, you need to add them globally (via a script tag) and webpack will use that reference. But it was a solution that fitted my need (my project use moment.js anyway), and I'm not sure this is the best for vfg.

At the time I envisioned that you could specify by field, what dependency it have and simply add it in a script tag (some fields do that). But I'm not sure that it would work if you import the lib. Also it force to use the lib in a global context.

Doc : https://webpack.github.io/docs/library-and-externals.html

Edit: Better doc (for webpack 2 but it is mainly the same process) : https://webpack.js.org/guides/author-libraries/

[cristijora]

Ah got that. Don't think that's a robust option. Ideally it would be nice to get rid of the external dependencies or use strictly what's necessary which is ok in the case of lodash, but for some reasons it imports a lot of code. Moment is used only in 4 places for some basic stuff. We can get rid of it I think.

[icebob]

Thanks @cristijora . Your PR merged. Now there is only lodash (75% of bundle).

[icebob]

Maybe webpack 2 tree-shaking can be remove the unused lodash functions?