Worst time to start a new app?


#16

@csiszi

Ah, yea I should have explained that better. If you have the “import” at the top of the file, then it has to be defined at the point that file is executed. You can wrap the entire file in a Meteor.startup function and that will solve it. Also you can “import” it inside of the component right before you use it (though this can be time consuming to migrate).

For example:

// in both/models/items.js

const Items = new Mongo.Collection("items");
...
this.Items = Items;

and in your component file:

// in client/components/Items/Items.jsx

const Items = this.Items;
const Component = React.createClass({
  getInitialState() {
    return {
      foo: Items.findOne();
    }
  }
});
this.Component = Component;

This way it’s not being called until after it’s defined. You could also do this:

// in client/components/Items/Items.jsx
Meteor.startup(function() {

const Items = Items;

const Component = React.createClass({
  getInitialState() {
    return {
      foo: Items.findOne();
    }
  }
});
Component = Component;

}); // end Meteor.startup

However, I would go a step further and organize your collections into their own modules. Models consume them but they are different things. You could make one collections file like this:
// in both/collections/index.js

const Items = new Mongo.Collection("items");
const Posts = new Mongo.Collection("posts");


this.Collections = {
  Items: Items,
  Posts: Posts,
};

Then in your files you can do this:

// in client/components/Items/Items.jsx
Meteor.startup(function() {

const {Items} = Collections;
// in 1.3 would be  import {items} from 'boths/collections';

const Component = React.createClass({
  getInitialState() {
    return {
      foo: Items.findOne();
    }
  }
});
Component = Component;

}); // end Meteor.startup

Or since this example is a module (not just a single export) we could do this without the wrapper like this:

// in client/components/Items/Items.jsx

const Component = React.createClass({
  getInitialState() {
    const {Items} = Collections; // now it's defined at call time
    return {
      foo: Items.findOne();
    }
  }
});
Component = Component;

Hope this helps! I need to write this up in a blog post soon :smile:


#17

Will you also consider a screen cast on migrating from Blaze 1 to React from the bottom up (not the top down)?

I’m talking taking a list within a Blaze 1 template, and converting it over to React – all the while keeping any communication between the new React list and the Blaze 1 template.


#18

Will you also consider a screen cast on migrating from Blaze 1 to React from the bottom up (not the top down)?

I prob. won’t have to do this but this video explains how to do it really well!

https://www.youtube.com/watch?v=BF58ZJ1ZQxY


#19

What does the above mean?

Anyway. I’ve seen this video, which is how I got the idea of starting from the bottom up. But what I and many others I think would like to see is this applied to Blaze 1.

Replacing a portion of a Blaze 1 Template with a React component (and this React component should be able to communicate with the Blaze 1 Template).

Something like this is badly needed for us in the Meteor community that have existing Blaze 1 applications that need migrating to React.


#20

I first heard about Meteor about four weeks ago, on the coding blocks podcast (great podcast). They were singing its praises so I checked it out and was blown away once I’d done the tutorial. This, I thought, is the perfect platform for getting all those ideas out of my head and into a prototype - so much quicker than the .net stack I’m used to.

Then I was listening to Josh and Ben on the Crater podcast and realised that Blaze was on the way out, and also that the testing game was maybe a little weak and it definitely left me sad. I think the question marks over Blaze at the moment are a real concern to those of us coming to the framework now, which is a shame as the buzz is really growing over Meteor (based on my sample of one people obviously…!).

I’m watching this space with great interest.


#21

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.


#22

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… :slight_smile:

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.


#23

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 :smiley: 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 :smile:


#24

Any tips on using module pattern with different files sharing the same namespace?


#25

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() {}
};

#26

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

#27

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.


#28

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);

});

#29

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 :smiley:


#30

Still undefined even deconstructing inside the startup callback :confused:


#31

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.


#32

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.


#33

Here is it: https://github.com/leocavalcante/meteor-modules
Thanks for the attention!


#34

This sounds great. One Question: Que pasa aqui? -> http://react-meteor-tutorial.com/


#35

Oh yea, I think I forgot to delete that out of the html of react-ive meteor :laughing: 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 :smile: