• frezik
    link
    fedilink
    arrow-up
    7
    ·
    8 months ago

    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.

      • frezik
        link
        fedilink
        arrow-up
        1
        ·
        8 months ago

        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.

        • madcaesar@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          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?

          • frezik
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            8 months ago

            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:

            <btn mobile big>
            <btn desktop small solid my-class>
            <btn medium>
            

            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.

            • madcaesar@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              8 months ago

              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.