Hi all, as the title suggests I’ve fallen out of Meteor development. In fact, I’ve fallen out of development in general due to a more narrowed focus for UX.
I’ve still been following meteor on the periphery and now have a couple of freelance projects that I’d like to us it with. I’m loving the dynamic imports that 1.5 brings, and I still love the reactivity of Meteor in general. But I feel like in the last year everything has moved so much that I’m not sure where to begin.
To show you where I am, the last thing I built open source with meteor was this boiler plate which uses a combination of blaze and react to feel more like ember (something I was very familiar with already). That way of working is gone and I don’t know where to pick up at for 1.5.
Do you guys have any resources for migrating from blaze to 1.5?
Thanks in advance!
First, not that much has to change. We’ve got a project that started on 1.1 and is currently on 184.108.40.206. There have been some changes through that, but most fall into the recommended, rather than must, category. The two biggest were moving most data retrieval from the server to method calls rather than pub/sub (ongoing), and the imports structure introduced in 1.3. Neither of those are necessary, but they will make your life better.
We are still using Blaze, but that’s largely because there’s no percentage in refactoring at the moment. React or Blaze, use what you like.
The Meteor Chef has a boilerplate project called Base, which he has kept up to date since before Meteor 1.0. It does a good job of putting together a useful base starting package, and explaining what’s what without being too fluffy or too terse.
(Edit: he is currently at Meteor 1.4, so the new dynamic imports stuff isn’t in there at the moment).
I have been maintaining, continuously upgrading and enhancing the Meteor Mantra Kickstarter
I will be releasing a major upgrade this week. It will offer all the features you see in the README updated to all the latest versions of everything (except those that require Node v6).
The release will merge the AsSub branch into the trunk, enabling what I guess you could call, “layered modular code-splitting”. The Kickstarter will reside as a git submodule of your application. Dynamic loading hooks and shell scripts will link your app’s npm modules into the Kickstarter at build time. Since it’s a git submodule within your app, you’ll benefit from new improvements made to it, without being forced to to alter your code with each later release.
If you’re interested in this, let me know and I’ll ensure you have all you need to get started.
I’d definitely recommend the guide to brush up on best practises https://guide.meteor.com/