I noticed that what normally works in the JS ecosystem, doesn’t work in Meteor.
I had to rename every file from .js to .jsx. Then I had to add ‘.jsx’ to lots of imports. This seems like a silly distinction since, I believe, JSX is a superset of JS so assuming that all code is jsx should work.
Another thing, it seems class properties aren’t supported (that’s what I gather from this and this). Class properties are needed in React, for example: static childContextTypes = ...
For now I guess I have to rewrite my component as a React.createClass. So now we have three distinct ways of defining react components. This gets confusing quickly.
Maybe Meteor needs a compatibility/stability mode, so people who for some reason need an old version and those using new features can both use Meteor without a lot of hassle. I don’t care which one is the default, as long as there’s a way to make the code work.
What you describe is (IMHO) a symptom of running BETA code, for example the .JS/.JSX thing is solved in more recent releases and Class properties are also working fine in my use cases from 1.3-beta.12 onwards… (YMMV)
Its a transitional point for Meteor, if you look at the project now compared with 12 months ago its made a monumental movement towards a more “Standard” JS approach and you (and all of us) are right on the bleeding edge of that movement.
For what its worth, If you have some code which isn’t working on Beta.12 onwards I’d be really keen to collaborate on it with you as i’m also keen to “iron out”/understand/promote/evangelise the modern Meteor best practices…
I upgraded to beta.12 yesterday, because I was hoping it would fix it, but it didn’t for me. I still get the same “Missing class properties transform” error.
Specific to React classes or JS classes in general? I use class properties in the Meteor Costs Starter Kit and they work really well (Beta12) however i’m looking at the code now and i’m not using them on my React classes (extends React.Component)…
I see your point, the solution I would use is to stay with the class method for defining React.Components and apply the childContextTypes post definition, as illustrated in the diff here:
Thank React folks for doing changes, even if there was so much “React is so good because it doesn’t change the syntax the way Angular does and the api will stay the same” noise around the net a year ago.
Cool, thanks for this workaround @floydprice, now it works. I didn’t know I could define properties on class like that (coming from a Java background, haha).
A few months ago, we asked MDG to identify and maintain a Long Term Stable Branch. Talked to Geoff personally on this issue.
There’s been no official response, although my hunch is that 1.3 might get labeled as LTS. In other conversations, I’ve gathered that they were hesitant to label anything LTS without ECMA2105 support. (Unfortunately, that kind of thinking sort of misses the point of an LTS release.)
So, that leaves community releases and distros to fill in the gap for the time foreseeable future. From our work on such things, version 1.1.0.3 has been extremely stable. The packages in the clinical track that have made it under continuous integration on CircleCI are also extremely stable. Everything else is unstable and beta by default.
To be fair, React only added another option on how to define components. The old one still works… it just doesn’t make sense mixing two approaches in one project, that’s confusing.
I think it’s Meteor’s responsibility to make sure all approaches are possible, if it wants to be considered a serious participant in the JS ecosystem.
Class properties are only at stage 1 of standardization, which means the syntax and semantics could still change drastically
However class properties seems like a pretty basic syntax for using classes at all. How can I even use classes without this? And how contraversial can the syntax static x = ... really be?
Ok, thanks for the info @awatson1978. I guess I’m looking for the opposite of LTS. Your definition of unstable isn’t unstable enough for me JS ecosystem changes quickly. Being 1 year behind the conventions projects like React are using doesn’t seem acceptable to me.
In terms of LTS 1.3 looks like a good candidate as its bridged the gap between “classic” meteor and the modern JS/NODE ecosystem. while keeping the door open for improvement (via NPM).
Yeah Javascript doesn’t have the strict semantics that Java has which is both awesome and terrible
