Hello! I have had the same problem with my Tic Tac Toe game and now the Simon Game. Basically, I have a default game object that I’m trying to use for the reset functions in both games. It looks something like this:
I would expect this to replace this.game from the constructor with the defaultGame object. However, when I console.log(defaultGame) in the reset function, it’s taken on the properties updated throughout the game, instead of remaining unchanged as I would have expected.
I sort of disagree with this. Es6 classes are convenient syntactic sugar, but they makeep the classes look like Java classes (sort of the point) when they don’t work like Java classes. I’d say it’s better to learn how prototypes and prototypal inheritance work first, otherwise the code you read (written by others) won’t make sense.
Thanks! I was interpreting ‘clone’ as ‘the same thing’ when reading documentation. Will keep digging.
I’ve already started with prototypes, but am curious to experiment and try other ways. I’ve been using React for most of these front-end projects, but would likely learn far more building something with ES6 classes from scratch. Perhaps for the next project, or a later refactor of this one.
I don’t disagree with this. Many ES6 features are HUGE improvements over the ES5 way of doing things. However, I do think that it is important to understand what the language actually does. I have no issue with using ES6 classes, I just think you should learn how prototypal inheritance works FIRST, because it is not the same as most languages with a class keyword. I suppose this is less of an issue if JS is your first programming language, which is probably the case for many people here, but then the same problem will apply when they learn a second language just in the opposite order.
If anything, shoehorning OOP into everything regardless of whether the language actually does OOP is “legacy thinking”. Besides, anyone working professionally is going to have to work with, and understand, legacy code. Assuming that ES6 classes work the same as classes in other languages will get you into trouble eventually.
I’m saying it’s nice to design a solution using class hierarchies and methods and have the code reflect your design with obvious keywords like “class” and “constructor” and “extends” and have setters and getters nicely called out - this has nothing to do with how a class is actually implemented - it’s more about easily mapping code to an abstract design
Not true. Neither the object spread operator nor Object.assign make a deep copy. There are good reasons why: it is actually fiendishly difficult (or impossible, even) to define a default (implicit, built-in) deep copy that would make sense for all kinds of object; it would often be a hazard to (reasonable) efficiency. Also, of course, one often requires shallow copy rather than deep.