8 Likes
Good job @cloudspider, I really like the format of this video, it is on point and concise and very well presented, I’d love to see more of those on different topics. 
I’m impressed by how clean the Meteor/Vue integration is, I will start playing more with it.
2 Likes
Great work @cloudspider 
It’s fun to see videos on Meteor + Vue, I think this will help so many Vue devs come and try Meteor.
And it’s very exciting to have the new create meteor --vue command coming in Meteor 1.10.3, great job on that!
One video that might help many Vue devs trying Meteor for the 1st time, would also be the use of a Meteor.callPromise() inside a Vue Method for when someone doesn’t need Pub/Sub reactivity 
For new Meteor users, this might not matter much, but some people end up using Pub/Sub for everything and we could help them learn about thes async Methods calls (aka Meteor.callPromise) from client to server to get some data.
Keep up the great work! 
And thanks to @akryum for these great base Vue + Meteor packages 
1 Like
Yea was thinking to go apeshit with the datalayer now. Show how to use Meteor as BFF for Nuxt and how to use methods in different ways including the promised ones
2 Likes
That all sounds awesome & fun!! 
Rock & Roll!
I was on the Official Meteor YouTube page last night and watched this video from 2015 that really does an amazing job of explaining why Meteor is so important for the JS community.
I really hope the JS devs of planet earth 
can eventually realize the bigger picture vision, what they’ve been missing out on.
Almost exactly 5 years have passed since this time, but the case for Meteor is even more obvious today than ever before.
Digging into Meteor’s internals has also really given me a tremendous amount of respect for everything that’s happening under the hood to make my dev life so easy 
If we can get just 1 million or so devs from Vue & React communities to take a look at Meteor again, I think we’ll all live in a much more productive world.
1 Like
Also a big thanks to @gschmidt for the great vision in the 1st place and @benjamn for the massive amount (aka majority) of code written to make Meteor what is is today!!
Also, a big thanks to everyone who has ever worked on and/or contributed to Meteor along the way. I’m excited for Meteor to grow to its properly deserved level of appreciation in the JS community. 
This will probably come from the many new Meteor users who eventually become contributors and enthusiasts. Something that only happens after they try Meteor and take a little time to understand the “Meteor Magic”.
1 Like
@cloudspider - thanks for the video and I love your Dutch accent (ik heb in Nederland gewerkt), missed that.
Would you recommend the method shown in your video (with just integrating those two packages) for everyone who wants to start moving their Blaze UI elements over to Vue?
How about this package https://github.com/karol-f/vue-custom-element ?
I really would like us to get away from Blaze and on to Vue but as both need to co-exist for a while (eg. new UI elements should be done all in Vue and no longer in Blaze, existing ones should be switched over when time allows) there’s a “best practice” guidelines missing in the Meteor Vue guide (https://guide.meteor.com/vue.html).
1 Like
Oh nice haha. Where did you work?
Yes since this will be maintained by me and @akryum will help with the v3 integration soon
I would recommend that package if your focus is web-components. Some people argue that this would be more future proof since its framework agnostic. Big companies like ING have web components as their foundation.
In practice however you will need to reinvent a lot of things like SSR, but also you cannot leverage all of the features of a framework like Vue or React. See web components as the layer below vue (more verbose, but less dependent)
In your case you mention you want to switch to Vue and use Meteor’s reactivity system. In that case I would 100% use akryums packages, but only the vue-component package at first in combination with vue-meteor-tracker. Use Vue’s default router and all the other packages. I would not recommend akryums SSR package. Its going to be deprecated (want to stick as much as possible to the Vue ecosystem for the Vue layer)
Good one. I will take it into account as one of the todo’s after I manage to finish the new version of the Vue Meteor guide. That would be something like “Migration from Blaze, React” or whatever
1 Like
Maastricht, with Vodafone. Lived in Belgium though (as all the other rich Dutch lol)
Thanks a lot for that. Your contributions will make Meteor more attractive to other developers. Vue and Meteor is a very powerful and easy to use combination IMO.
1 Like
The GF of my best friend lived close to Maastricht. I remember us always getting kebab just across the border 
Great to see Vue becoming natively supported in Meteor soon.
I have an app using Akryum’s packages described in the video. What’s still missing is the integration with the Meteor account system. Specifically:
- persistent user session, as in storing / retreiving the user and resume token in localstorage
- implementing resumeToken mechanism, making sure the logged-in user stays logged in when refreshing the browser, and that the socket connection is reinitiated
- handling invalid resumeTokens
- managing socket connections to the Meteor backend, for example reconnecting when the backend goes down and then resuming the session again. That includes all the error tracking etc.
With Meteor + Blaze you don’t have to think about any of these aspects. With Meteor + Vue suddenly this becomes a thing.
And there’s no Vue+Meteor guide talking about these aspects. They always focus on publications and collections etc - like this video - but this is the actual hard part of the integration.
So I had to manually implement this and could only do so by studying the Meteor source code (which was a lot of fun).
I wonder how the native Vue integration will solve this?
Otherwise imho the integration is hardly usable for most of the world.
1 Like
In Lanaken? That’s where I lived. We had a Turkish restaurant on our street but I don’t remember that he had Kebap there.
Sorry for the OT, should take this part offline LOL
1 Like
@satya I think the Vue + Meteor integration is super easy to use, and the 1st thing I did was set up my recent app with the Meteor Accounts system, and it took no knowledge of Meteor’s internals.
I’ll probably write soon about the approach I took, which is very easy and more of a common approach that any Vue app might use. It authenticates with Meteors accounts system and has been so easy.
Lots more people are using Vue w/ Meteor these days, so docs & examples will be expanding, making it easier for everyone!
Was thinking of a useAccount hook on v3
1 Like
If you don’t mind me saying this, in my opinion this would not be a good design decision for a view layer integration. The current integration already provides the necessary tools for interacting with Meteor in the cleanest and most maintainable way possible - by making it possible to expose meteor reactive data as vue’s own reactive variables with the vue-meteor-tracker package. With this you can make full use of Meteor’s capabilities with Vue, while at the same time:
- having a very clean API surface between Meteor and Vue, you know specifically when and where data from Meteor flows to Vue - it’s easy to debug and if you ever need to switch off from Meteor, you’re in a good position to do so without having to refactor a bunch of Vue code
- having the front end code of your app work on the standard Vue fundamentals (i.e. Vue’s own reactivity system) instead of having a messy combination of Meteor’s and Vue’s reactivity all mixed up.
So for example your comment about retrieving the user tokens in localStorage. This already works with Vue like it’s supposed to. The Meteor.user and Meteor.userId objects are Meteor reactive variables and with vue-meteor-tracker, with a few lines of code, you can make these Vue reactive variables wherever you need to. In a specific Vue component, or more commonly, as a reactive user object in your top level component or vuex. Whatever logic you then wish to associate with the user object changing (for example changing a route on logout), you can perform in Vue.
The same goes for handling the connection to the Meteor backend. Meteor.status() is a reactive variable and with vue-meteor-tracker it becomes a reactive variable in Vue as well. Want to show a warning to the user when the connection to the backend becomes disconnected? Just expose the Meteor.status() as a Vue reactive variable and have Vue watch it. No studying of Meteor internals necessary, just a quick glance here.
I would really advise against introducing any Meteor related magic to the integration. It’s simply not necessary and in my opinion really hurts the maintainability of the code in the long term. Both the maintinability of the integration itself, but perhaps more importantly, maintainability of the apps as well. Keeping the integration lean has been a very good design decision by @akryum and I for one fully support it.
3 Likes
Really well said @vooteles
Meteor is really well set up with easy API options to build on Connections, Accounts, and Passwords.
I recently found a really handy “Cheatsheet” for the Meteor API that is so handy, anything with “Client Only” or “Anywhere” is 100% available to Vue. @satya you can test these out in the console and get everything you need.
This is really a brilliant part of the Meteor design of “Connected Clients” that doesn’t get talked about as much as it should. Without Meteor it is really hard to build a “Connected Client” So almost no one does outside of Meteor. There are many benefits to this approach for many modern apps.
CONNECTIONS:
// Connections
// Client Only
Meteor.status()
Meteor.reconnect()
Meteor.disconnect()
// Server Only
Meteor.onConnection(callback)
// Anywhere
DDP.connect(url)
ACCOUNTS:
// Accounts
// Anywhere but publish functions
Meteor.user() // returns user object
Meteor.userId() // returns userID
// Anywhere
Meteor.users
// Client Only
Meteor.loggingIn()
Meteor.logout([callback])
Meteor.logoutOtherClients([callback])
Meteor.loginWithPassword(user, password, [callback])
Meteor.loginWithExternalService([options], [callback]) # options: requestPermissions, requestOfflineToken, forceApprovalPrompt
// Anywhere
Accounts.config(options) // options: sendVerificationEmail, forbidClientAccountCreation, restrictCreationByEmailDomain, loginExpirationInDays
// Server Only
Accounts.validateNewUser(func)
Accounts.onCreateUser(func)
Accounts.validateLoginAttempt(func)
Accounts.onLogin(func)
Accounts.onLoginFailure(func)
PASSWORDS:
// Passwords
// Anywhere
Accounts.createUser(options, [callback]) # options: username, email, password, profile
Accounts.emailTemplates
// Client Only
Accounts.changePassword(oldPassword, newPassword, [callback])
Accounts.forgotPassword(options, [callback]) // options: email
Accounts.resetPassword(token, newPassword, [callback])
Accounts.verifyEmail(token, [callback])
// Server Only
Accounts.setPassword(userId, newPassword)
Accounts.sendResetPasswordEmail(userId, [email])
Accounts.sendEnrollmentEmail(userId, [email])
Accounts.sendVerificationEmail(userId, [email])
I don’t use all of these in my app, but that’s kind of the point, you can pick an choose based on the needs of what you are building.
2 Likes