You may have seen this by now, but figured I’d post it just in case.
Basically, MDG is going to create some type of Blaze abstraction on top of React so that you get the power of React and it’s community but with a more Blaze like syntax. I’m really interested to see what they come up with! Should be pretty cool.
Thanks for your perspective @tomRedox. I’m glad I came to Meteor over a year ago, or else I would have second thoughts too. Everyone was on the same technical page and things were much more simple. It was nice to be able to focus on my business ideas and not the tech so much – it was great while it lasted. Ah, the good old days… 
I agree with others, it’s a questionable time to come to Meteor with all the transition going on. In fact, it’s not just Blaze and Velocity MDG is kicking to the curb, they’re going to be adding Facebook’s GraphQL. Also look for Flux and Redux to complement or replace tech within the Meteor stack too. Also, Webpack could possibly be replacing portions of the Meteor stack. Say goodbye to Atmosphere in favor of npm. There might be more but it’s hard to keep up.
MDG seems to be slowly replacing a lot of their tech stack in favor of Facebook’s stack at the moment.
I have no choice but to learn the Facebook stack to keep current as I’m tied to Meteor due to a production application in use by many clients of mine.
Yea there is a lot going on in the JavaScript world. It’s still really early and everyone is figuring out how to write thick clients on the web. JS tech was optimized for “JS Sprinkes” 5 years ago.
Web apps are starting to become more like iOS/Android apps but our tooling and libraries for the past 6 years (or more) has been really poor at doing this (compared to .net, java, ios, android).
Backbone was the first paradigm shift for thick clients. React is another paradigm shift, making our UI declarative and using functional programming methodologies (the virtual dom is cool but is my least fav feature).
Also the language itself is starting to mature. We “FINALLY” have modules in the language 
Well almost, at least with Babel. JavaScript itself also does OO very poorly compared to Java/C#/Ruby/etc… However, it does do the functional paradigm really well and is getting more ‘functional’ features in ES7/8
Anyway my point is, JavaScript is inherently going to be churning through libs and frameworks until we can figure out how to build web apps that don’t crumble. Though I hear you, I too could do with some JS stability 
Any tips on using module pattern with different files sharing the same namespace?
If you’re using the ‘pattern’ and not real modules you can do this, it’s basically checked to see if the module is defined and if it is, it’ll use it, otherwise Utils will fallback to an empty object :
this.Utils = this.Utils || {};
Utils.parseEmail = function() {
};
// somewhere else
this.Utils = this.Utils || {};
Utils.parsePhone = function() {
};
Generally this is code smell because you can prob. break up the module more. For instance, why not use sub modules like this (or even use two non-nested modules):
// somewhere
Utils.Email = {
parseEmail() {}
};
// somewhere else
Utils.Phone = {
parseNumber() {}
};
I’m trying to accomplish something like that, but it always reach my namespace empty.
// both/_namespaces.js
this.Components = {};
// client/components/App.jsx
const App = React.createClass({...});
this.Components.App = App;
// client/startup.jsx
const { App } = this.Components;
console.log(App); // undefined
I’m using Chimp now to do feature testing, but there still is no solution for unit testing in Meteor projects, other than separating out your code into a package and testing that.
have you tried wrapping the last bit in a Meteor.startup ? Also I would only refer to this when defining. It can get confusing if you’re doing this.components inside of another function.
// client/startup.jsx
Meteor.startup(function() {
const { App } = Components;
console.log(App);
});
As I mentioned before, you can use Karma to unit test Meteor applications. I’ve done it for many months (before webpack). It just takes a bit of tweaking or manual importing. You don’t have to resort to the hacky package approach.
At any rate this will get better in 1.3
Still undefined even deconstructing inside the startup callback 
Correct me if I’m wrong, but doesn’t Karma only unit test server code? I remember having to set up integration tests separately for my client code.
Hmm, if you can setup a minimal reproduction and put it on Github I can look at it this weekend. I must be mis-understanding your setup.
Karma is only for browser code. It will run in as many browsers as you have configured and it will report back all results in the CLI. If you want to unit test server code you can either, run it in the browser (via karma), or use another test running like node-jasmine or mocha. There are experiments to run karma tests in Node but i’m not sure how stable they are.
Using Mocha for both is prob. the easiest experience, Jasmine in Node used to be difficult but i’m not sure how good it is now.
Oh yea, I think I forgot to delete that out of the html of react-ive meteor 
I decided to not make the video tutorials because I only had a few signups. However, I think I might have been a bit too early 
@SkinnyGeek1010, you’re very active on these forums, I didn’t get comment on this before, do you plan to post a video on migrating from Blaze 1 to React from the bottom up?
ah, sorry, missed that one No plans so far, i’m really swamped at the moment. It would also be hard to cover all the ways Blaze gets it’s data.
In general you can just use the MDG react-template-helper and pass in the data (however you’re getting it) as a prop. Then in the component just reference it with this.props.foo.
For example:
<template name="PostsContainer">
<div>
{{> React component=Posts postsData=myPosts }}
</div>
</template>
and in your Posts component you can take the props from the Blaze template and use them to render out a list of Post components:
const Posts = React.createClass({
render() {
return (
<div className='Posts'>
{this.props.postsData.map((post) => {
return <Post pdata={post} />
})}
</div>
);
}
});
The gist is that you’ll have a Blaze template ‘container’ that gathers data the normal way, and then you pass it down as a Blaze attribute. All of these attributes are a key on the this.props in React.
Hope this helps!
Just pushed a PR to fix this, the main problem was that App.jsx needed a Meteor.startup as well. Also prepending this to Collections made it not be global for some reason so removing some of the this fixed a few more errors.
Honestly, with 1.3 coming soon and a public beta available, you might want to start using that as long as you don’t need to launch in production before it’s released.
Awesome, thanks! Will follow your tip about 1.3 beta. It isn’t for general public, its a small app to help a inner process.
Go for it (go for it!).
I personally prefer text&code over video, you might have different metrics for video demand. The topics you provided sounded awsome.
Sorry for offtopic