Meteor 1.3 *early beta* now available

announce
163

Thanks for the reply, source maps (Java and CSS) are both enabled. I’m getting the same behaviour in Chrome, IE and FF (all on latest versions). All my other Meteor stuff is running fine, it’s weird.

164

I would like some more direction on how to use ReactMeteorData or some other paradigm for reactive meteor data in a React module, especially when using ES6 syntax :smile:

165

Current best practice, which only supports mixins, here:
http://react-in-meteor.readthedocs.org/en/latest/

Discussion on upcoming direction, and support for es6 wrappers / decorators here:

1 Like
166

I’m afraid this doesn’t work with NPM module syntax. This depends on the Meteor react package while NPM is based off of packages

167

You can add the react-meteor-data package directly. I don’t believe it depends on react-runtime.

meteor add react-meteor-data

Then just install and use react from npm with import/export. ReactMeteorData will be available as a global, to mix into your components.

168

Okay. I was using the earlier Beta and this was causing conflicts with react-meteor-data and the NPM installed react. I guess I’ll have to upgrade and see if it works alright. Thanks!

169

Hmm, that’s odd! Give a newer one a try (I would try beta4, beta5 introduced issues for us).

If you check out the package file, it does not require react-runtime (which is what would cause the double react conflicts).

1 Like
170

Note that in the final releases, react-runtime will simply redirect to NPM react, so there will be no problem at all using packages from Atmosphere and NPM both together with React.

1 Like
171

Good to know. Right now I have a whole bunch of Tracker.autorun and Tracker.dependency since I couldn’t get react-meteor-data to work with NPM support. Will be so nice to remove all those once a consistent work flow is agreed upon by MDG and the community

172

Hey all,

We just wrote a post about a first pass at app testing which we’ve implemented on top of this 1.3 release:

3 Likes
173

I think you should be able to import ReactMeteorData like so:

import {ReactMeteorData} from 'meteor/react-meteor-data';

and use it as usual while waiting for a consistent work flow.

174 
import {ReactMeteorData} from 'meteor/react-meteor-data';

That probably is the consistent workflow. I think importing things explicitly should be the way to go.

4 Likes
175

I am having difficulty requiring a particular npm module in 1.3. Here is my issue with reproduction repo. https://github.com/meteor/meteor/issues/6114

Any ideas?

176

I would like to test a deployment of the latest beta release. How would I go about it?

I currently use this buildpack with IBM Bluemix hosting: https://github.com/ind1go/bluemix-buildpack-meteor

Most buildpacks I’ve tried insist on using version 1.2.1. I’m not familiar yet with creating or editing buildpack scripts. Can anyone point me in the right direction?

177

I have a problem with modules that i want to be both on the server and on the client.
I have a dependant module on the client in /client/imports/dependantA.js
I have a dependant module on the server in /server/imports/dependantB.js
Where do i put my dependency.js module for it to be importable in both modules ?
I have tried in /imports, but it doesn’t work.
Thank you.

1 Like
178

This should work fine and I’ve done this very thing for sharing methods between client and server. Can you post a code sample where it doesn’t work?

2 Likes
179

Ok, i have found out the answer, you have to write import foo from "/imports/dependency" you have to use a root slash.

3 Likes
180

Is it possible to use jspm within Meteor 1.3 or is it a world of conflicts?

181

Hmm, I didn’t have to do that, it worked fine with a relative path. Well as long as it works for you, then it’s good!

182

to support his point, I’ve had to experiment with getting my paths right aswell - I’m on beta 5, and I’ve had to use root path’s aswell for shared code.

1 Like