Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.
Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you’re not used to it, but it just takes practice.
I’d say this example doesn’t fully show off what immutable data can do–it tends to help as things scale up to much larger code–but here’s how I might do it in JS.
Notice that JavaScript has a bit of the immutability idea built in here. The Array.flat() returns a new array with flattened elements. That means we can chain the call to Array.join( " " ). The classes array is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn’t always do that; push() and pop() modify the array in place.
This particular example would show off its power a little more if there wasn’t that initial btn class always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.
Very interesting. Actually the part you mention about there being an initial 'btn' class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.
It’s only a const within a function. You can pass the value to another function and changing it as it’s passed. For example:
In functional programming, you tend to keep track of state on the stack like this.
What is the advantage of this VS just overwriting the var?
Keeping state managed. The data for the function will be very predictable. This is especially important when it comes to multithreading. You can’t have a race condition where two things update the same data when they never update it that way at all.
Hm I’m having trouble visualizing this do you know a quick little example to illustrate this?
Rather than me coming up with an elaborate and contrived example, I suggest giving a language like Elixir a try. It tends to force you into thinking in terms of immutability. Bit of a learning curve if you’re not used to it, but it just takes practice.
Ok how about this then, I frequently do something like this:
let className = 'btn' if (displayType) { className += ` ${displayType}` } if (size) { className += ` ${size}` } if (bordered) { className += ' border' } if (classNameProp) { className += ` ${classNameProp}` }How would this be made better with a functional approach? And would be more legible, better in anyway?
I’d say this example doesn’t fully show off what immutable data can do–it tends to help as things scale up to much larger code–but here’s how I might do it in JS.
function generate_class_name( display_type, size, bordered, class_name_prop ) { classes = [ 'btn', ( display_type ? display_type : [] ), ( size ? size : [] ), ( bordered ? bordered : [] ), ( class_name_prop ? class_name_prop : [] ), ]; return classes.flat().join( " " ); } console.log( "<" + generate_class_name( "mobile", "big", null, null ) + ">" ); console.log( "<" + generate_class_name( "desktop", "small", "solid", "my-class" ) + ">" ); console.log( "<" + generate_class_name( null, "medium", null, null ) + ">" );Results:
Notice that JavaScript has a bit of the immutability idea built in here. The
Array.flat()returns a new array with flattened elements. That means we can chain the call toArray.join( " " ). Theclassesarray is never modified, and we could keep using it as it was. Unfortunately, JavaScript doesn’t always do that;push()andpop()modify the array in place.This particular example would show off its power a little more if there wasn’t that initial
btnclass always there. Then you would end up with a leading space in your example, but handling it as an array this way avoids the problem.Very interesting. Actually the part you mention about there being an initial
'btn'class is a good point. Using arrays and joining would be nice for that. I wish more people would chime in. Because between our two examples, I think mine is more readable. But yours would probably scale better. I also wonder about the performance implications of creating arrays. But that might be negligible.Aaah okay i get it now :) that makes a lot more sense.