No More Posting New Topics!

If you have a question or an issue, please start a thread in our Github Discussions Forum.
This forum is closed for new threads/ topics.

Navigation

    Quasar Framework

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    [Solved] What is the impact on many globally available custom components?

    Help
    4
    10
    214
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Q-Brad
      Q-Brad last edited by Q-Brad

      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:

      b000caee-7971-4708-91e4-d03bc836f37c-image.png

      This references a components.js file which registers 100+ components as in this example (abbreviated):
      5421eac7-1d32-41ab-8b6a-8fe84d924136-image.png

      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?

      qyloxe metalsadman 2 Replies Last reply Reply Quote 0
      • qyloxe
        qyloxe @Q-Brad last edited by

        @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.

        1 Reply Last reply Reply Quote 0
        • Q-Brad
          Q-Brad last edited by

          @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.

          qyloxe 1 Reply Last reply Reply Quote 0
          • qyloxe
            qyloxe @Q-Brad last edited by

            @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 🙂

            1 Reply Last reply Reply Quote 0
            • metalsadman
              metalsadman @Q-Brad last edited by metalsadman

              @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.

              1 Reply Last reply Reply Quote 0
              • Q-Brad
                Q-Brad last edited by Q-Brad

                @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. 😁

                1 Reply Last reply Reply Quote 0
                • beets
                  beets last edited by beets

                  @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

                  1 Reply Last reply Reply Quote 0
                  • Q-Brad
                    Q-Brad last edited by

                    @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.

                    metalsadman 1 Reply Last reply Reply Quote 0
                    • metalsadman
                      metalsadman @Q-Brad last edited by metalsadman

                      @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’s magic comments https://medium.com/front-end-weekly/webpack-and-dynamic-imports-doing-it-right-72549ff49234.

                      1 Reply Last reply Reply Quote 0
                      • Q-Brad
                        Q-Brad last edited by

                        @metalsadman Thanks! I’ll check them out.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post