Live data from Hacker News

JavaScript fundamentals before learning React

robinwieruch.de

61–70 of 72 posts

Re: JavaScript fundamentals before learning React

#61

The biggest fundamental is that you only rarely need new (when forced upon you by a bad API) and you don't need this (not ever). That statement has worked well for me in this language. I know it causes many people to cry and get immediately angry. The bottom line is that they increase the verbosity (substantially) of code, they are completely optional, and they often compound code maintenance through a more convolute…

I can understand not liking `this` in JavaScript, but it seems optimistic to say you never need it. If nothing else, you are bound to encounter large amounts of code that uses it, so being familiar with its behaviour is necessary to understand that code.

"... but it seems optimistic to say you never need it. If nothing else, you are bound to encounter large amounts of code that uses it"

Wait -- JavaScript now supports "it"??! Can you iterate over "them"? At least it's not gendered, so you need to use "him" and "her" and "it" depending on the object's gender, or just keep everything in a collection so you can use "them".

Re: JavaScript fundamentals before learning React

#62
post #7
post #6

Earlier quoted context omitted.

Hi, Robin. Then you may want to say that `const` guarantees that the name will remain bound to that object. The great-GP is correct in that `const` has nothing to do with immutability besides that. It doesn't necessarily conveys an intent of inner immutability. It just states that whatever is in the variable will stay there until it goes out of scope. Using `const` whenever possible is good advice, off course.

Good point, thank you for the clarification! Somehow I have always thought about showing the intent of keeping the data structure immutable when using const. I have changed it in the article. One more learning for me today :)

I've found this is often a problem in languages that pass simple values by value but compound values like objects and arrays by reference. The meaning of a qualifier like const and the inference a reader can draw when they see it can fundamentally change depending on what type of value it is applied to.

My experience has been that both the change in value/reference behaviour and the lack of total immutability guarantees when using a const qualifier on a reference type can be a source of bugs.

Languages like C and C++ distinguish more explicitly between value and reference semantics, and likewise between constant pointers and [mutable] pointers to constant data. To some extent that removes those sources of bugs, at the expense of having to write more explicit but verbose types like `const SomeType &` instead of `SomeType` all over the place.

Re: JavaScript fundamentals before learning React

#63
post #18
post #8

Hey, author here :) I am curious about your experiences using/learning React. Are there any other JavaScript topics which are important when starting out with React? Would be great hearing your opinion!

It’s worth noting that using the fat arrow syntax for class functions make them exponentially harder to unit test because they do not exist on the Prototype of the component, but are instead only initialized when the class is initialized. If you are trying to unit test a function that calls another function in the same class you cannot mock the second one it if it is a fat arrow.

I also think it's worth noting that fat arrow class methods is not a feature of JavaScript/ECMAScript, but rather a feature of Babel. It might make it into a future standard, but so might decorators (including autobinding decorators) or double-colon syntax for binding. None of these is currently legal vanilla JS.

Re: JavaScript fundamentals before learning React

#64

This article has a lot to offer a JS + React beginner so it feels lame to reply to some tiny part of it, but this bit is a constant error propogated in the ecosystem: > Even though it is possible to mutate the inner properties of objects and arrays when using const, the variable declaration shows the intent of keeping the variable immutable though. let and const only control mutability of the reference. They say noth…

> let and const only control mutability of the reference. They say nothing of the value mutability. const then can only be a signal that you are not reassigning to the identifier. Wouldn't this definition suggest that the value CAN be reassigned? The reference could be immutable but allow value reassignment, but is not the implementation of const.

> The reference could be immutable but allow value reassignment, but is not the implementation of const.

You can reassign values through a const reference in javascript. For example:

    const x = [1]
    x[0] = 2 // ok!
This just doesn't work with primitive values, because primitive values are immutable and copy-by-value. So this works with lists but not strings (because strings are a primitive and thus immutable).

Or, put in C++ friendly terms, javascript doesn't distinguish between pointer reassignment and value reassignment. It only has reassignment, which is illegal for const variables. Variables which hold non-primitives (lists, objects, etc) are actually pointers to those values. const does not affect the mutability of the value stored at the pointer.

Re: JavaScript fundamentals before learning React

#65

This article has a lot to offer a JS + React beginner so it feels lame to reply to some tiny part of it, but this bit is a constant error propogated in the ecosystem: > Even though it is possible to mutate the inner properties of objects and arrays when using const, the variable declaration shows the intent of keeping the variable immutable though. let and const only control mutability of the reference. They say noth…

PostScript actually stores read, write and execute bits in the references themselves! (Unlike the way Unix files store the access mode attributes in the inode itself, so all hard links to the same inode have the same rwx attributes.)

So you can have a reference to a mutable PostScript dictionary representing a font or something, then go "dup readonly" to hand out a read-only reference to the same dictionary, so other code can't modify it, but you can still modify the writable font if you hang onto the original writable reference.

You're allowed to change the execute bit of a reference with cvx/cvlit, but you can only downgrade the readability and writability of a reference with readonly, executeonly or noaccess. Since PostScript code is data (homoiconic), protected code in proprietary fonts can be read-only executable arrays.

http://www.math.ubc.ca/~cass/courses/ps.html

Re: JavaScript fundamentals before learning React

#66

The biggest fundamental is that you only rarely need new (when forced upon you by a bad API) and you don't need this (not ever). That statement has worked well for me in this language. I know it causes many people to cry and get immediately angry. The bottom line is that they increase the verbosity (substantially) of code, they are completely optional, and they often compound code maintenance through a more convolute…

I can understand not liking `this` in JavaScript, but it seems optimistic to say you never need it. If nothing else, you are bound to encounter large amounts of code that uses it, so being familiar with its behaviour is necessary to understand that code.

this also has some really fun rules that are useful for mad science sometimes. For example, you can recover the JS context's global value via this:

    (function() { return this })()
In a browser this resolves to the window object. In nodejs it resolves to the global object. I've used this a few times to help write isomorphic javascript bundles, though its much less useful than it once was.

Re: JavaScript fundamentals before learning React

#67

Earlier quoted context omitted.

I agree with you, but I’ve cleared up this confusion with a number of colleagues. People coming from languages that have a truly immutable “const” find the keyword confusing in js.

Yea, I think const in JS alludes to the way const works in C++. If someone knows java though, it can always be explained that const in JS is identical to marking a local variable as final in Java. More so than const, I was perplexed by the JS choice of the `let` keyword. Are there any other languages that use let for declarations that can be reassigned? Did BASIC allow lets to be reassigned? Can’t remember...

`let` in common lisp can be reassigned.

Re: JavaScript fundamentals before learning React

#68
post #34

Earlier quoted context omitted.

It's been astonishing to me how people switched from var to let, but seem confused as to when to use const. I use const wherever I can since it's more appropriate for non-changing variables, and it helps me more easily visualize how a variable is being used in a block. But in other people's code I see a lot of letting all over the place. Maybe it's because of those articles saying to use let instead of var, but gloss…

maybe it’s because const is 2 more letters to type. if “let” was “letitbe” I bet const would be more popular seriously though, I wish they could have chosen a 3-letter word for const in keeping with var and let. I know const exists in other languages, but it doesn’t even mean the exact same thing as some other languages anyway.

Unrelated but didn't know how to contact you: https://www.youtube.com/watch?v=TdzIKD0oMzo

Re: JavaScript fundamentals before learning React

#69

This article has a lot to offer a JS + React beginner so it feels lame to reply to some tiny part of it, but this bit is a constant error propogated in the ecosystem: > Even though it is possible to mutate the inner properties of objects and arrays when using const, the variable declaration shows the intent of keeping the variable immutable though. let and const only control mutability of the reference. They say noth…

I think the author was going for something like "When you see a const, think twice before changing anything inside that const."

Re: JavaScript fundamentals before learning React

#70
post #51

Earlier quoted context omitted.

It's been astonishing to me how people switched from var to let, but seem confused as to when to use const. I use const wherever I can since it's more appropriate for non-changing variables, and it helps me more easily visualize how a variable is being used in a block. But in other people's code I see a lot of letting all over the place. Maybe it's because of those articles saying to use let instead of var, but gloss…

I tend to go by the following rules: Use const by default. If I need let, see if I can refactor to using const. I've found that actually I can go far without using let, improving my code along the way. I see a pattern from colleagues. They initialise a variable using let and then branch to figure out what should go inside it. That can be replaced by a pure function. For loops tend to be the next thing. In that case,…

> They initialise a variable using let and then branch to figure out > what should go inside it. That can be replaced by a pure function.

I don't want to detail the discussion, but I would love to see some of your code. I contend with this antipattern often but solve it in different ways often depending on language features. If you're doing anything other than simply calling an auxiliary method with a ton of parameters, I would appreciate seeing your solution in Javascript, a language that I'm learning but not proficient in.

Post reply on HN