![]() Thus, I believe having immutable values and making modifications only by creating new versions of the old data helps us to write code that is more predictable, safer and also easier to test. If the state object had been immutable, we could not have made such a mistake. See, it is very easy to accidentally modify mutable state. push ( 1 ) // Oops, you have mutated the application state outside of setNumbers! ![]() numbers let temporaryNumbersPlusOne = numbers. In JavaScript, primitive types like numbers, strings and booleans are immutable. If you do want to change it, you create a completely new value, which is equal to the original except for the modified parts. Immutability is a simple concept: an immutable value is some data that cannot be changed. Luckily for us, it’s still versatile enough for doing functional programming and modifying data immutably. Unfortunately, JavaScript, by nature, is highly focused on object-oriented programming and mutable data. I think this concept of immutability would be useful in the JavaScript world too. Clojure has built-in support for functional programming and immutability, to which I am now highly addicted. I’m familiar with the language, but frontend apps that me and my teammates have built have been mainly written in ClojureScript - a Lisp dialect that compiles into JavaScript. What makes things interesting is that for most of my career I haven’t touched JavaScript very much. I have been programming web frontend professionally for more than seven years now. If you are using JavaScript, like many frontend developers, your data is mostly mutable by default - unprotected from an external change. Once the data has been baked into a form that is ready to be used, you wouldn’t like anyone to change it in the middle of the process, would you? Unfortunately, it is quite possible if your data is mutable. This data is rarely presented in one form: it needs to be modified, transformed, merged and split in order to be useful in different layers of an application. From a database to a server, from the server to a client, from an application state to pixels on the screen. One of my colleagues once said that programming is just moving data from one place to another. We’ve already discussed a similar approach when talking about sort in the chapter about lodash.JavaScript What about arrays? Basic array operations in vanilla JavaScript are mutable - they update the array in-place: 1Īn immutable version of push would have to clone the array first and add the element to the new copy. In the previous chapters we’ve talked about how to avoid mutating objects. We haven’t yet discussed immutability of arrays. Obviously setIn doesn’t mutate the object but returns a fresh copy instead. The second argument is the value we want to set the property to. As you can see setIn takes an array of strings defining the path of properties leading to the value we are interested in. On the other hand fromJS will always traverse all levels of nesting. This is because Map only works shallowly - when it sees a property that’s a reference to an object it doesn’t convert it to Map but jest leaves it as it is. setIn(, "Celine") įirst of all, note that we’ve used fromJS instead of Map. fromJS(employee) Ĭonst updatedEmployee = immutableEmployee. Imagine having an object with several levels of nesting and having to update a property residing in a deeply nested object. For example, setIn works great with deeply nested objects. There are many interesting operations available on Map. We can easily return to the world of plain JavaScript objects with toJS: 1 Instead, it will return a new updated object. set( "category", "safety") Īs expected set will not mutate the original object. It’s very easy to initialize a Map from a plain JavaScript object: 1Ĭonst product = Immutable. ![]() The name comes from the world of algorithms and data structures where we use it as a name for a structure which maps some keys to some values (just like a JavaScript object). Let’s focus on Map which is an immutable version of plain JavaScript object. Immutable.js introduces a few immutable data structures. This post is part of the Functional Programming in JavaScript series. In this post we will learn how to use the library and how we can benefit from it. It is a library which makes working immutable objects much more natural. It’s not surprising given that one of the language’s main purposes was to mutate DOM (the Document Object Model).įortunately, Immutable.js comes to rescue. It doesn’t feel like the language and the standard library have been designed with immutability in mind. ![]() However, none of them feel very natural in plain, vanilla JavaScript. In the previous post we saw some techniques that can help us implement immutability. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |