Suggestion/Feedback from a NEW user's Perspective!

Ben Hayat

Hello Team;

I have been a software developer for many years, but new to Vue and Quasar. For any new platform, I try to learn the platform’s patterns, best practices and approach the development in that direction. This saves times, mistakes and allows a better communications with others.

As I started Vue, took some courses from experienced developers, read Vue’s docs and samples and got a feel for the platform. Then looked at a few third party UI tool kits, and noticed they also follow the same pattern with building apps. So you feel at home (as a new user).
Now I’m in Quasar and trying to start my journey of implementing it into my app. My first encounter was the naming of “Starter Kit” which didn’t fit into the culture of Vue. I made some suggestions, and with the help of Scott, the docs are being changed to Quasar CLI. Great!!!

The next stop was to build my first app using Quasar CLI and after getting the project up & running, I noticed something that prompted me to write this feedback.
When I had looked at other Vue apps, they all followed the pattern of using index.html in the public folder, App.vue and main.js in the root of project.
The important element, is the entry point, the “main.js” where certain additional codes might need to be added for different cases, i.e. using Firebase Auth or calling a backend service to get User’s Data, BEFORE the app is created and mounted and etc. All samples follow this pattern.
However, when I looked at Quasar’s project, I don’t see “main.js”. There is a Quasar folder with some files generated by CLI which should not be edited, and one is considered to be the entry point, but not the same naming convention of “main.js” and a totally different scheme to add additional codes to the entry point (which as of now, I’m still unclear how to").

And this brings me to this this feedback & suggestion

It’s best to stay with the convention that Vue has set, i.e. using “main.js” as entry point, so NEW users don’t freak out and walk away from Quasar, as they don’t find it the same as others.
secondly, if Quasar framework requires such changes to the convention, there should be CLEAR instructions in the docs that guides the user how to switch from Vue’s conventions to Quasar’s conventions. This is a very important addition to get the NEW users up and running and making sure they are not lost in the early stage of adoption.

Sure, it’s all easy for an experienced Quasar developer, but we want to make Quasar adoption as easy and seamless as possible to get new people in.

I hope my suggestion will help to expand the current and future docs to get NEW users in and up & running.
And meanwhile a pointer on how to expand the entry point would be appreciated.

Hope this helps!

Hawkeye64

Actually, Quasar does follow this pattern. You have to build the project first (quasar dev or quasar build). You will see in the dist folder, there is now index.html and in the js folder, there is app.[*].js (which is your Vue entry-point file). The js extension is what webpack is doing for you on all those files in the js folder.

Ben Hayat

@hawkeye64

I’m talking about my Dev time project, not deployment/Distribution. Here is my a screenshot of my dev and all the files in Quasar folder are generated.
But in Vue development, we get main.js that we can enhance it further. Please read my post more carefully, as I stated all the details.

alt text

s.molinari

Hi Ben,

The file structure is what it is, because you are now within a framework, or rather a level of abstraction (or two) above Vue. And as such, Quasar has its own “predetermination” or “opinionation”. Basically, the idea with quasar is to offer a low barrier to start with.

This is what is mentioned about the structure of the files in the docs.

If you are a beginner, all you’ll need to care about is /quasar.conf.js (Quasar App Config file), /src/router, /src/layouts, /src/pages and optionally /src/assets.

In other words, you just have to start designing your app and don’t overthink what is happening in the background (at least not at first). Quasar will take care of what you are needing to think about for you.

Scott

Ben Hayat

@s-molinari

Thanks Scott;
Your point is well taken and I’m trying to go along with it.

So perhaps you can answer this question for me.
In regular Vue App, we have the main.js as you see in the screenshot below, before we instantiate the Vue object, we have to check Firebase’s state (To login user async) BEFORE we can instantiate the Vue obj.

But in Quasar built apps, we get another file called app.js in Quasar folder that does what main.js does, except, this is auto generated and should not be edited.
So my question (which I can’t find in docs), where do I add codes in the entry point like we did in main.js??

Thanks!
alt text

Hawkeye64

@Ben-Hayat Ok, so I misread…I followed the herring instead of the bigger fish.

I think what you are looking for is a Quasar plugin:
https://quasar-framework.org/guide/app-plugins.html

Examples of plugins I use:

import AnimatedVue from 'animated-vue'

export default ({ Vue }) => {
  Vue.use(AnimatedVue)
}

import axios from 'axios'

export default ({ Vue }) => {
  Vue.prototype.$axios = axios
}

// batman's utility belt for javascript
import _ from 'lodash'

export default ({ Vue }) => {
  Vue.prototype._ = _
}

import moment from 'moment'

// leave the export, even if you don't use it
export default ({ Vue }) => {
  Vue.prototype.$moment = moment
}

// form validation
// See: https://www.npmjs.com/package/slug this project is dead
// now using dodoslug, a fork of node-slug
// See: https://github.com/dodo/node-slug
import slug from 'dodoslug'

slug.defaults.modes['mymode'] = {
  replacement: '-', // replace spaces with replacement
  symbols: true, // replace unicode symbols or not
  remove: /[._]/g, // (optional) regex to remove characters
  lower: true, // result in lower case
  charmap: slug.charmap, // replace special characters
  multicharmap: slug.multicharmap // replace multi-characters
}
slug.defaults.mode = 'mymode'

export default ({ Vue }) => {
  Vue.prototype.$slug = slug
}

Ben Hayat

@hawkeye64

A common use case for Quasar applications is to run code before the root Vue instance is instantiated.

That’s exactly what I was looking for. Thank you Sir!

Hawkeye64

Glad to have helped.

s.molinari

Yep. quasar-conf.js is a perfect example of that layer of abstraction higher above Vue I was talking about.

I’m thinking about how getting started as a beginner can be more clear in the docs. I mean quasar init my-project is pretty simple, but where to go from there for a beginner isn’t really given as a clear “guide”. I also think overall concepts about the abstraction that probably most experienced Quasar devs take for granted are also not really clear and need better explaining.

Let me give it some more thought over the weekend.

Scott

Ben Hayat

@s-molinari
Scott, more docs to make things more transparent, are always welcomed.

Basically, a workflow of things, after the Quasar CLI has created the project. What those extra files are for. Basically, explanation on anything that Quasar adds on the top of Vue CLI that NEW users are NOT familiar with.

By disclosing those info and explaining the DIFFERENCES (A table would be nice to show Vue vs. Quasar), and we can immediately see, for example, Vue uses main.js and it is editable but Quasar uses app.js and requires plugins. Then what and how plugins are wriiten and used.
This way, new users can see things more clear than it is now.

Hope this helps.

Hawkeye64

@Ben-Hayat Forgot to give you the plug-in information (above) for quasar.config.js:

module.exports = function (ctx) {
  return {
    // app plugins (/src/plugins)
    plugins: [
      'animated-vue',
      'axios',
      'download',
      'lodash',
      'moment',
      'slug'
    ],

Ben Hayat

@hawkeye64
Thanks Bud!

colinm

@s-molinari wrote:

I’m thinking about how getting started as a beginner can be more clear in the docs.

I think a larger set of example plugins like those that Hawkeye64 gave would be very beneficial. There is an “examples” section in the docs but it doesn’t have actual code examples and is pretty thin.

Also the Directory Structure page lists “plugins” in the directory tree but I think this deserves more prominent mention since one of the first steps in a real project is often going to be integrating a few third-party or internal libraries. The nomenclature of “plugins” can be a bit deceiving since they also can serve as a more general-purpose initialization (vs Quasar-specific plugins which I first thought they were) which the docs author even acknowledges because the “(app initialization code)” in parentheses is added beside the “plugins” directory.

So for example the sentence:

If you are a beginner, all you’ll need to care about is /quasar.conf.js (Quasar App Config file), /src/router, /src/layouts, /src/pages and optionally /src/assets.

Could be augmented with mention of plugins:

If you are a beginner, all you’ll need to care about is /quasar.conf.js (Quasar App Config file), /src/router, /src/layouts, /src/pages and optionally /src/assets. Custom initialization code in Quasar is handled via “App Plugins” rather than the typical Vue convention of editing main.js.

Keep up the great work, Quasar team!

s.molinari

@colinm - If you could, make a PR to improve the docs with your suggestion.

Scott

s.molinari

BTW, I’m working on a blog series to help newcomers to dive into Quasar faster. The topic of this thread will also be covered in that series too. This tutorial blog series is currently planned to be released around the time 1.0 is released and will be released in, most likely, weekly installments.

Scott

digiproduct

@s-molinari Did you ever create the blog series for newcomers? I just discovered Quasar yesterday, and would be interested in reviewing a newcomer blog series.

s.molinari

@digiproduct - No. Unfortunately not. How well do you know Vue?

Scott

digiproduct

I know Vue a little … enough to be able to use it relatively well in Laravel … but don’t consider myself an expert by ANY means.

I’m simple awe-struck by the Quasar Framework, and want to start using it, and would love to follow some sort of best practices series to make sure that I begin in the best possible way. I’m busy looking at lots of forum messages and sample code at the moment before I even attempt to try my first installation of Quasar.

digiproduct

@s-molinari I just managed to find some tutorials, and I’m about to work my way through them …

https://github.com/quasarframework/quasar-awesome

s.molinari

I’d like to suggest you go through this Udemy course. https://www.udemy.com/vuejs-2-the-complete-guide

If you got that under your belt, getting deeper into Quasar will be much easier. It’s basically then just learning what the CLI offers.

Scott

No More Posting New Topics!

Suggestion/Feedback from a NEW user's Perspective!