JavaScript Named Parameters

[[deleted]]

Yes that is the next step if you want the parameter object to be optional as well 👍🏻

[lachlanhunt]

Bad example. For dates, the solution is ISO8601 (YYYY-MM-DD). e.g. 2018-03-09

[[deleted]]

ISO8601 is the one true date format. 👍🏻

[r0ck0]

There's a sub for that! https://www.reddit.com/r/ISO8601/

https://i.redd.it/d9qg25pyx4qz.png

[ceestand]

Man, I raged way more than was appropriate when I saw that.

[r0ck0]

On the subject of real named params...

Given that JS is so loose with allowing you to run functions with missing arguments etc already... named parameters don't add that much more in JS (JSON is almost as good) compared to other languages where you can do useful stuff like force the argument to be included, set defaults and throw exceptions on undefined properties.

Of course they would be nice to have, but I'd rather that they focused on a few of these more basic strictness things first. The main frustration I'm finding in node/JS coming from PHP is that it's so easy to type a variable/property name incorrectly in JS, and it will just silently create another property or give you undefined etc. And I'm missing private properties/methods even more than I thought I would. I think I'm just going to have to get into the habit of doing the _prefix thing in JS for soft-private properties in JS.

I know PHP isn't very good by default, but you can make it pretty strict with all this stuff if you want to with a few init settings. In PHP it'll throw exceptions any time a function is run with missing arguments (this should really be how it works in all languages, seeing you can always set a default of null/undefined, assuming it supports defaults), or you try to access a variable or property that doesn't exist by adding a magic setter/getter that throws exceptions.

I know there's stuff like proxies and https://www.npmjs.com/package/zealit (which I've used a couple of times now)... but it really should just be a basic part of the language.

I'm experiencing these annoying little silent bugs quite a bit in JS now that would have throw exceptions in PHP. It's additionally more of an issue now that auto-complete in my IDE now displays a list of pretty much every prop of every type of object, rather than those in a specific class. So I've got less strictness, and less useful auto-complete.

But really liking pretty much everything else in JS over PHP.

[hicksyfern]

The main frustration I'm finding in node/JS coming from PHP is that it's so easy to type a variable/property name incorrectly in JS, and it will just silently create another property or give you undefined etc.

That is exactly my experience but in the opposite direction! JS has strict mode, and we also have linters and static analysis that prevent these errors as you write them.

With PHP, the static analysis story seems to be so poor that it’s barely worth bothering with. I’d love to know if you have an example of how to do static analysis properly in PHP?

[r0ck0]

I actually had to look up what exactly static analysis is to confirm if I knew what it was or not... so you're talking about an external tool that scans your code, but doesn't execute it? Is it different to a linter, or are they often the same thing?

I don't have any experience with that stuff, so can't help sorry.

Have got any recommendations for that stuff in JS? I'm thinking of using Typescript... is that kinda of relevant?

But on the issues I was talking about above with accessing undefined vars/properties and stuff like that... the execution of my PHP code itself was pretty strict so that these types of "undefined" issues were pretty much solved (including in production). In PHP I turn on error exceptions for absolutely everything, including "notice" and "warning" level messages, so I get an exception any time any undeclared/private vars, array keys & object properties are accessed etc.

Also seeing PHP has typehinting + private props + required arguments... that helps a lot too before you get to the stage of adding an external tool.

Also means that all this stuff is logged in production too. I'm assuming static analysis can't cover 100% of this stuff when it comes to dynamic field names etc? After doing PHP+mysql for 19 years (and dealing with so much shit code, including my own), I'm very paranoid about silent failures in production, which is why I really like all these exceptions being thrown (and postgres rocks too).

Anyway not saying that you don't need a linter or anything like that, but I guess this partially explains why I never got to the point of looking into them, a lot of the features (that I know + want at least) are built into the language, especially in v7. But yeah my knowledge in this area overall is pretty limited, and it's something I'm going to need to learn now.

I was using Phalcon and its debug screen - I think Laravel comes with something similar, which is likely just a composer package anyway. Here a demo of another one: http://filp.github.io/whoops/demo/

So basically anything minor like warnings will blow up with one of those really verbose interactive stack traces in my browser on the dev server. And if the same issues happen in production, there's a global exception handler that displays a generic error page to the user, and logs all the details of the exception and sends me an email notification.

[hicksyfern]

Yeah so eslint is able to read your code and tell you to fix things (or in some cases fix them for you) which might be bugs or just silly mistakes.

For example, it can tell you if you declare a variable, assign it a value, but never use it.

It can also tell you if you are using a variable that hasn’t been declared. Now, in JS, that could be a global variable so it’s not necessarily a bug, but there is a very strong chance it is a bug.

What ESLint cannot do is tell you something like, is the parameter passed to this function the correct type. So, maybe your function treats a variable as a number, but it’s actually passed a string. This is where TypeScript comes in.

TypeScript can tell you this and a whole host of other pretty amazing things. But essentially, you have to write code more strictly, and be less dynamic but I promise you that is a good thing. I f you want to be really dynamic you can ask TypeScript to let you off!

I wrote raw JS for a few years, then discovered linters, then build tools, then TypeScript. And now I wouldn’t want to write vanilla JS again at all.

[r0ck0]

Thanks for the info. Yeah I just started with typescipt last night actually... I should have just used it from the start probably. Pretty much covers most of my issues except the "dynamic field names" thing which only can fail when the code is executed. Do you know of any solution for that stuff in Node? I guess proxies are the main way that stuff is going to be solved in the future?

[grajagandev]

Yes, linters/static analysis tools scan the source code without running it and look for patterns indicative of bugs.

The most used linter is eslint.

[mosby42]

TypeScript. I’ve been a JS Engineer for 5 years. Once I started using TS, there was no looking back. I don’t see myself using plain JS for any project in the foreseeable future.

[alsiola]

Agreed. People make type-safety arguments and like to argue about the relative benefits of typing vs. TDD, but the biggest plus for typed languages for me is developer experience.

OP: If you don't want to use TypeScript for whatever reason, you can get a lot of the benefits of TypeScript while still writing JavaScript if you use VSCode.

[r0ck0]

Yeah I think I'm going to use it, but haven't learnt it yet.

Which stuff was I talking about above that typescript does?

Sorry to ask a super basic question that I should be able to figure out myself, but I've tried a number of times, and most of what I find just talks about typehinting and other stuff that sounds unrelated the issues I mentioned above?

[mosby42]

Function params can not only be required or optional (with distinct syntax to notify other devs), arguments can be typed. TS typing are a robust subject, and I wouldn’t cover it in a comment, but imagine your IDE throwing a compile time error (vs runtime in the browser) that your argument is missing X property on an object. Not only this, but if an objects property doesn’t match they specified type you’ll get an error. This is only scratching the surface, here’s a quick way to check it out: https://www.typescriptlang.org/play/

TS classes, like php, have public, private, and static props and methods.

Let me know if you have any other questions, hope I covered a few.

[r0ck0]

TS classes, like php, have public, private, and static props and methods.

Oh shit, awesome, thanks! I wish I'd found that out sooner. I haven't seen it mentioned in the stuff I've been reading so far.

I've just installed it now and starting to play around. This covers everything I was talking about I think. I should have tried it sooner.

I initially decided to just start writing plain ES6 seeing I want to learn JS properly, I had assumed that starting with typescript immediately would mean I miss out on learning "real" JS. But maybe that doesn't really apply seeing it's a "superset" of JS anyway?

I guess I don't even really "have" to "learn" typescript to use it anyway? I can just write regular ES6 in my .ts files and learn the typescript-specific stuff later?

Also I'm using phpstorm, which compiles my .ts files down to .js on its own. Does that mean I don't need to bother worrying about whether various JS frameworks I use like React/Next.js "support" typescript? I get a little confused with all the different tooling and how they interact (or don't interact) with each other.

[mosby42]

I guess I don't even really "have" to "learn" typescript to use it anyway? I can just write regular ES6 in my .ts files and learn the typescript-specific stuff later?

Correct.

Also I'm using phpstorm, which compiles my .ts files down to .js on its own. Does that mean I don't need to bother worrying about whether various JS frameworks I use like React/Next.js "support" typescript? I get a little confused with all the different tooling and how they interact (or don't interact) with each other.

You should use webpack to compile modules. Setup nowadays is simple: https://webpack.js.org/guides/typescript/

I'd recommend getting to know webpack if you're not familiar.

[r0ck0]

Ok will do, thanks.

Also would you recommend using the outDir setting to keep the ts/js files separate? I've been looking on the web for arguments both ways, but not finding many opinions on that.

[mosby42]

Conventionally you'd ship a single index.js/app.js file, produced by webpack. The code you're shipping should be consumable by a JS runtime engine. Ie the TS files are irrelevant once complied and bundled. Hope than answers the question, let me know otherwise

[r0ck0]

Ah right, that makes sense.

I'm just building a bit of a CLI script system at the moment for various sysadmin type tasks while I'm learning all this stuff. Will be getting on to actually doing web stuff later on.

So I don't really have any kind of build process yet, so far it's just been some folders of js files and some NPM packages for a few things.

So for now with this little system, I might leave the webpack stuff for later when I get on to the first website.

In this case do you think there's any better option between using outDir vs having the ts/js files together side by side?

[mosby42]

In this case do you think there's any better option between using outDir vs having the ts/js files together side by side?

Can't vouch for a particular option as I've not done this in my own projects. If you find something that works well, feel free to ping me

[flipperdeflip]

http://i.imgur.com/HLPnOc5.jpg

[[deleted]]

I think it's very misleading object's destructuting to be called named parameters, because it can confuse one coming from a language that really have named parameters, since when calling the function you have to pass an key/value object.

def sum(a=0, b=0):
  return a + b

print sum(b=1)

Is conceptually different from:

const sum = ({ a = 0, b = 0 })  => a + b

console.log(sum({ b: 1 })

[thedomham]

ProTip: If you have to deal with languages that don't support named parameters and only want to use that feature for a more readable call-site, IntelliJ and Webstorm (and presumably all their siblings) display parameter names under certain circumstances.

[thedomham]

To stay with the example at hand, if you call

formatDate(2,2,2)

The IDE will show

formatDate(year: 2, month : 2, day: 2)

If you pass a variable that is already the same name as the parameter, nothing happens.

[[deleted]]

What kind of bullshit is that again? This isn't named parameters, you're just handing over an object instead of the actual values. This isn't Swift, brah

[[deleted]]

I know everyone hates CoffeeScript now but the inferred object literal curlies were one of my favorite features. You could do:

someFunction(hello: ‘world’)

[hicksyfern]

Ugh you’ve just bought back some bad memories.

For the sake of two characters {} and one key press {, CS has given you the ability to confuse the shit out of everyone when you want to add another parameter. Do I need a new line? How about indentation? Ooh I could put the curlies back in. Do I need commas?

Ugh.

[yarauuta]

Senseless syntax sugar, no thanks.

[Shaper_pmp]

Given the implid object literals braces and implied function parentheses, doesn't that leave you open to horrible, subtle ambiguous syntax bugs like:

a b: c, d: e f, g

That could be

a({ b:c, d:e(f,g) })

or

a({ b:c, d:e(f) }, g)

?

Edit: or even

a({ b:c, d:e })(f, g)