@dobbel said in Which backend for Quasar ?:

For Meteor I used this starter kit to show me the way:
https://github.com/alexandesigner/quasar-meteor
It’s a bit outdated but still works ( with some minor tweaks). I today locally created a new app with this repo and updated it to the latest Qv1 and Meteor V2. If you’re interested in using Meteor I could share this up to date starter kit.

@dobbel
I would be interested in a starter-kit based on Quasar CLI and Urigo’s meteor-client-bundler with … explanations, since I never quite managed to understand Alexandesigner’s.

Among other confusing stuff:
a) The commands to create the project do not mention neither meteor nor quasar

b) The code in quasar-meteor/api/client/main.js/ contains Blaze code; why should it be needed it if the client is made of Quasar/Vue components?

c) It does not use the standard meteor-vue integration packages [https://github.com/meteor-vue/vue-meteor](link url) and therefore it does not use the meteor vue option provided by these packages, but rather calls meteor code by using a $meteor special variable anywhere in the Vue view (e.g., method option, created hook).

Any clarification on all those points would greatly help.

Hi,

I stumbled upon this great thread yesterday after googling for “meteor vue quasar”.

The example quasar/vue/meteor app in https://github.com/quasarframework/quasar-template-meteor seems like a great starting point for a noob like me trying to evaluate the potential of this QVM stack with single file Vue components.

However, it raised the following questions concerning this QVM app structure and that recommended in the Quasar doc.

Let’s start the quasar-meteor template app structure:

1. Why are the routing code split into a
   client/main.route.js file and a
   imports/route.js file
   instead of being in a single
   imports/startup/client/route.js file
   as in the meteor guide app structure?

2. Why is there a client/main.css file
   instead of an app.variables.styl file
   that could perhaps be put in
   an imports/ui/theme folder
   or in an import/ui/layout/theme folder to follow the meteor guide app structure?

3. Why is there an empty imports/startup/client/index.js file whereas the client startup code is put in the client/main.js file?

Now concerning the quasar app structure, why having a separate
src/themes/app.variable.styl file
instead of putting the stylus customization code inside a
<style lang=stylus><style> tag in the
src/App.vue root component to follow the single file Vue component philosophy?

Thank you very much in advance!

@damiendeville said in Which backend for Quasar ?:

c) It does not use the standard meteor-vue integration packages [https://github.com/meteor-vue/vue-meteor](link url) and therefore it does not use the meteor vue option provided by these packages, but rather calls meteor code by using a $meteor special variable anywhere in the Vue view (e.g., method option, created hook).

@dobbel
Thinking more about it, I guess those vue-meteor packages are needed to let the meteor build tool recognize the .vue files and the lang=pug, lang=ts, lang=stylus and such attributes in the .vue files and call the appropriate transpilers for each piece of code inside those .vue files.

Now if one creates an app using the Quasar build tool, it does all this source code analysis, transpiling and build stuff out-of-the-box and therefore there is no need to use those packages and thanks to the meteor-client-bundler any function of the meteor object can be called anywhere in the Quasar client app instead of being circumscribed to the meteor vue option created by the vue-meteor-tracker package.

Hence, all this hard work by the 25 contributors of the vue-meteor project is only needed when one creates a Quasar-Meteor stack project as a Meteor app using Quasar as front-end but if one creates a Quasar-Meteor stack project as a Quasar app using Meteor as back-end all is needed is the meteor-client-bundler module.

Is that correct?

@dobbel said in Which backend for Quasar ?:

For Meteor I used this starter kit to show me the way:
https://github.com/alexandesigner/quasar-meteor
It’s a bit outdated but still works ( with some minor tweaks). I today locally created a new app with this repo and updated it to the latest Qv1 and Meteor V2. If you’re interested in using Meteor I could share this up to date starter kit.

@dobbel
I would be interested in a starter-kit based on Quasar CLI and Urigo’s meteor-client-bundler with … explanations, since I never quite managed to understand Alexandesigner’s.

Among other confusing stuff:
a) The commands to create the project do not mention neither meteor nor quasar

b) The code in quasar-meteor/api/client/main.js/ contains Blaze code; why should it be needed it if the client is made of Quasar/Vue components?

c) It does not use the standard meteor-vue integration packages [https://github.com/meteor-vue/vue-meteor](link url) and therefore it does not use the meteor vue option provided by these packages, but rather calls meteor code by using a $meteor special variable anywhere in the Vue view (e.g., method option, created hook).

Any clarification on all those points would greatly help.

@dobbel I always found this starter-kit https://github.com/alexandesigner/quasar-meteor puzzling since it:

• It seems to use two different front-ends, Blaze and Quasar (why would one do that?)
• It also uses axios which seems simlarly redundant with Meteor pub/sub through DDP

Could you explain why you chose this one rather than https://github.com/quasarframework/quasar-template-meteor?

I know it also confusing since:

• The top-level app structure does not conform to the Meteor guide app structure
• Nor does it conforms to the folder structure of the example in the Meteor-Vue guide Vue | Meteor Guide (which BTW also does not conform to the Meteor guide app structure to add to the confusion)
• Nor does the folder structure below template/imports/ui to the folder structure below /src in the Quasar app structure guide App Structure - Quasar Framework

but even though I found it bit less obscure than alexandesigner’s.

Thanks!

@damiendeville Partial self-answer here. I almost managed to customize the q-input component styling to my local needs with the following code:

<style lang="stylus">
.q-input
  height 2.5em

.q-if-label
  text-align right
  color orangeRed

input[type="number"]
  height 1em
  color purple
  text-align right 
</style>

However, I still do not understand why I needed to add the [type=“number”] to the input selector to access the input element inside the q-input element.

But this code is not really legible, since neither the q-if-label component nor the input elements encapsulated in the q-input element appear in the vue template that this stylus code is styling. Is there any way to customize the appearance of a quasar component other than selecting in stylus sub-components and sub-elements internal to the component hence in effect breaking its encapsulation and making the code incomprehensible without inspecting the component 's internal DOM with a browser debugger?

Also, I tried to add an ellipsis to the placeholder and the following code just didn’t have any effect:

input[placeholder]
  text-overflow ellipsis

Any suggestion on this one?

Noob here trying to apply some CSS to the <input> element inside a
<q-input> element.

By adding:

<style lang="stylus" scoped>
input
  text-align right
  height 32px
  color purple
</style>

to the element containing the <q-input> element, I manage to move the entered input text to the right. But it does not alter neither the color of the input value nor the height of the input field to accommodate for the large font size inherited from the parent component without cropping it.

What I am doing wrong?

And also what is this sp unit used in the typography section of the Quasar doc? I don’t find it the w3school CSS reference

@damiendeville Now the fact that the Meteor app code must be placed below a template folder is problematic with correctly setting up the launch.json file to simultaneously debug the client and server code in VSCode.

Having added the launch.json file found here: https://github.com/Microsoft/vscode-recipes/tree/master/meteor,
when launching a debugging run with VSCode, I get an error with the following complaint:
no package.json file found in <workspaceFolder>.

Since the package.json is in fact in <workspaceFolder>/template due to the installation of meteor inside this subfolder
I have tried to change the option:
“webRoot”: “${workspaceFolder}”
to
“webRoot”: “${workspaceFolder}/template”

Then I tried to move the package.json file to <WorkspacePath> but it broke my meteor app build.

Could anyone using this VSCode recipe for Meteor help figure out how to alter it so that it manages to find the package.json file below the template folder?

@damiendeville I found answer to the first question here: https://github.com/vuejs-templates/webpack-simple/issues/29
In short, this mysterious h is an alias for the createElement Vue function that creates a new node in the DOM. It apparently is an compulsory argument to the render lambda that the render option of a Vue instance is expected as value (why it needs to be passed as argument instead of just called inside the render lambda I still don’t get it)

So
h => h(AppLayout)
is just an abbrevation for
createElement => createElement(AppLayout)

Now if you want to stay at the highest possible level of abstraction and hence would like to avoid using render functions, you can substitute the option:
render: h =>h(AppLayout)
by the two options:
template: ‘<app-layout/>’
components: { AppLayout }

BUT, this will only work if you import the development versions of Vue and VueRouter that include the template compiler instead of the production versions that exclude it and thus require the use of a render function.

Hence your imports:
import Vue from ‘vue’
import VueRouter from ‘vue-router’

must be replaced by:
import Vue from ‘/node_modules/vue/dist/vue.common.js’
import VueRouter from ‘/node_modules/vue-router/dist/vue-router.common.js’

I am trying to leverage the great help that the Meteor-Quasar starter kit provides to assess the practical usability of the Meteor-Vue-Quasar tech stack to develop apps. But as a Vue and Quasar noob, I am struggling to understand parts of it in spite of the nice comments that it contains.

1. Line 34 of the template/client/main.js file
   render: h => h(AppLayout)

what is this h that I cannot easily find referenced anywhere else and what does it do? Is it a function? Where does it come from? I am guessing that it somehow injects the AppLayout component inside the root app component that is being created by the New Vue expression that starts on line 32 but I don’t understand the syntax.

Another related questions is:
why create the top-level app component as JavaScript code of a Meteor.startup function that injects the AppLayout component using a render function in this root component instead of, say, adding an App.vue component in the template/imports/ui/ folder that would look something like:
<template name=“app”>
<app-Layout></app-Layout>
</template>

<script>
// put the router instance creation code here instead of in the Meteor.startup //function
<script>

Would such declarative approach also work? If not why?

2. There is a NotFound.vue component in the templates/imports/ui/ folder but I do not find any route to it

3. I still do not understand why the folder into which to put the Meteor app code and run it (to avoid interference between the meteor build system which does not use webpack and the Quasar build system that does) needs to be called “template”. Is this a reserved Quasar word? If so where is the doc explaining it. I assume it has nothing to do with the “template” Vue reserved word to use as tag surrounding Vue’s html generation template code in the single file Vue components, but if it is the case, it is a confusing choice by overloading the same word “template” with two distinct meanings

@mwarren2 said in Meteor!:

@damiendeville said in Meteor!:

Do you mean that this ‘template’ is needed only because running the meteor CLI in the application root folder would somewhat not work? But why? Since you did not use the quasar CLI nor webpack, what is the problem? Also is the name ‘template’ arbitrary?
Could it be called ‘foo’ or ‘meteor’ and it would still work properly?

It has to be called ‘template’. That’s all I know.

@rstoenescu perhaps you could explain?

@mwarren2 said in Meteor!:

I was asked to add the root ‘template’ folder by quasar’s creator - presumably one day it would be good if it fitted into the quasar starter-kit system, but at the moment I don’t think this is possible - maybe one day when Meteor can simply be installed from npm, if that happens.
For the moment you should simply ignore the template folder and change directory into it and run the usual meteor commands from there.

Do you mean that this ‘template’ is needed only because running the meteor CLI in the application root folder would somewhat not work? But why? Since you did not use the quasar CLI nor webpack, what is the problem? Also is the name ‘template’ arbitrary?
Could it be called ‘foo’ or ‘meteor’ and it would still work properly?

I also do not understand the need for transpiling. You say:
Then here we transpile two es6 .js files (one for ios, one for material design) to commonjs which meteor needs
What are those files to transpile, where are they located in your project and you are talking about transpiled from what source langage to what langage? I thought Meteor was written in and supporting es6.

Thanks again for further clarifications