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 nothing of the value mutability. const then can only be a signal that you are not reassigning to the identifier.
const is still useful as a default of course since reassignment is generally the exception.
Maybe this is what they meant but the language used made it seem otherwise.
While it is simpler, I think it's better that people actually understand the difference between a reference to a value and the value itself. "Pointers are hard" is a statement that many beginner programmers make, but if you don't understand the concept, you will always be limited as a programmer.
And whether you say "can be reassigned" or "mutable" (which means exactly he same thing, BTW) it doesn't really matter. JS has some surprising mutability rules. Variable references can either be mutable or not (depending on const, let or var), however function parameter references are always mutable (which can cause much hilarity in some circumstances).
Even values are a bit strange at times unless you understand what's going on under the hood. It's obvious that boolean or number values are immutable, but it's less obvious that string values are immutable; even more so since it doesn't throw an error (at least in V8) when you try to mutate them. You might assume that function values are immutable (how could you mutate it?), but because of closures, they are completely mutable (as long as the values being closed over are mutable). And, well, functions are also so-called "object" values in JS (which I still think is not a good idea, but I understand why they did it).
While, it is more complex to discuss that separation, it's valuable when you get into more difficult discussions -- especially if you are trying to write mostly pure functional code, with a few non-pure bits for performance. You need to be able segregate the pure from the non-pure and if you are passing closures, for instance, it's super important to understand how mutating a value in one place can essentially infect something that you thought was pure.
> "can be reassigned" or "mutable" (which means exactly he same thing, BTW)
I have never used 'mutable' to describe a variable, but rather only to what it references. Perhaps it's more lax in js-land. Why would you call something that's atomic ally changed anything other than assignment?
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...
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.
> 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.
Author here {: Yes, what you are saying here is what I meant. I didn't want to mix in the whole topic around "passing by value or reference" in this short teaser.
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.
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 glossing over const.
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 can be replaced by higher order functions/methods without detriment to clarity (usually an improvement).
Perhaps the move towards iterators, with async support, will make it more common and legitimate. I haven't yet used those in a codebase but perhaps let in that instance leads to clearer code.
> 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.
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.
It would have been nice to have `let` work like `const` does, and something else for what is currently `let` (`mut`?).
The TC39 was constrained by the list of reserved words though. `let` and `const` were reserved in ES5, and there was nothing that could have conveyed `mut`.
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.
If you don't know about references, I feel like you shouldn't be touching react. React is quite easy to pickup if you have an understanding of JavaScript and the Dom. The tooling surrounding react is an entirely different story.
To be fair, beginners should stay far away from most of the tooling around React. In-fact a lot of veterans should too. Most people only use stuff like Redux or Immutable out of habit rather than necessity, or as a crutch to constrain themselves away from bad habits that they shouldn't have picked up in the first place.
I think this idea is propagated by Swift developers because that’s the only place I’ve ever seen const used this way at all, ever.
That said I started writing articles on JavaScript and React and TypeScript in medium and please subscribe and check out my post history of you’re interested in this topic! I only did two so far but I plan to do one every day starting tonight, with this very topic!
> 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 nothing of the value mutability. const then can only be a signal that you are not reassigning to the identifier.
const is still useful as a default of course since reassignment is generally the exception.
Maybe this is what they meant but the language used made it seem otherwise.