[Solved] What is the impact on many globally available custom components?
-
I have about 100+ custom UI components for my website. Instead of having to import many of them on each different page on the site, I’ve basically imported them all via the [boot] section in quasar.config.js. Notice the ‘components’ section in quasar.config.js in the image below:
This references a components.js file which registers 100+ components as in this example (abbreviated):
I’ve been wondering, is this a good way to do this? Is there an impact on the initial application load?
Again, all of this is an exercise in not having to include all sorts of import statements into each SPA page that uses different components.
Is there a better way?
-
@Q-Brad well, developer tools is your friend. Especially tabs: network , memory and performance. You need to build and app with static components, test, then build app with dynamic components and test again. Then you can compare test results and decide what you want most - the fast loading time, fast first presentation or maybe even something else.
-
@qyloxe Soo… your answer is basically to say that you don’t know the answer, and that I should just go figure it out myself - which I have been attempting to do using developer tools - and that I shouldn’t bother asking if any of the many knowledgeable developers here have had any experience on the subject. Nice.
-
@Q-Brad said in What is the impact on many globally available custom components?:
@qyloxe Soo… your answer is basically to say that you don’t know the answer, and that I should just go figure it out myself - which I have been attempting to do using developer tools - and that I shouldn’t bother asking if any of the many knowledgeable developers here have had any experience on the subject. Nice.
Nope. I showed you the METHOD of getting a precise answer to your question. Any other answer of type “do this or do that” would be guessing and wasting your time. Test, measure, compare - that is the proper answer. Why? Oh, that is another question
-
@Q-Brad https://forum.vuejs.org/t/performance-penalty-of-global-component-registration/56655
Reddit says there will be a perf impact (no tests made) but it’s for you to decide to weigh in the tradeoffs, if you don’t register global reusable components then you’ll have to deal with import boilerplate code where they are used, especially if you’re gonna use the components numerous times. 100+ global components do sound a lot, personally I only register those that I will use heavily, usually form components.
-
@metalsadman Thanks for the response. Yes, this is basically my conclusion as well. And you’re right, 100+ components is a lot, hence the reason for the question… but in the end, you’re probably also correct - I should probably just globally register the layout/form components that are used 80% of the time or more, and just deal with the annoyance of having to do multiple imports on most pages. I guess I got spoiled (and a bit lazy) by having the ability to globally register.
-
@Q-Brad you really do have to use the webpack analyzer, but what I’ve found is that if you use the same component is more than one chunk, is that it will be imported into the common chunk. You can control that via the min chunks webpack config option. But even better, is you can control what chunks components go into with the special require syntax (it is based on comments) and try and optimize it based on the general sections of your site. For example, I try to bundle all the customer dashboard chunks into a separate “customer.js” chunk, since not logged in users, and especially google, don’t need them. In my most recent project, I don’t require components gobally, where I used to do so. Instead I use the special require syntax in my routes file, and let webpack decide when to use the common chunks file, and sometimes specifically split a 3rd party component into its own chunk.
Edit: a word
-
@beets Hmm… that’s very interesting, and potentially very helpful. Thanks for that input. Would you happen to have an example of how that works somewhere in a github repo or something? It would be great to be able to see an example visually.
-
@Q-Brad this article discusses about that https://www.binarcode.com/blog/tips-for-building-lighter-and-more-performant-vuejs-spa/ .
it’s using webpack’smagic comments
https://medium.com/front-end-weekly/webpack-and-dynamic-imports-doing-it-right-72549ff49234. -
@metalsadman Thanks! I’ll check them out.