Forem: James F. Thomas

Just Which Way Does The Auth Flow? #3

James F. Thomas — Sat, 19 Sep 2020 22:14:42 +0000

The Switch In The Flow From Authenticate to Authorize

Introduction:

Last time we concluded our exploration of the OAuth process with the secrete calling of the req.login() function. Remember that it is just one of the little perks of putting Passport.js middleware functions into our project. So, thank you very much Passport.js, and now we can move on up to serialize. At this point in our control flow, having completed authentication, our user information is being passed from the done() function in our Verify Callback to the next function in the chain, serializeUser(). This function marks the establishment of a new user session and the last level of our exploration.

What is a user session?

During my research, I encountered several different ways people defined user session, but for our purposes, we will think of it as a cache of requests a user makes during a specific time period. This time begins at the invocation of req.login() and ends, of course, when you call req.logout(). But wait there is some Passport.js hidden magic going on again. The logout() function is exposed on the request object, and will be called inside the route handler. It is extremely easy to miss this connection, I know I did, mostly because of the differences in scope. So instead of logout() is found in that chain of Passport.js functions we set up in the authentication strategy, it’s called when the user is on the way out the door, like turning off the lights when the user clicks logout.

Code Example: `logOut()` function invocation in route handler

apiRouter.get('/logout', (req, res) => {
  req.logOut();
  req.session.destroy();
  res.redirect('/');
});

In the above code block, you can visualize where the logout() function is invoked. This code block was housed in a sperate file from the OAuth strategy setup used in my project and illustrates how someone could leave it out of their map of the control flow. Let’s backtrack a bit before we forget about serializeUser().

So where does serialize fit in?

Remember that serialization occurs between login and logout functions, once the user’s information is passed from our verify callback to serilazeUser() at the beginning of our user session. The job of the serailizeUser() function is to translate certain user data, in this case, the id, into a format that can be stored within a session cookie. The session cookie is sent to the browser and maintained for the length of the session. The baking and decorating of session cookies is a treat we’ll cover another time.

Code Example: Passport.js `serializeUser()` function

passport.serializeUser((user, done) => {
  done(null, user);
});

When we examine the code block above you see that serializeUser() accepts two arguments, the user object, and the done() function. It is at this point that serializeUser() will designate what user information to translate into the session cookie by passing it to done. Once done has been invoked our code is passed onto deserializeUser() which will then locate a user within our database that matches the translated data. This serialization and deserialization of user information allows our application to keep all user data safe server-side, while the cookie will only contain a session id that is used to continuously authorize that user’s requests throughout the life of the session.

Code Example: implementation of Passport.js `deserializeUser()` function

passport.deserializeUser((user, done) => {
  getUser(user) 
    .then((foundUser) => {
      if (foundUser) {
        done(null, foundUser);
      } else {
        console.log('no user with that id found');
      }
    })
    .catch((error) => {
      console.log(error);
    });
  });

If the session hasn’t expired or the user hasn’t hit the logout route, the serialize/deserialize set will be working to keep that user happy providing information to their authorized requests. One function I missed mentioning earlier was the destroy() function. This method is part of the Express.js framework and not native to the Passport.js control flow unless you specifically choose to employ it in your applications’ structure. The destroy() method will destroy the session cookie, subsequently ending that users authorization, and requiring the entire OAuth process be restarted for future requests to be served.

Conclusion:

At this point, we have explored all the levels as well as players involved in those steps that need to be taken in order to authenticate and authorize a user. I know that I learned a few very interesting things and it is my hope that you did too. Biggest take away from this whole dive:

Authentication is the process of proving you are who you say you are, while Authorization is the process of being allowed to go into certain areas, use certain services, or view specific content. Here's a fun little analogy: All crew sailors can get permission to come aboard the ship, but only certain members can eat in the officer's mess.

I'll be back soon, to tackle some new topics. I've been told by many teachers that the more you write, the more you grow, so to ensure my development skills continue to grow I will write continuously.

Happy Coding!!!

Sources:

Wikipedia.com (https://en.wikipedia.org/wiki/Session_(computer_science))
How do Express.js Sessions work? (https://tilomitra.com/how-do-nodejs-sessions-work/)
Passport.org (http://www.passportjs.org/docs/configure/)
A peep beneath the hood of PassportJS' OAuth flow (https://dev.to/anabella/a-peep-beneath-the-hood-of-passportjs-oauth-flow-eb5)

Just Which Way Does The Auth Flow? #2

James F. Thomas — Sun, 13 Sep 2020 17:13:16 +0000

Requesting & Utilizing User Information To Authenticate

Introduction:

Last time on blog post, we took a dive into the subject of user authentication and explored what I like to think is its outermost layer of the process. We briefly defined what the “user auth” model entails and how we can utilize the Passport.js library to accomplish these goals. While we did not cover all the different authentication strategies provided via Passport.js, we did describe the most traditional user auth method the “Local” strategy. If you recall the local strategy involves setting in place a process in which the user can create a username and password, that will be persisted, and later used to grant them access to restricted aspects of your application. My goal for this post is to dive into the second layer of the user authentication control flow, unpacking the events that occur between the first redirect away, the user requesting authentication, and the final redirect back to our application as a trusted guest.

What happens between redirects and the auth request?

After the user lands on our home page and is prompted to log in, they are then redirected to the OAuth provider where they click an authorized link, and now what? Well, now we are inside of the OAuth process, where the user will grant authorization to our application to utilize their profile information in order to prove they are, without exposing their password. The next question should be along the lines of if they do not give out a password then what will our application use to grant them access? The OAuth provider, upon successful user verification, will grant our application, the consumer, a temporary pass also known as an OAuth or access token. The way I like to think of these tokens is like a limited access pass to the user's information, in which exactly what information our application is authorized to use is designated on the token, and any other sensitive information pertaining to the user is never exposed.

Code Example: access token

{
  "access_token":"RsT5OjbzRn430zqMLgV3Ia",
  "expires_in":3600
}

The above code snippet is an example of the access token that will be returned to our application via the OAuth provider. As you can see, the token contains an id string and an expiration time.

What happens after we get the token?

Now that our application has a verified access token, it can make HTTP requests to the provider API for information for as long as that token is valid. But we are more concerned with user profile information returned along with the token from the Passport.js strategy we configured and incorporated into our application. The strategy configuration contains a function called the “Verify Callback”, which is used to locate user information with this matching profile information. If we have never encountered this user then their information will not be persisted in our database and we must now make an entry for them, but if they are located the corresponding information is returned. The information is now passed to the done() function of our verified callback and saved as user on the request object.

Code Example: Passport.js OAuth strategy configuration

  passport.use(new GoogleStrategy({
  // define the options to use with google strategy
  clientID: process.env.GOOGLE_CLIENT_ID,
  clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  callbackURL: process.env.GOOGLE_CALLBACK_URL,
},
((accessToken, refreshToken, profile, done) => {
  // deconstruct variables from profile object
  const { id, displayName } = profile;
  const userObj = {
    idDiscord: id,
    username: displayName,
    profilePhotoUrl: profile.photos[0].value,
  };
  getUser(userObj)
    .then((gotUser) => {
      if (gotUser) {
        done(null, gotUser);
      } else {
        addUser(userObj)
          .then((newUser) => {
            done(null, newUser);
          });
      }
    })
    .catch((error) => {
      console.log(error);
    });
}

In the above code snippet, you can follow the control flow of the code block contained in the “Verify Callback”. The user id, display name, and photo URL are deconstructed from the returned google profile information as userObj. The variable userObj is then passed as an argument to the getUser() function that will query the database for a matching entry. If a successful match is located that information is returned and then passed onto the done(null, gotUser) function, but if no match is found in the database a sperate function adduser() is called to create an entry for that user. The newly persisted users information is now returned and also passed to the done(null, newUser) function. The part that isn’t shown in the code but rather handled backstage by Passport.js is the invoking of req.login().

Code Example: Passport.js login function


req.login(user, function(err) {
  if (err) { return next(err); }
  return res.redirect('/users/' + req.user.username);
});

The Passport.js library has an exposed login function on the request object, that will add the returned user information passed to done() as req.user. This information can be utilized in different ways within our application, usually for authorization, but most commonly to establish a new user session. The reason we haven’t seen it in our set up of authentication middleware is that Passport.js will call req.login() automatically when you are utilizing its middleware. Now, isn't that a great little bit of information to store under your cap for next time?

Conclusion:

Much to my surprise, during my research I discovered that user authentication and user sessions are not within the same process and so I’m stopping our dive into level 2 of the OAuth flow right here. Next time we will finish our exploration of OAuth by unpacking what a user session is and all the Passport.js functions involved in that process. Hope you learned a little something new about user authentication, and until next time:

Happy Coding!!!

Sources:

What is OAuth? Definition and How it Works (www.varonis.com)
Wikipedia.org (www.en.wikipedia.org/wiki/OAuth#OAuth_2.0)
Passport.js docs (passportjs.org)
A peep beneath the hood of PassportJS' OAuth flow (dev.to)

Just Which Way Does The Auth Flow?

James F. Thomas — Sun, 06 Sep 2020 16:23:27 +0000

The Passport Authentication Control Flow

Introduction:

I am currently wrapping up the student portion of my journey as a
software developer and that means group projects, huzzah! Now, this is the time in which you sharpen your skills by getting things done with your peers with minimal involvement from program instructors, or at least that is the way it is done in our program. Anyway, while working in my current group, on a great project I might add, a groupmate asked me a question to which I felt I gave a subpar answer at best. So, in my quest to present a more informed answer in addition to satisfying my own standards of knowledge I decided to do some more research which lead to this blog. The question is coming, but first, we need to set the scene and explain the tech involved so no matter what level of developer you are currently, you can follow this story and possibly learn something constructive in the process. This story begins with authentication and since we were using node.js in our project that means I should briefly introduce passport.js.

What does is it mean authenticate?

User authentication involves obtaining unique identifying information from users traditionally including username + password, identification numbers, phone numbers, pin numbers, code words, secret handshakes, or email addresses. I snuck the secret handshake one in there just see if you were really reading, but in a physical setting that would definitely make the list. If you want a physical auth example for digit access, think of eye scans or thumbprint access now employed on phones.

Once these credentials are obtained and confirmed against a persisted list to be valid, your website will grant that authorized user access to previously restricted sections, services, or resources hosted on the site. Think of a situation in which you visited a site and were prompted to log in or create an account with a username and password. Well, my friend, that is authentication, and in this digital world, we have all experienced it.

Just to give you a visual reminder, the above picture is a basic example of the traditional authentication process that we are most familiar with. Now that we are clear on what it is to authenticate, let’s tackle the passport part.

What is passport.js and why use it?

Passport.js is an authentication library that allows developers to use external avenues or third-party entities for user authentication. Passport is middleware for Node.js based applications that serves the singular purpose of authenticating users to grant them access to an application. This allows a dev to basically outsource the task of collecting, persisting, and verifying user information to someone else and focus on creating an awesome application. This is great because it is one less user feature for the dev to have to map out, setup, and test. In my opinion, the biggest benefits of using Passport.js rather than setting up your own authentication are familiarity and trust. In the situation where a user is unfamiliar with a particular site and in turn, does not want to supply any personal information, Passport employs OAuth services from well know entities that will then be used to send identifying information to the less trusted sites granting users temporary access without exposing personal information or passcodes. Passport utilizes OAuth services with well-known sites like Facebook, Instagram, LinkedIn, Twitter, and Google to request certain information, not your password, known as tokens that will be used to authenticate and then authorize access to sites for a specific amount of time. Because users are more likely to already have an account with one of the trusted OAuth providers, this avenue of user authentication is becoming more popular. Each provider will require different authentication steps and so passport has created a different strategy for over 500 different OAuth providers from which developers can choose to incorporate into their site authentication process. To browse the full list visit http://www.passportjs.org/packages/.

Is he ever going to reveal the original question?

Now that the foundation is laid, and we understand what user authentication is along with how Passport.js fits into that process I feel I can move into the question that was asked to me. So, after we successfully incorporated Passport.js into our project and employed a Google OAuth strategy for users, and in the process of viewing the returned user profile object to implement other application features, I was asked if I knew the flow of the authentication middleware. I was able to use my intuition and a chain of console.log() statements to give an answer but that wasn’t enough for me and so here we are.

What is the flow of information through the Passport.js chain of middleware?

First, in order to provide an OAuth service on your website, you must choose and configure the strategy. For our application, we choose the Google strategy and so below is how I configured and incorporated it into our application. I created a file titled passport-setup.js in which I required all needed dependencies and configured the Google strategy.

passport-setup.js


// require passport library
const passport = require('passport');

// import googleStrategy from passport library
const GoogleStrategy = require('passport-google-oauth20');

// import db query functions from database/index.js
const { addUser } = require('../database/index');

// set up passport middleware to use google strategy in our project
passport.use(
  new GoogleStrategy({
  // options for the strategy, input clientID && clientSecret
    callbackURL: '/auth/google/redirect',
    clientID: process.env.GOOGLE_CLIENT_ID,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  }, (accessToken, refreshToken, profile, done) => {
    // passport callback function
    // console.log('passport callback fired'); // indication that function fired
    console.log('USER PROFILE', profile); // shows returned profile information
    const { displayName, id, photos } = profile;
    addUser({
      google_id: id,
      name: displayName,
      profile_photo_url: photos[0].value,
    })
      .then((newUser) => {
        console.log(`Created New User: ${newUser}`);
        // completes the http request, and sends information to next function in middleware chain
        done(null, newUser);
      })
      .catch((error) => {
        done(error);
      });
  }),
);

When an unauthorized user visits and clicks a restricted link, they should be directed to a login page with authentication service options if more than one is set up or directly to the authorization endpoint. In the case of our application when users visited and clicked the login-in button in the navigation bar, they were redirected to google.com. The redirect was accomplished via an authentication route like the code snippet below.


authRouter.get('/google',
  passport.authenticate('google', {
    scope: ['profile'],
  }));

Once the user has completed the authentication steps via Google they will be redirected back to our application at a specific endpoint. This was accomplished by specifying the callback route like below.


/**
 * google callback route returns users to the home screen following google authentication
 * utilize passport.authenticate() function to authenticate the user via google
 * retrieve the users profile information
 * finish by redirecting the user back to homepage "/"
 */

authRouter.get('/google/redirect', passport.authenticate('google'), (req, res) => {
  res.redirect('/');
});

These three steps are going to serve as our top layer of the OAuth process because if you really examine each code example you will see portions that need deeper explanation and also require additional pieces of the puzzle to make them work. But from this top layer, we have directed the user to our OAuth provider, allowed them to log in, sent back the user profile information along with temporary access information which will be stored by our site. At this point, the user has been granted access to restricted service on our site and did not have to give any personally sensitive information.

Conclusion:

While authentication is a procedure we are all very familiar with these days, so is data security or lack thereof, and after learning more about the entire OAuth process I find it to be a simple aspect of UI/UX design that a developer can employ to make potential users more trusting of the applications they build. I want to continue our deep-dive into the OAuth process, so in the next installment we will unpack where to retrieve all the information needed to properly set up the OAuth strategy you want to employ, in addition to clarifying how the temporary access information returned is stored and then used on your site. I do hope you learned a little something new about the authentication process and that it sparks your own search for new things to incorporate into future projects. See you soon but until then….

Happy Coding!!!

Sources:

Passport Docs (www.passportjs.org)
Microsoft Docs (www.docs.microsoft.com/)
Learn OAuth 2 (www.tutorialspoint.com/oauth2.0/index.htm)

Unifying our basics of TypeScript

James F. Thomas — Sun, 30 Aug 2020 16:25:27 +0000

Exploring the "Union Type" and how it is applied.

Introduction:

Last week we ended our journey into the basics of TypeScript (TS) by showcasing how the language implements the features of static typing, optional inferred typing, and how it utilizes the static typing rules with complex data types called interfaces. Remember static typing refers to the dev being required to define the variable data types before use, optional inferred typing is when the compiler sets variables data type from the first value assigned to it, and finally, interfaces are the construction blueprints that outline the member or return types of the values encapsulated within our complex data structures (objects, arrays, functions). These rules were all employed with variables that were assigned to a single value or output type. This week it is my goal to highlight how the TS language utilizes another characteristic in order to combine these usually singular assignments into a variety of inputs and outputs for the variables a developer may need to utilize in the code their composing. Let us jump right in and see how TS unites the selections we have available to make our code more accepting of all the possibilities.

What is the Union Type?

The union type is an attribute of the TS language that allows a developer to choose from many possible value data types for their variable assignments, function inputs, and returns. Up until this point in my coding journey, I have personally been exposed to single value assignments. The closest situation in which I have gotten to experience something similar to the union type in JavaScript (JS) is using conditional statements to evaluate for data type and then controlling the response based on those data types encountered.

JS code example:


let exampleFunction = (input) => {
  if (typeof input === "string"){
    console.log("value is a string"); 
  }
  else if (typeof input === "number"){
    console.log("value is a number"); 
  };
    console.log("input must be number or string");
};

exampleFunction(true); 

// prints "input must be number or string"

The above code block is an example of how I have previously utilized aspects of JS to evaluate variable data types and then control program response based solely on the data type entered as an argument to the function. The if conditional coupled with the typeof operator work well to accomplish this goal, but as you can see there are multiple steps that need to be put into place in order to accomplish this goal.

With each piece of the block that needs to be set in place, there is another chance for error and so enters the TS Union type to make the life of a new dev like me a little bit simpler. With TS the task of assigning expected specific variable data types is accomplished by using the Union type, and the single “|” pipe operator.

TS code example:

let fixCar = function(cartype: "MITSUBISHI" | "TOYOTA"){
    if (cartype === "MITSUBISHI" || "TOYOTA"){
        return "your vehicle is fixed";
    }
    return "We don't service that make of vehicle here."
}

console.log(fixCar("FORD"))

// Argument of type '"FORD"' is not assignable to parameter of type '"MITSUBISHI" | "TOYOTA"'.

Looking at the above TS example we can easily see how the code block is far simpler than the JS code which performs the same task. We have fewer if conditionals to evaluate the parameter ‘cartype’, and we no longer need to utilize the typeof operator. To me, the beauty of this union type comes about when you attempt to use the function fixCar(). Remember “Static Typing”, well here it is again, by utilizing the union type when we define the function parameters we will receive an immediate error message from the compiler when we attempt to use the function fixCar() with any other parameters besides those explicitly defined in the function declaration.

What else can I unite in TS?

Now that we have seen one example use of the Union type in TS, let's quickly look at a few other examples of how we can use the Union type to require certain inputs for our data structures.

simple data type example:

let singleVar: string | boolean;

singleVar = "I'm OK"; // Good

singleVar = true; // Good

singleVar = 24; // Bad => Type '24' is not assignable to type 'string | boolean'.(2322)

In the above code block, we have utilized the Union type to explicitly require that and value assigned to the singleVar variable be of the “string” or “Boolean” type. Any other value types will cause the compiler to throw an error and our code won’t run.

mixed data type example:

let mixedVar: string | string[];

mixedVar = 'This is good'

mixedVar = ["I'm good too"] 

mixedVar = true; // Bad => Type 'boolean' is not assignable to type 'string | string[]'.

mixedVar = [24, 'Not Good', true];
 // Type 'number' is not assignable to type 'string'.
 // Type 'boolean' is not assignable to type 'string'

In the above code block, we have utilized the union type to explicitly require that the value assigned to the “mixedVar” variable be a “string” or an array of “string” types variables. I really thought this was a cool use when I first encountered it. Not only will TS type check your single values, it will do the same to values inside your complex data types. Now honestly how cool is that?

complex data type example:

interface Student {
    name: string;
    age: number;
};

interface School {
    programName: string;
};

type CodingStudent = Student | School;

let coder: CodingStudent = {
    name: "James",
    age: 36
};

coder = true; //Type 'boolean' is not assignable to type 'CodingStudent'.

coder = {
    programName: "Operation Spark" 
}

In our final code example above, we have utilized not only the Union type but we have also created a custom type by combining the requirements defined in our interfaces. Combining interfaces allowed us to create instances that can contain attributes from either interface and still satisfy our static typing restrictions set within either interface.

Conclusion:

In this leg of or journey, we expanded our understanding of the static typing system employed in the TS language by combining it with the Union type. The Union type allows us to increase the choices of possible values that can be assigned to the variables I want to use in my code. The Union type can be combined with simple or complex data values, along with other aspects of the TS language to create custom types via the | & type operators. I am really enjoying learning about the new ways that TS is providing me to interact with my code and will continue to explore them in blogs to come. I'm looking forward to unpacking the concept of type guarding in the very near future, but first, more research and practice so it's presented in a clear and correct way. Hope you learned a little something new.

Happy Coding!!!

Sources:

TypeScript Docs (https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html)
whiley.org
howtodoinjava.com

Learning about a new Type of Script

James F. Thomas — Mon, 24 Aug 2020 01:33:35 +0000

A Brief Introduction into the language of TypeScript:

When you begin your journey into the world of writing code the nuances of the language you learn will be one of the most difficult things you encounter, or at least it was that way for me when I started. Wrapping my head around the concept of variable types, and then remembering the differences in how each interacted with the other in JavaScript was initially a huge challenge. With time the rules became clearer and I then began to feel more comfortable with writing more robust blocks of JavaScript code. I later experienced, mostly through error handling, that JavaScript is very lenient in what it will allow you to write and will even permit you to construct improper expressions without ever throwing an error. Frankly, I prefer to be warned that something is not set up correctly on line 1 before I can move onto line 2 or even further to 200. Now that I have suffered through hours of debugging, engraining certain best practices, I am able to catch potential errors before they happen. Continuing my evolution as a developer learning new languages, I was pointed toward TypeScript, which was touted to protect against some of the errors that JavaScript allows. This blog is my dive into better understanding TypeScript starting at its roots.

What is typescript?

TypeScript (TS) is a static scripting language maintained by Microsoft that is open-sourced and intended to be a syntactical superset of JavaScript (JS). This is a very technical definition transposed from the TS docs, but it still needs further deconstruction for a newbie like me to gain a clear understanding of what TS is and how it differs from JS. Static scripting refers to a type checking format or set of rules that a language enforces to ensure code the developer has written is bug-free. Static typing languages are those that enforce their type constraints at compile-time, and also demand that the developer define the data type of the language construct (variables, expressions, functions, etc.) they intend to use before it is utilized in their code. Static scripting allows for code to be debugged as it is written, prior to being run or executed by the computer, resulting in faster run times, and of course, we can all understand the importance of this feature. Catching bugs before code is run will ensure better and proper functionality of the programs you write. Let's examine how TS interacts with some primitive data types.

Example 1


var name: string = "James Thomas";

// explicit data typing

Above is an example of a static scripting language in action, explicitly defining the variable data type before it is assigned in the code. TS has an extra optional feature, due to its strongly typed designation, that needs to be showcased. The term “Strongly Typed” simply refers to the fact that in this language declared variables are bound to a certain data type. Variables must be assigned to values of the data type they “Explicitly Defined” or “Inferred” to be whenever used in the code or the compiler will return a type error. This optional feature mentioned will allow for the dynamic typing of written variables while still providing the security of static typing error protocols by the compiler. “Inferred Typing”, is the languages' ability to determine a variables data types without prior explicit definition.

Example 2


var name = "James Thomas";

// inferred data typing

Although the above variable definition looks like vanilla JS, the magic happens when the variable is used later in code and fails to adhere to the typing rules of the language. If the variable is used in a syntactically incorrect manner the compiler will throw an error just as if it were explicitly defined in our first code example.

Example 3


var number = 36;

number = "James Thomas";

// Error: Type 'string' is not assignable to type 'number'. (2322)

So, we have seen how TS works with a few primitive data types but still need to explore how the language applies the static typing parameters to complex data types.

How Typescript interacts with complex data types?

Because complex data can contain primitive values, the static typing rules employed by TS must interact with complex data types in a slightly different manner. To facilitate this static typing interaction with complex data, TS includes what is called an “Interface”. The Interface should be looked at as a defining blueprint or contract for all elements of the complex data type to be later defined and used in your code. These TS Interfaces operate much like ES6 class constructors, where each newly instantiated class instance will always contain the properties and methods defined in the parent constructor.

Side Note => TS does include classes as well but interfaces are a new aspect of the language to me and so I'm gonna highlight them here to improve my understanding.

One major difference between Interfaces and Classes is that Interfaces only contain the declarations of the contained elements and not the values or method functionality to be inherited by each new entity created. Just to clarify “instance” refers to classes while “entity” is referring to interfaces. This means that with interfaces the developer must later define the elements of complex data type outlined by the interface.

Example 4

interface Student {
    firstName: string,
    lastName: string,
    className: string,
    answerRoll: ()=>string
}

// this interface defines the types of all Student objects to come

Looking at code example above we see our TS interface called student which defines all the elements any Student object must contain. This interface is our blueprint to follow when we create Student objects for use in our code. Another key difference between interfaces and classes is that interface entities are not instantiated with the new keyword. The syntax differs in that you must still define the object and all its containing elements.

Example 5

 var senior: Student = {
    firstName: “James”,
    lastName: “Thomas”,
    className: “McLaren”,
    answerRoll: ()=>string => {return “Here, ready to code!”}
}

// new Student object

Although this way of creating new entities via the interface may seem a bit cumbersome compared to simply using the keyword “new” and a class constructor function the pay off comes at compile time. Remember that TS compiles into JS so when the compiler reads an interface it ignores it. Less code to compile results to smaller build times and no impact on the runtime of the code you wrote. That is a great pay off in my book.

Conclusion

I think this is a great place to stop on this leg of our journey into the basics of TS. We have unpacked a few foundational concepts like:

What a static scripting language is?
The differences between static and dynamic typing.
What defines a strongly typed language.
The TS optional feature of "inferred" typing.
The differences between interfaces and classes.

These concepts will allow us on our next leg to explore the Union Type and how it interacts with variables, functions, arrays, and interfaces. Hope you enjoyed the read and in the process learned a little something new.

Happy Coding!!!

Sources:

TypeScript docs (https://www.typescriptlang.org/docs)
Oracle docs (https://docs.oracle.com/cd/E57471_01/bigData.100/extensions_bdd/src/cext_transform_typing.html)
Tutorialspoint.com
Sitepoint.com (https://www.sitepoint.com/typing-versus-dynamic-typing/)
Wikipedia.com

Which Route Leads To The Middle?

James F. Thomas — Fri, 24 Jul 2020 13:33:41 +0000

Exploring routes and middleware functions

Introduction

The internet is an environment built on the to and fro movement of words describing persons, places, or things in the world we live in. The seemingly simple task of listening for and responding to those words accordingly can be a daunting duty all by itself. Luckily, we have some key phrases, that move along predetermined paths, being listened for by particular entities, that respond to the keywords, making our online conversations flow smoothly without ever stopping our rants or raves. In this blog, we are going to introduce and explain some of the key players in that data exchange and how they allow us to keep the words flowing as seamlessly as possible.

What path are my words walking?

The path that I am referring to is generally known as a route in computer science. The term ‘route’ basically refers to the entire pathway our words or data must travel in order to reach intended destinations in a network. The ‘route’ encompasses all the stops and tolls along the way to that destination including all players such as a computer, router, server, or database. More specifically, routing or determining the route data will travel and in what way it will be processed, is directly related to the choice of words included in your data package. Remember those keywords I mentioned before, well here they come again, but this time let’s title them requests, or, methods, or verbs. Even though all three choices are interchangeable for the sake of clarity in the remainder of this introduction they will be called verbs.

What keywords should I listen for?

The aforementioned verbs, or specifically HTTP Request methods, are one of the key parts of the requests for information that are sent out along these routes. The request and subsequent response have a particular format that consists of other key portions (headers, data types, data amounts, cookies, etc.) but is not in our focus for today. Each of these HTTP verbs will enact a certain protocol to be performed on the data being sent to an intermediate (player along the route) and then elicit a particular response back to the client or entity having sent the request. HTTP stands for Hypertext Transfer Protocol and the verbs that you choose to use will trigger one of these predetermined transfer protocols. I thought that was an interesting little tidbit for you to start making a full picture with because it helped me. Anyway, there is no limit to the number of verbs that can be defined, meaning in the future our intermediates can be programmed with far more response protocols, but there are 5 that are more commonly used than others: GET, POST, PUT, PATCH, & DELETE.

Who’s listening?

Now that we know what words are being listened for, we need to highlight” who” is listening, and that brings us to those intermediates I mentioned along our route. The specific player I am going to refer to is middleware. Middleware is a bridge between the operating system (“OS” => your computer’s software) your machine is using and the applications (the particular programs being run on the “OS”) that are being run on it. Middleware functions are hidden or abstracted from the user but allow for the coupling of multiple applications enabling control of information and transfer between them. The bridge created by middleware allows applications to receive services and have certain capabilities that are not offered by the operating system of your computer, such as messaging, API management, and authentication. All middleware performs a communicative role between applications and the OS but the specific type will be solely dependent upon the tasks you are performing and the information you want to receive. So let’s take a look at a few basic examples of middleware in action.

var express = require('express')
var app = express()

app.get('/', function (req, res) {
  res.send('Hello World!')
})

app.listen(3000)

In the above example, we are utilizing middleware functionality provided by the express.js framework. The express framework is imported into our project via the require() function and a new instance of the express framework is then instantiated allowing us access to the frameworks methods. The .get() method from express.js allows us to handle requests for information to a certain endpoint, file or server location, etc. The point we are requesting information from is our first input parameter ’/’ while the second is a callback giving our function access to the request and response objects that will contain our data. Res.send() is a method that allows for response in the form a string to sent to our application and displayed on the DOM. The final component of our example is the app.listen() method which binds our application, to listen for connections on a certain host port.

Conclusion

Topic Recap:

We defined a ‘route’
We highlighted HTTP Request Methods
We briefly introduced Middleware
We viewed a basic example of middleware in use

Now that you have been exposed to what a route is, what is sent along with them, and who interacts with the packages sent along each, you can be better identify the bridging elements between your front and backend. For the newbie like me, the ability to read and identify particular parts of the code in projects and documentation will greatly enhance your ability to recognize implementation patterns and employ them on your own in the future.

Happy Coding!!!

Sources:

ComputerHope.com (https://www.computerhope.com/jargon/r/route.htm)
Express Doc (https://expressjs.com/en/starter/basic-routing.html)
Wikipedia (https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods)
Microsoft Azure (https://azure.microsoft.com/en-in/overview/what-is-middleware/)

Show * Database MySQL

James F. Thomas — Mon, 20 Jul 2020 05:07:51 +0000

A brief overview of Database Management Systems (DBMS) and proper syntax while interacting with MySQL.

Before we can get into the specific meat and bones of interacting with the MySQL database, we must first do a little bit of explaining what a database is and why you would ever need to use one. Once we have established our base understanding of what and why the specific ways to interact with the MySQL database will be far more relevant to the future success of your web design projects. So without any more waisted whitespace let’s describe * databases.

What is a database && why use one?

A database is simply a specifically organized assemblage of correlated electronic information that can range from a simple list of items, groups of photos, or even massive anthologies of customer-related information from a large corporation. Typically, the data or information housed within these electronic storage containers is arranged into tables, that then displayed in a column x row format, which makes interaction with these stored values far more economical. A Database is usually employed when multiple processes are accessing and altering data concurrently. The database serves to ensure that these simultaneous inquiries, do not overwrite the changes being performed on either the user or server-side. In the case of someone interacting with database information, this task is called performing a “query” and will require you to use particular verbiage to be successful in the appending or retrieving of desired data.

Are all databases the same?

There are serval different types of databases available for use in your next project, but which one you employ is dependent upon not only some personal choices but also upon the project itself. Some considerations to help guide your database management system (DBMS) choice is:

Data structure (how it looks and is to be presented)
Data consistency (usability of stored data)
Data protection (access and encryption of stored data)
Accessibility/integration (the ability of multiple parties to
access and utilize data)
Interaction efficiency/ scalability (response time to
interactions and ability to change data)
Usability (regards how easy it is to work with DBMS)
Service/implementation costs.

Once you have considered the factors that will guide your choice you can sit down and choose your DBMS type. Here is a list of some of the types of DBMS:

Centralized – database information is stored at a centralized
location
Distributed – database information is stored across varies sites
Personal – data collected and stored on personal computers
End-user – shared data designed for end-users (i.e. different
department managers)
Commercial – for huge data sets, subject-specific, paid access
through commercial links
NoSQL – for large sets of unstructured data
Operational – information related to company operations
Relational – data organized by tables (rows x columns),
predefined category
Cloud – database built for a virtual environment
Object-oriented – a mixture of object-oriented programing and
relations database structures.
Graph – a type of NoSQL database that uses graph theory to store,
map, and query data relationships

With all these factors to consider and types of databases to choose from you can see just how complex this decision of which database to use in your next project can be. So, in that light, I have included links to this very influential information below in my sources section in the hope that you can utilize it to make the most appropriate choice for your project shortly. As for this blog project we will choose the relational database management system specifically MySQL and highlight how to interact with the tabled values stored within this database.

How do I interact with relationally stored data?

Remember earlier we stated that the interaction with stored information was done via something called a query. Well that query, is simply a statement to the DBMS containing keywords along with instructions of how the program should alter data you want to target. Unlike other programing interaction verbiage, you may have encountered in the world of code, I find MySQL syntax extremely readable and more closely resembling human speech than JavaScript or syntax.

Keywords such as SHOW, USE, CREATE, SELECT, DELETE, DESCRIBE, INSERT, LOAD DATA, FROM, WHERE, IN, & ORDER BY are just some of the words and or terms used to interact in specific ways with stored data. Since this is our first encounter with MySQL syntax lets stick with some basic queries and get more advanced in the blogs to come.

Create a new database on server

mysql> CREATE DATABASE test;

View existing databases on the server:

mysql> SHOW DATABASES;
+----------+
| Database |
+----------+
| mysql    |
| test     |
| tmp      |
+----------+

Create a new table

mysql> CREATE TABLE animal (name VARCHAR(20), owner VARCHAR(20),
       species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);

Display the new table you just made

mysql> DESCRIBE animal;
+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| name    | varchar(20) | YES  |     | NULL    |       |
| owner   | varchar(20) | YES  |     | NULL    |       |
| species | varchar(20) | YES  |     | NULL    |       |
| sex     | char(1)     | YES  |     | NULL    |       |
| birth   | date        | YES  |     | NULL    |       |
| death   | date        | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+

Add a value to the table you just made

mysql> INSERT INTO pet
       VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);

These simple queries will get you started arranging information in your database by creating a place for and adding more values to your relational tables. We have only scratched the surface of our journey into databases, so I do hope these 4 examples show just how simple yet readable the MySQL query syntax is to understand and if you choose, put to use.

Topic Recap:

a database is an organized collection of electronic information
many factors influence the type of database you will employ in
your project
interaction with stored data is called a query, queries are
strings
MySQL query syntax is very human-readable

Conclusion:

The modern database has evolved into many different choices that will be affected by a multitude of different factors that should be considered before your project beginning. I suggest a little bit of research into some queries into the syntax used in each one before you make your choice. While your free to choose anyone you want, I like the syntax utilized in the RDBMS MySQL for its human readability and structured displays. These may change with greater experience but for now, MySQL is the base I am banking on. With the information highlighted in this blog, I hope to have armed you with all you need to choose the best DBMS for your next project no matter it is big or small.

Happy Coding!!!

Sources:

MySQL Docs (https://dev.mysql.com/doc/refman/8.0/en/what-is-
mysql.html)
Oracle Docs (https://www.oracle.com/database/what-is-
database.html)
“8 Key Considerations When Choosing a DBMS”
(https://blog.paessler.com/key-considerations-when-choosing-a-
dbms)
“Types of Databases” (https://www.tutorialspoint.com/Types-of-
databases)

Just How Do React.js Components Cycle Through Life?

James F. Thomas — Mon, 13 Jul 2020 03:35:08 +0000

The Lifecycle of React.js components!

A “Lifecycle” in the React.js framework refers to the procedures which correlate to the creation, displaying, monitoring, and removing of a React component. This “Lifecycle” can be arranged into three phases – Mounting, Updating, Unmounting – with various methods available on the React object that empower a developer to observe and alter the component as desired throughout each section of its life. So, let us take a quick peek at the birth, life, death, and the associated tools for each phase in the lifecycle of a React component.

So how do I bring a component to life?

The birthing of a React.js component comes about in the mounting phase of the lifecycle. While it does refer to the first stage of this component's life it can be broken down one step further as well to include different steps according to the type of component you want to bring to life. Before mounting your component, you must consider the desired tasks you want this component to perform on the page, which will influence your choice to initialize the component with or without state. State is an object that is given to your component via the constructor and allows you to set properties on the component that can be monitored for changes.
The state object is a JS object so accessing and setting those properties is done via dot notation. A stateless component also referred to as presentational or dumb, is labeled this chiefly because these components lack a state object and cannot track changes in user information. The stateless components are used to present or display static (unchanging) information. Stateless components due to one thing hence the names presentational and dumb.

Stateless Components

1

//Will display basic stateless React.js element

ReactDOM.render(
<h1> Completely Statless Yall </h1>, 
document.getElementById("htmlLocation")
);

2

const Stateless = () => {
  return (
    <h1>All I Do Is show This Info!</h1>
  )
 }

//Will display basic stateless functional React.js component 
ReactDOM.render(
<Stateless />, 
document.getElementById("htmlLocation")
);

3

class Stateless extends React.Component {
 constructor(props) {
   super(props)

  }
 render() {
   return(
     <div>
      <h1>{this.props.title}</h1>
     </div>
   )
 }
}

var info = {
  title: "I have no state"
} 

//Will display basic stateless React.js class component  
 ReactDOM.render(
  <Stateless title={info.title}/>, 
  document.getElementById("htmlLocation")
  );

Statefull Component

class CodeSchools extends React.Component {
  constructor(props) {
    super(props);
    this.state = {school: "Operation Spark"};
  }
  render() {
    return (
      <div>
        <h1>Welcome To {this.state.school}</h1>
      </div>
    );
  }
}

//Will display stateful React.js class component
ReactDOM.render(
  <CodeSchools/>, 
  document.getElementById("htmlLocation")
  );

React.js elements evolve into components once they begin to accept props object regardless if they have state or not. There is a guiding rule in react.js, that will affect how you interact with the props object that you pass into your stateful components, which all pertain to purity. No matter if the component you declare is of the functional or class designation it must never alter its own props. Remember that in JS a pure function does not alter its inputs and has the same return value for the same inputs, well the same rules apply to any component in the React.js framework.

// impure function example 

function impure(object, name) {
  object.owner = name;
  return object;
}

Side-Information

In React.js the act of placing your initialized component or element on the DOM is called Mounting and is the second part of the first stage of the lifecycle but is usually the term used to describe both actions. So, in the future, if you come across mounting remember you must first create something before it can be placed. For the mounting Phase to be carried out React.js has multiple built-it methods that can be employed to get your component onto the screen but only one is absolutely necessary, and that is rendered (). The render method is the portion of your component that will actually output HTML elements to the DOM, it will examine the components state, and then return elements, fragments(a group of child elements like a list), portals (render components to different parent component), or basic JS data values (strings && numbers). There are additional Mounting phase methods such as componentDidMount (allows you preset JS statements to alter the state of the object once it has mounted), but to best illustrate the key actions of this phase I will stick to highlighting the render() method only.

So, what happens after my component is mounted?

After the mandatory render method has placed your React.js component onto the DOM, you have officially entered the Updating phase of the component’s lifecycle. During the updating phase, the component will be rendered repeatedly according to either a change in the parent components props object or a change in the components local state. These changes represent interactions with the user interface or updating of information from a server that is being visually represented on the DOM. Methods like setState() allow us to interject event listeners into our components that will change the state properties in response to desired events. One common example would be changing DOM information in response to a user click.

class CodeSchools extends React.Component {
  constructor(props) {
    super(props);
    this.state = {school: "Operation Spark"};
  }

/*
created new function which uses setState() method to 
change school name property of state object
*/
  changeSchool = () => {
    this.setState({school: "Hack Reactor"})
  }

  render() {
    return (
      <div>
        <h1>Welcome To {this.state.school}</h1>
<!--added HTML button & click listener responds to user actions-->
        <button type="button" onClick={this.changeSchool}>Change Your School</button>
      </div>
    );
  }
}

There are multiple methods that will allow you to monitor and subsequently change your component in response to that input but setSet() is very simple far simpler for a beginner to grasp in theory and implementation so I kept it simple in the above example. If you just need to know more about component updating you can go to https://reactjs.org/ and read up on the methods shouldComponentUpdate(), ComponentWillUpdate(), and componentDidUpdate() to satisfy your curiosity.

It’s up and updating, so now what?

Once the component is up and responding to user interactions, we can move along into the final lifecycle phase which encompasses removing components from the DOM and so is appropriately named in direct opposition to our first phase. We are now in the Unmounting phase of the react.js component lifecycle which is home to one solitary built-in method, componentWillUnmount(). Following the appropriate naming of the phase, this method’s only job is to remove a component from the DOM in preparation for being destroyed. Once a components instance is taken off the DOM or unmounted it will never be rendered again. In light of this fact componentWillUnmount() should not utilize the updating phase method of setSet() because the component will never be used again and therefore will have no state to set.

//This function will alert you right before the component is removed and destroyed 

componentWillUnmount() {
  console.log('will unmount');
}

ComponentWillUnmount() is the final function to be called in a chain of events prior to your component being removed from the DOM. It can be used to simply alert you of the component’s removal or be set to do away with or cancel any elements as well as timers set in the mounting phase by built-in method like CompentWillMount() or CompentDidMount(). Since we are keeping this exploration of the lifecycle phases as a basic overview, I feel simply alerting you to the existence of the method is enough to properly demonstrate each phase and some of the methods employed in each one.

Conclusion

The lifecycle of any component in React.js is split into 3 distinct phases which are all eloquently named for your ease of recall. If you think about them logically you will never miss one in the set when asked. First, create it and put it on the screen. Second, monitor and change accordingly. Third and final, remove and destroy when done.

Topic Recap:

Components are not components until the accept props
Components need to be pure not altering inputs, returning the
same value with same input
The component Lifecycle is composed of three main parts:
Mounting, Updating, Unmounting
Unmounting has only 1 built-in method for that lifecycle phase

If this overview was not enough to elucidate the cycles of a react.js component’s life for you, check out the links below for a deeper dive into aspects and methods that are coupled with each stage. Until next time and topic, Happy coding!

Sources:

W3schools.com (https://www.w3schools.com/react/react_lifecycle.asp)
Edmond Atto (https://medium.com/the-andela-way/understanding-the-fundamentals-of-state-in-react-79c711be677f)
React.js docs (https://reactjs.org/docs/components-and-props.html)
tutorialspoint.com (https://www.tutorialspoint.com/react-js)

Your Gonna Need Some Scripts To Go With That JavaScript!

James F. Thomas — Mon, 06 Jul 2020 01:53:06 +0000

If you're new to programming like me, then you may only have minimal experience with the three pillars of web design, HTML, CSS, and JavaScript or JS. For your skills to advance to the next level you must understand how these pillars support the foundation on which your web sites and applications will be built. This blog will quickly highlight the connection between HTML and JS, by explaining the placement of the HTML element known as the <script> tag.

Why you want JS in your HTML?

JS is a scripting language that is used to provide interactivity to your formerly static webpages. This means that the page you build will have programmed actions or reactions to client-side interactions with page components. Even simpler, if it moves, updates, scrolls, toggles, turns, changes color, or appears out of nowhere chances are JS is behind the scenes getting work done. So here the takeaway is, JS makes your page and apps move.

How do You get it in there?

Although there are two branches there is only one root. No matter how much or exactly where you want to put the JS into your HTML file, it will always have to go inside of a <script> tag. The script tag is a dedicated HTML element that is used to run executable code for client-side interactions. When you want your page to react-to or retrieve-from the person visiting the site or using your app, the code that will enable this ability will be embedded inside the script tag like so <script>executable code </script>.

script tag example

<!-- This will display an alert pop up with the current date inside the string value -->
<script>
    let today = new Date();
    alert(`Today is ${today}, and everything is all good!`)
</script>

So, we just put the JS in the script tag?

Well yes but no. The <script> tag is your link between the two languages (HTML && JS) but there are two actual ways in which the code can be executed. You can either write the code you want to interact with HTML elements right into your code, or you can write all the code you want to interact with your page elements in a separate file and connect them to your HTML page via a link. These methods are knowns as in-line vs cached. Choosing the cached option, a separate file containing all your JS code would probably be the best if you plan to run your JS code on multiple pages, as it would save you from having to duplicate the inline scripts for each page that you create.

Inline

<!DOCTYPE html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Code Examples</title>

  </head>
  <body> 
  <!-- This inline script will create a <H1> element on top of page when loaded -->
  <script>
      document.write("<h1>Hello World!</h1>")
  </script>


</body>  
</html>

Cached

<!DOCTYPE html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Code Examples</title>
    <!-- This is an example of linking HTML to extrnal file -->
  <script src="myJavascriptFile.js"></script>
  </head>
  <body> 


</body>  
</html>

Where is the best place to put my scripts and why?

Making the choice of where to place your script tag is always up to the programmer but knowing some background information on how the code interacts with the page elements will help you make an informed decision. The most traditional placement of the <script> tag is within the <head> section of the HTML document which is at the top of the document preceding the body. Following our most traditional spot within the <head> section, would be the placement of the <script> tag as the last element in the body section prior to the closing </body> tag. If your page is not intensely interactive or you wish to only add small dynamic features to some of its components, then adding your inline JS at the top or bottom of the page is not going to noticeably affect the speed of your page load.

Script Tag at Top of File

<!DOCTYPE html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Code Examples</title>
  <!-- Placing the script at top of your JS file-->
  <script src="myJavascriptFile.js"></script>
  </head>
  <body> 

</body>  
</html>

Script Tag at Bottom of File

<!DOCTYPE html>
<html lang="en-US">
<head>
    <meta charset="UTF-8">
    <title>Code Examples</title>
  </head>
  <body> 

    <!-- Placing the script at bottom of your JS file-->
    <script src="myJavascriptFile.js"></script>
</body>  
</html>

How JS affects the speed of your load is due to the fact that the DOM will pause loading HTML elements when it encounters JS code in the <script> tag. It will then resume downloading the remaining page content once the JS code has been interpreted. Of course, if you have numerous elements on the page, each with their own <script>’s this will drastically slow the loading of the page and make for a dull user experience. At this point, it is best practice to use the <script> to link your page to an external file containing all JS code intended for your site. Another small caveat to the placing the <script> at the bottom of the file is to avoid loading errors. JS code can NOT interact with HTML elements if they are not loaded, so again placing your <script> tag at the end of the <body> will help you avoid these communication breakdowns.

One Quick fix for this delay in page parsing, or loading of page elements, would be to add the defer attribute to the <script> tag. When the browser encounters a tag with this attribute it will wait to execute the code until the document has been fully loaded.

Defer attribute

<!-- Add defer attribute to signal that script content shouldn't be run unitl page loded -->
    <script defer></script>

So, remember:

JS code can be entered into your projects directly => Inline or indirectly => Cached
<script> tags are the route to including JS in your HTML files
<script> placement affects browser page parsing, so place mindfully
When in doubt Cache the code out

Although it is a simple choice, it can be one that vastly affects user experience on your page so make sure to choose your placement wisely. Your goal should be to have as smooth and short of load time as possible to ensure those users continue to come back and tell all their friends about the wonderful thing you have created. Thank you so much for your time, I hope that you learned something, and now that you know where your JS should go, knowing is half the battle!!!

Happy Coding!!!!

Sources:

https://www.w3schools.com/
https://developer.mozilla.org/en-US/
https://www.tutorialspoint.com/javascript/javascript_placement.htm
Javascript & Jquery interactive front-end web development by Jon Duckett

Scopes & Closures - A Metaphor

James F. Thomas — Sun, 28 Jun 2020 19:25:19 +0000

Introduction

When I first began learning the ins and outs of basic coding, which I am still in the process of doing, the concept of “scopes & closures” was one that took me a minute to understand. I loved declaring variables, assigning values, and making things appear with console.log() statements. I truly felt like a wizard, creating my incantations, and watching them play out before my eyes. But once the tasks began to include loops and functions the concept of scopes appeared, and all the while threw me for a loop. So, I came up with a metaphor that helped me scope out the situation.

Scopes

What exactly is a scope?

More technical definitions of scope involve wording like, “the context of execution” (MDN) or “the level of accessibility” (W3Schools), but for me, the easiest way to explain scope to a newbie would be “the area of your code in which the variable or value was created”. I found this to be a simple and visually applicable definition that allowed me to start really grasping scopes and how they build upon or within one another. Being able to absorb the concept of scopes is the only way to move into closures, so let’s first expand a bit more on the types of scopes a newbie will need to comprehend.

Scopes come in two varieties:

The first and simplest to understand is the “global”. To the beginner “global scope” will encompass any variables or functions in your code that are not inside another function or conditional block. For my newbie’s let’s get visual, look at your code and if it’s not housed inside anything else, that would be the global scope.

// globally declared items 

let name = "James F. Thomas";

let age = 37;

let globalFunc = () =>{
  console.log("My First Blog Post")
}

Yes, there are instances where an undeclared variable housed within a function will be automatically turned into a global variable, but that is beyond the basic overview of this blog. Remember we are keeping to the lowest level of abstraction for this one.

//undeclared variable in function

let globalExample = () =>{
  message = "My First Blog Post";
  console.log(message);
}

The second scope type would be known as “local”. A “local scope” is generated when you initialize a variable or a function inside of another function, conditional statement, or loop code block. Placing the variable or value inside the curly braces of those previously listed code components will render them inaccessible or invisible to any components not in the same or local scope.

//local scoped variables

let outerFunc = () => {
  let localVariable = "I'm local"
}

Locally scoped variables or values are considered children of the global scope in which they were created. It is with that relationship they will retain access to any globally located code components and be able to use them as desired. The technical term for this ability is “lexical scope”. This access continues with each nested function but is only one way in nature. So that means as we go from parent to child to grandchild each inner level can access outwardly but not vice versus. Kids access parent values, but not the other way around, and grandkids of course can take from both.

let name = "James F. Thomas";

let globalFunc = () =>{
  console.log(name)
}

globalFunc(); //prints "James F. Thomas"

This child-parent interaction or “lexical” relation between local and parent code components is just what we needed to understand to find closure. Trust me that will be funny in a few lines.

Closures:

A “closure” describes the access a child element has to values housed in its parent or “lexical” environment. A closure is created when a function is housed within another and refers to its parent variables.

let outerFunc = () =>{

  let message = "I'm local"

  return function childFunc(){
    console.log(message);
  }; 

};

outerFunc()(); //prints "I'm local"

Ok cool, so why is that important? Those variables and values not within the closure will only exist at runtime, so the closure or inner function will allow for future access even after the outer function has returned. So basically, a closure creates a type of barrier around the values it has accesses to and then allows you to store access to them even after the outer function has been run.

Conclusion:

Even though that all makes sense to me NOW, I had to come up with a more relatable explanation for these concepts during my first encounter with this topic.

So, in my head:

The global scope is an entire city, and any variable or function declared in it is a city service, and city services are available to all residents. Local scopes are gated communities within the city, with their own services, only available community to residents. Some subdivisions are huge and can have other smaller gated subdivisions inside of them, with their own services. Residents can of course leave their communities and access city services like the bus, but the bus does not run into any of these gated communities. For closures, I thought about the gated communities having their own service warehouses, that supplied goods and kept records, but the only way for non-residents to receive either was to make calls from the distribution center located in the city downtown. Lucky for us they are open 24 hours a day.

Yeah I know it’s silly but it worked for me, and maybe it will work for you.

Happy Coding!!!

Forem: James F. Thomas

Just Which Way Does The Auth Flow? #3

The Switch In The Flow From Authenticate to Authorize

Introduction:

What is a user session?

Code Example: logOut() function invocation in route handler

So where does serialize fit in?

Code Example: Passport.js serializeUser() function

Code Example: implementation of Passport.js deserializeUser() function

Conclusion:

Just Which Way Does The Auth Flow? #2

Requesting & Utilizing User Information To Authenticate

Introduction:

What happens between redirects and the auth request?

Code Example: access token

What happens after we get the token?

Code Example: Passport.js OAuth strategy configuration

Code Example: Passport.js login function

Conclusion:

Just Which Way Does The Auth Flow?

The Passport Authentication Control Flow

Introduction:

What does is it mean authenticate?

What is passport.js and why use it?

Is he ever going to reveal the original question?

passport-setup.js

Conclusion:

Happy Coding!!!

Unifying our basics of TypeScript

Exploring the "Union Type" and how it is applied.

Introduction:

What is the Union Type?

JS code example:

TS code example:

What else can I unite in TS?

simple data type example:

mixed data type example:

complex data type example:

Conclusion:

Learning about a new Type of Script

A Brief Introduction into the language of TypeScript:

What is typescript?

Example 1

Example 2

Example 3

How Typescript interacts with complex data types?

Example 4

Example 5

Conclusion

Which Route Leads To The Middle?

Introduction

What path are my words walking?

What keywords should I listen for?

Who’s listening?

Conclusion

Happy Coding!!!

Show * Database MySQL

What is a database && why use one?

Are all databases the same?

How do I interact with relationally stored data?

Topic Recap:

Conclusion:

Just How Do React.js Components Cycle Through Life?

The Lifecycle of React.js components!

So how do I bring a component to life?

Stateless Components

1

2

3

Statefull Component

So, what happens after my component is mounted?

It’s up and updating, so now what?

Conclusion

Your Gonna Need Some Scripts To Go With That JavaScript!

Why you want JS in your HTML?

How do You get it in there?

script tag example

So, we just put the JS in the script tag?

Inline

Cached

Code Example: `logOut()` function invocation in route handler

Code Example: Passport.js `serializeUser()` function

Code Example: implementation of Passport.js `deserializeUser()` function