Organizing ES6 code

[SkinnyGeek1010]

The Meteor.onReady(function(){…}) way seems to be good for the client side classes which isn’t bad but is not helping us to take the full advantage of isomorphism.

Whoops, I meant to type .startup as the onReady doesn’t exist… I edited the example above too.

When I’ve tried that, what I saw was the build failing due to pre-requisites order issues, so we’re back on the import/export issue.

But if you’re extending a class inside of the startup these super classes should be read into memory already? I haven’t tried this yet but I think all files should be useable inside of this. However if you put all classes inside of a startup then you’ll have issues as then the order of startups firing will be an issue.

Yea file renaming would work too, but not ideal.

ES6 imports are really needed! For once I feel like Meteor is really lagging behind the JS community

[sebastianconcept]

yeah @SkinnyGeek1010

For me the filenames is a cheap hack but is the lesser evil for now.

If JavaScript would be even more late bound it wouldn’t need loading order to be more than a warning since at a later stage when the class is really used it would have been loaded and available. But since it’s a requirement, yes, we really need import/export

[jedwards]

That will be great! Looking forward to it!