Yosemite

Yosemite

I'll never forget the first time I head the song Yosemite by Lana del Rey. I very nearly clicked away. 

It was quite near the start of my Software Engineering journey, right near when I start learning the Front-End/Web Development. I was listening to Arcadia by LDR before, maybe twice, and then Blue Banisters came on. I nearly clicked away in the first 30 seconds but I forced myself to keep listening anyway. 

I'll never forget how that song has made me feel. It became my song of 2022 even though I only discovered it in November. I can still listen to it every day and get that complete sense of wonder and of awe that I felt the first time that I heard it. That ending of the song is completely amazing, and it just completely just blows me away every time.

"Withstanding all the time, changes, and seasons..." - LDR

Concise Body Arrow Functions

Why am I so bad at arrow functions? Whyyyyyyyyyyy? 

Just kidding, I am beginning to get them. But why are they so hard?

"Functions that take only a single parameter do not need that parameter to be enclosed in parentheses"

The biggest thing I have learned today so far is that arrow function expressions' parameters do not always require there to be brackets around them. Basically, if there is only one parameter that the function takes, then there do not need to be brackets (parentheses). 

Examples

ZERO PARAMETERS

const functionName = () => {};

ONE PARAMETER

const functionName = paramOne => {};

TWO OR MORE PARAMETERS

const functionName = (paramOne, paramTwo) => {};

Implicit Return

Implicit return is when we use arrow functions and we omit the return keyword. This basically means that we don't need the curly braces ( { } ).

"The contents of the block should immediately follow the arrow => and the return keyword can be removed."

So (to quote a Codecademy example) if we have:

const squareNum = (num) => {
    return num * num; 
};

Then we can refactor this one to:

const squareNum = num => num * num;

Which is pretty crazy. Crazy, huh?

Codcademy points out the following changes in the above example: 
  • There are no parantheses around the first num since it is a single parameter (see above, please).
  • There are no curly braces { } since the function "consists of a single-line block" (of code).
  • The return keyword has been removed since the "function consists of a single-line block" (of code).

One more little example from my course

This is an example of an implict return with ternary operators (What does this mean?! I haven't seen this since my Python days). 

const greaterThanFive = (num) => {
    return num > 5 ? true : false;
};

So far the above is an arrow function (expression) with a ternary operator.

But here is the above function with an implict return added into it as well. 

const greaterThanFive = num => num > 5? true : false;

I NEED TO REVISE EVERYTHING ON THIS BLOG POST. LIKE EVERYTHING. IT'S NOT GOING IN/FULLY CLICKING AT ALL.

However, I have found a little section in the summary of the course which pretty much summarises everything that hasn't gone in for me just yet and that I feel like I need to revise: 

So this just makes me feel a little bit better...

A revision of functions

A few short little things that I forgot during my early lessons on functions which would've hylpe me along the way if I'd remembered (I know that some people say that terminology doesn't matter but the way I learn really relies on terminology in a big way tbh):
  • the 'function keyword' is literally just function but then the name of the function is called the IDENTIFIER and I had forgotten about that
  • A 'parameter' (which I still don't really get) is described as (as in I get what it is practically but I still don't get the logic) is "a named variable inside a function's block which will be assigned the value of the argument passed in when the function is invoked".
    • So if we put in "weight" and "height" here
      • while the function is declared
    • Then we don't have to actually put in the VALUES (value, value, value, value) of the weight and the height until the function is INVOKED
      • i.e. until the function is called
  • Speaking of CALLING FUNCTIONS it GOES A LITTLE SOMETHING LIKE THIS:
    • you just type the NAME OF THE FUNCTION
    • i.e. the FUNCTION IDENTIFIER 
      • omg to call the function you just TYPE IN THE IDENTIFIER
      • You just TYPE IN THE IDENTIFIER
      • You just TYPE IN THE IDENTIFIER

A little thought on parameters

Just want to throw in this little quote on parameters as well: 

According to the Codecademy course, the ES6 version of JavaScript "introduces new ways of handling arbitrary parameters through default parameters which allow us to assign a default value to a parameter in case no argument is passed into the function". 

i.e. SO THAT IF NO ARGUMENT IS PASSED INTO THE FUNCTION, WE NO THAT IT WILL USE A DEFAULT PARAMETER(S) I.E. DEFAULT VALUES TO RUN IN IT WHEN IT IS EXECUTING THE CODE. 

Just another little example of an arrow functions

Because I can never, ever get enough of these. 

const workoutJournal = (miles, avgTime) => {
    console.log('I ran' + miles + ' miles at an average of ' + avgTime + ' per mile.');
};

The above example:
  • Is an arrow function expression
    • Because it uses the const keyword to assign the function to a variable
    • Because it uses "fat arrows" (whyyyyy) => (hahahaha)

And here is one more example:

const greeting = () => {
    console.log('Hello Programmer!');
};

Aaaaand another (just one more, I'm really really sorry)

const multiplier = (number) => {
    console.log(3 * number);
};

Correcting my mistake

The purpose of a parameter is to 

"Allow a function to accept data". 

(I got this wrong in a quiz).

Also one more thought

The most 'condensed form' of a function does not even use the return keyword...

Comments

  1. Just a note on some of the above. If you're writing your own code it's up to you how you want to write your code. There are tools out there that help you not have to think about these things and no matter how you write your code it will change it based on the rules you like.

    Personally I like writing small functions and happily forget to use parens when only using a single parameter but I just let my tools add things in or take them away.

    When working with a team, ideally they should have provided rules for said tools or have a code style guide that you can follow so that your code fits in with the rest of the code in a codebase.

    ReplyDelete
    Replies
    1. Morning Adam, I just saw this!
      That's very helpful thanks because e.g. I really love patterns and I don't necessarily see why I should have to remove the parentheses from a single parameter (just for example). When you say tools are you talking about things like Run.JS? Or do you have other tools in mind that you use?

      And yes got it about the teams, very good advice, noted! 😯

      Delete
    2. So many languages have tools known as linters and formatters with newer languages shipping their own official offerings. Linters will typically highlight where there's a problem while formatters will change them for you. You can think of a linter like a spell checker in a word document.

      JS doesn't have these built in tools but the community has produced some and two that a majority have opted for are ESLint and Prettier. RunJS for example has Prettier built in and you can look into the formatting settings to choose your preferences.

      Delete
    3. Oh and another thing to add is that some of these tools are very opinionated and strict enforcing rules for everyone while some are highly configurable. ESLint is very configurable while Prettier is fairly opinionated but allows for some configurability for example whether you want to always use parens or avoid them when they're not needed. Hope that helps.

      Delete
    4. Adam, as always, this is AMAZING, thank you ever ever so so much.

      Notes on this going in next post :D

      Delete

Post a Comment

Popular posts from this blog

Hello World

Two Lines of Thought, Makes Me Wonder What I'm Missing