that’s not a bad solution, but not exactly beautiful syntax, a lot more work type out. And having to import {get} in every file?
Why is javascript not designed to be simple in standard use cases?
1 Like
Lodash/Underscore links:
Explain please?
Also, I’m running Meteor 1.3.5.1 and would like to start migrating to ES6 syntax, what do I need to do, install babel?
Easy: In Javascript the if statement only fails if the condition is “falsy” (i.e. a literal boolean false, but it can also be undefined or an empty string, for example)
get(company, 'images.logo', '/images/default-logo') will either return the value from company.images.logo (which will be “truthy”) or it will return /images/default-logo which is also “truthy”.
Which means that the statements inside the if-statement will always be executed.
1 Like
Just meteor add ecmascript and you are there. Everything in .js files will be treated as ES6 code and transpiled so it runs even on IE8.
1 Like
Yep! good catch! My 2nd example should have assigned it to an ‘imageUrl’ var or something.
A tab trigger solves the typing length issue, but yeah not quite as nice. Maybe someday it’ll be baked in 
Thanks brother – this did the trick. Do I need to also add this?
meteor add es5-shim
And in terms of Lenting, do you use this?
npm install -g eslint babel-eslint
Does anyone have advice and patterns on converting existing client side Blaze js files from ES5 to ES6?
es5-shim is something you should include if you support IE8 as IE8’s support of ES5 is horrendous.
For linting, I use webstorm so I can’t speak to other linting tools, except to say that I’ve heard of babel-eslint being really helpful for people with atom or sublime (both excellent editors).
1 Like
This points to a general issue in JS, there’s usually multiple ways to accomplish the same thing, unlike python.
As far as lodash, the main concern of using non-native methods is bundle size (web performance)? Seems like lodash/fp fixes this? Also webpack 2 has tree shaking, which I think solves the same issue, removes unused code in lodash.
I think we as a community should simply write a babel plugin for nicer null-checking syntax, it’s probably simple enough. I asked about it on babel forum, but no answer on the complexity of this. Why wait around until the committees get around to it?
AMEN! That’s kind of what CoffeeScript was and is about. In a sense, I think we owe ECMA 6 to CoffeeScript. JAshkenas decided you don’t have to hate JS, and could have both the elegance and expressiveness of Python/Ruby and the ubiquity of JS. Also, it’s really cool to reduce your code base by ~25% simply by removing semi-colons, parethesis, and curly brackets. IMO, the massive adoption of CoffeeScript gave the ECMA committee the kick in the pants it needed.
1 Like
As a former Rails ninja, and knowing all the Rails-to-Node transplanted people out there, I had hoped http://rubyjs.org/ would take off. No such luck though.
Agreed @redmage. So where do we go from here? Coffee script is ok but I personally feel Meh about the syntax, I like curly braces fine.
Today the thing that is getting me down is how many imports I need for my front end code. For a react page with a handful of form elements I need about 10 or more imports. Wonder if someone has tried to solve this? Meteor had this solved by allowing stuff to be in the global namespace. Maybe not ideal but it beats having to import every damn thing a thousand times. I imagine there’s some way you could hack webpack to achieve global imports, but haven’t tried. Nobody else finds this annoying?
@vikr00001 yes, it’s possible. For example https://github.com/webpack/docs/wiki/shimming-modules
I don’t know if this method is recommended.
@vonwao @vikr00001 Modules in ES6 are singletons. They can only execute once, no matter how many times they are imported.
The best way to cut down on excessive imports is to use module folders.
In a given folder, you put an index.js. That provides an entrypoint to the “module”. index.js imports files within the folder, and exports what is needed outside. Other sources then import the folder instead of any specific file. The exports from index.js are available as usual but semantically it is equivalent to a node module being imported which is important for keeping large imports under control.
3 Likes
Exactly, see Building multiple apps from the same source for one way to structure your app to use this import structure.
1 Like
I didn’t even realize there was a thread about that. My team does the same thing, although we use git submodules instead of symlinks as some of our developers are kinda stuck in windows world.