Does this support lazy loading / code splitting?

[b12f]

Hi,

We're currently looking at different solutions to start documenting our design system. VDS looks really promising so far, but one caveat might be that our existing project heavily relies on code splitting and lazy loading. We'd like not to load components and the corresponding CSS at all until they become necessary. The documentation only shows a Vue.use(DesignSystem) call and a corresponding global css import, which would load everything globally.

Is it possible to import single Vue components wherever they are used, and only load certain others globally? e.g.

// main.js
import { CustomButton } from 'our-design-system';
new Vue({ components: { CustomButton }});

or

// SomeComponent.vue
import { CustomButton } from 'our-design-system';

export default {
    components: { CustomButton },
};

Perhaps it is if during the build all components get copied over into the published directories, so you could do something like this?

import CustomButton from 'our-design-system/components/CustomButton';
import 'our-design-system/components/CustomButton.scss';

Edit: I just found #111, and it appears to be talking about the same problems. If you need help implementing this, I might be able to check out some solutions

[arielsalminen]

@b12f This is definitely possible already now by tweaking the Webpack build configuration and by removing the auto importing of all components (in system.js: https://github.com/viljamis/vue-design-system/blob/master/src/system.js) and instead doing it in a way that will export every single component individually. You can find at least some pointers and instructions on this via google and by looking how other vue libraries export their components.

If you look at the system.js I linked above, you should see how it right now installs all the components globally. It would be neat to make this an option so you could choose how to do it. Could definitely use some help here as I’ve been rather busy lately with client work!

[b12f]

Thanks for the quick response! I'll set up a project and take a look whether it's good for our purposes, and if/how we can merge a code splitting option into vds. Have a nice day.

[ah3nry]

Hi @b12f and @viljamis I'm trying to implement this too. Any guidance would be appreciated. Cheers

[b12f]

To be honest I went another route and implemented everything by hand. There's a lot of queues I took from both this repo and vue-styleguidist, but it in the end both the handling of routes, as well as the overwriting of the vue-styleguidist styles felt clunky, and the config too big.

I ended up with a structure very similar to this (theo for tokens, vue-docgen-api for jsdoc comments), but in a fresh project utilizing the vue cli, which greatly reduces our config complexity. Our current setup doesn't prebuild the components at all when packaging, so we end up importing singular .vue components from the design system package where we need them.

This has some disadvantages, the biggest one being that because components are not precompiled we are constrained to using the most vanilla vue components, since we don't want consumers to have to add a lot of configuration to get things like jsx working. We've looked at two solutions for this:

• Getting precompilation to pure JS to work with babel and vue-template-compiler (this is what I'm planning to do)
• Distributing a babel preset together with the design system.

Other disadvantages:

• It's more work to roll everything yourself
• Stuff that vue-styleguidist used to do for you has to be redone. I've ended up writing about 160 lines of scripting around vue-docgen-api

Some advantages:

• Total control over the router for the documentation page; it's a normal vue app
• Free to set up as you like; We have markdown documentation that can directly include vue components with vmark, making the docs way more easy to edit and extend. We currently also have custom markdown fence rule to automatically insert highlighted code together with the code example.
• Large parts of the config are handled by the vue-cli

[nataliawww]

Is there anywhere to see your solution? :) @b12f

[b12f]

@nataliawww Unfortunately no. The product is closed source and I'm not at the company anymore. There's some stuff I would've done differently in hindsight, but a lot just depends on your usecase.

In any case, I really recommend vmark for vue-enhanced markdown, doing your own router for the docs so you can also easily document other stuff like language, patterns and principles in whatever page hierarchy you like, and having automatic docs generated from jsdoc, for example with the great vue-docgen-api.

Then depending on your usecase you might want e.g. a lerna monorepo with one package per component, and/or to separate scss from vue, and/or to distribute build configs, and/or to have a really good changelog and semantic versioning.