In Quasar, what can be considered a "page"
-
This is a noob question about Quasar with a not-so-noob thinking behind it. So, please bear with me.
What I’d like to know is, what kind of components can be “navigable”, meaning what component can represent a page within an app? My concern is currently manually having to add routes and I’m thinking along the lines of an automated routing system. So, if I get the answer to my question, I’ll see if I can continue my train of thought.
Scott
-
Sometimes a single component can be used for several pages (i.e. routes). That’s the beauty of routing
Do you know nuxt? https://nuxtjs.org/guide/routing -
Woah! Throwing me a curve ball, ey?
I’ve seen nuxt, but haven’t had anything to do with it directly.
Ok. You are right about the single component being possibly used for multiple pages, but in the end, there is always something used to key in the right content or child components to be used on each page, which uses that single component, right?
Scott
-
Sure, that “something” is the routing process if I follow you… A route is a path with its eventual query variations, so if for you a page is defined by its path then you can say a page is a route modulus the query. I’m not sure if that was the purpose of your question
-
Ok. But, routing is just a bunch of logical decision, right? Like, if “/” -> load the home page or if “/blog” -> load the “blog” page, etc. etc. You might also have some sort of parameters too, which also means some sort of handling, which are also always decisions. In fact, the parameter handling decisions are also “pre-decided”.
What I’m considering is a routing system, which is convention driven and not a set of decisions written in code. For instance, if you have the convention of following a certain file system pattern, then you only add the files. The routes are, thus, automatically created. You don’t have to touch the router.
I am just wondering if it is worth the effort and will be flexible enough.
Scott
-
In my case, I use my routes definition array for many things.
For example, I require() it in
webpack.prod.confto list all the possible absolute static paths, and pass them to PrerenderSpaPlugin during build time. So whenever I create a new route I don’t have to worry about forgetting to add it to the PrerenderSpaPlugin config.I also use the
metaproperty to declare some navigation bar specific to a route.I will eventually use it also to give a unique name to several similar paths, so vue-analytics know it can pass them as a unique path to Google Analytics.
I’m also happy that I can $router.push() to a route’s name, so if i decide to edit this route’s path, I don’t have to worry about correcting the path in many places in my app.
Maybe all of this is specific to my app, but I personally don’t see any reason to avoid the routes declaration
-
Those are all great examples of decisions you’ve made. And currently the routes you are creating are results of those decisions - for each and every page your app needs. The routes or routing logic are not the decisions themselves.
What I am thinking about is to program the decisions themselves, which are then decided upon by following certain conventions. In other words, if you do something a certain way, the routing system automatically knows how to route, because of that. Could you imagine your scenarios in that kind of format? What you posted would be a great start to all the decisions such a routing system should encompass.
I realize that means opinionation (but we are talking about a framework, which is always opinionated, right?), but it also means simplicity, once the conventions are known to everyone. It would mean never having to touch routes at all, but rather just learning the conventions and following them.
It would also help solve the often posed question, “How should I structure my very large SPA?”. If we program in the decisions for the client developers into the routing system, they don’t need to make them, they just do what is needed, according to the conventions. Not sure that is at all a good thing, but for beginners and intermediates and lazy devs, it certainly is. LOL!
In other words, to me the routes system as it is, is just a big configuration file. You could easily create YAML for what the routes stand for and compile it all together at run time to the routes system, as it is. So, I am suggesting this configuration can be replaced by conventions, which I believe is the better way to program.
Convention over configuration, right?
Oh, and I’d leave this as an alternative routing plug-in. So, that would basically side-step the opinionation concerns. (But, I am of the opinion, that this kind of opinionation is always the good kind.
)Scott
-
I need to expand on why I think this kind of opinionation is good.
Think about all the devs using Quasar all creating the code for routes, which are results of their decisions. Surely, there is a ton of duplication, which means wasted effort.
Now imagine, this coding of decision results is taken away from them all. Surely, your argument would be, “but now their hands are tied.” And you’d be right.
However, now they would come to a central place and add their missing and needed decision to the code of the router (or ask for it). Being the decision is programmed -> BAM!, then every other of the 1000s and 1000s of devs using Quasar (I’m looking into a prosperous future) also get that feature too, instead of them all possibly reinventing that wheel.
I also realize this is where software bloat comes from too. So, this convention over configuration game is always a double-edged sword. But, a routing system is simple or modular enough, that bloat shouldn’t really be a big concern.
Scott
-
Hey all. I am finding myself swaying back and forth on the fence thinking about these subjects… static sites generators vs pre-rendering. Can I throw another curveball and ask for what you all make of Netlify’s note in their pre-rendering docs? https://www.netlify.com/docs/prerendering/ and the need for it.
PS. I’m also on the fence on picking a site generator, Hugo seems the top performer ( and powerful ) which is likely a deal maker. I’ve wondered a bit how one might painlessly combine Quasar and Hugo in a workflow. You all mention Nuxt and I like the sound of sticking with Vue since go templates are quite different. Performance is a must though, at least for one of the site I am considering it for. If pages get into the hundreds of thousands, thats a lot of generating. I thought I’d toss this in incase you may have a comment on this.
-
@smakinson Hugo (that I use) is great, but it is “only” a static website generator. Pages created with Hugo do not use a database so you can drop them directly into a webserver such as NGINX to get maximum performance.
Nuxt (that I never used) creates full dynamic web apps, with things like SSR and routing generated automagically (if I’m right). -
It’s an old topic, and I am much more knowledgeable since then, especially on Quasar.
The good news is, SSR is in the plans for Quasar, so have patience. Some exciting stuff coming up in this realm, should the assessments work out positively, which seems like they will.
Scott
-
Thats good news. Quasar is one of the most interesting things I have come across in a quite a while and I have some great results so far. Do you have experience with Netlify’s pre-rendering? If so, do you find it sufficient for now?
-
Sorry, no experience here.
Scott
