Most basic Meteor + Vue Setup boilerplate

announce
1

On request, I’ve created a minimalistic boilerplate of Meteor with Vue to show how easy it is to get started with Vue in Meteor.

9 Likes
2

Thanks! I think a lot of developers underestimate how useful such a minimalistic repo can be for people that have just started out and need to get some footing to at least get the ball rolling. Much appreciated.

By the way, it would probably be good to mention Vue in the title here as well.

2 Likes
3

What title do you mean? Did I miss it somewhere? It is in each title I can find

4

A while back the title of this thread did not have Vue in it. Now it has appeared, so you probably found it. Or somebody else added it. In any case, all good now :slight_smile:

1 Like
5

@cloudspider, you’re already done a lot, but perhaps we can coerce even a little more out of you. I think what would be super useful for novice developers would be if you’d now duplicate the above repo and make a couple of others with just a slight bit of code added to the original in each:

  1. meteor-vue-minimal-router - here a router is added to the original with just 2 or 3 example routes (so just importing the router from npm and a file added with route config and couple pages)
  2. vue-meteor-minimal-methods - based again on the orignal, here the one single component has one method to load data from server and one method to write data to server (and perhaps some test data generation in a separate file)
  3. vue-meteor-minimal-pubsub - based again on the original, here the one single component has a subcription and reactively displays some very basic test data from it (like names of students). Would probably make sense to have the test data be generated on startup.

I think these 3 repos on top of the original would take a beginner’s hand and walk them through most of Meteor’s basics in a very approachable way. Since the repos contain a minimal amount of code, the reader can easily see what gets added to the original boilerplate for new features. And also I think drawing a clear line between the ‘methods’ repo and ‘pubsub’ repo is beneficial to briefly illustrate that these are two very different things (something that I think a lot of beginners seem to struggle with).

There is an argument to be made that perhaps these could be just different branches in the same repo or committed some other way to the same one to use github’s built in diffing. But I think keeping them just as seprate repos and just mentioning each one in the readme as steps 1, 2, 3, 4 to Meteor/Vue mastery would be best. Since the beginners would likely not be very used to git tooling and the amount of code is minimal.

Regardless if you have the time to take this on, thanks for your efforts this far.

1 Like
6
  • Agree with points 1. and 3. since most people will make use of these.
  • As for 2. (methods), how is that different in Vue? I do not think that this is needed…
  • If we need to replace 2. with something else, maybe integrating with a GUI library (Vuetify?)… Or maybe this is an overkill?
1 Like
7

I’d say it’s needed because it’s core Meteor and people unfamiliar with what vue is (and isn’t) don’t know it’s the same in Vue.

If the purpose is to get Meteor developers familiar with using Vue with Meteor, nothing wrong with a boilerplate that shows you that using methods works the same way

1 Like
8

I think for a beginner it would be rather important to see the process of taking some data via a Meteor method and dropping it into a Vue component’s state. It’s not at all self explanatory how these bits and pieces fit together (where to fire Meteor.call() and where to save the data etc). A beginner may not even realize that you’d need to use Vue’s own state here. So I’d have to respectfully disagree on this one. Of all the examples, this is probably the most important one.

1 Like
9

Concede… More examples/scenarios are always better. I can see where for people not experienced with Meteor this could be good.

1 Like
10

Most of that was already in the pipeline. I like the idea of basic routing etc added. And I was already building the Meteor method one. :slightly_smiling_face:

1 Like
11

Great! But if at all possible, I’d say resist the urge to lump them all up in one repo. Keeping those 4 in separate codebases with a descriptive name for each repo is a couple of more key strokes for you, but it’ll help the average beginner a lot. I think. So when there’s a question in the forums on some topic, people can just provide the relevant repo URL on top of their answer.

Ok, I’ll shut my pie hole for now. For somebody doing absolutely none of the work I seem to have a lot to say about stuff :slight_smile:

12

Nice that’s exactly my thought. I regretted that decision for my React / Preact boilerplates aswell :stuck_out_tongue:

Ok, I’ll shut my pie hole for now. For somebody doing absolutely none of the work I seem to have a lot to say about stuff

I disagree. I’m active on this forum for quite some time now and had and still have questions of my own. HAck I was and am even one of those guys placing comments into the “Thinking about Meteor 2.0” topic. So please don’t stop. This is much better then going in on just my own gutt feeling about what the ‘potential’ community is expecting. I hate wasting time and that’s also one of the reasons I chose Meteor :slight_smile:

2 Likes