DEV Community: alelee93

JavaScript Fetch API

alelee93 — Wed, 20 Jan 2021 00:48:13 +0000

The foundational languages of websites are HTML, CSS, and Javascript.

If we were to compare a website to a house, then
HTML (Hypertext Markup Language) would be the concrete blocks making up the house and providing it with a stable structure.
CSS (Cascading Style Sheets) would be the color and molding of the house, enriching its space through eye-catching design.
And finally JAVASCRIPT would be the electrical wires of the house that bring it to life.

This post will focus on Javascript, and more specifically, the Javascript “FETCH API”

Before we begin, let’s take a slightly deeper look at Javascript.

Javascript is a programming language initially designed to interact with elements of web pages. When a web page is loaded, once the HTML and CSS have been downloaded, the Javascript in the web browser executes the JavaScript code. The JavaScript code then modifies the HTML and CSS to dynamically update the user interface.

Ok so why is the FETCH API important? What does it do?

The fetch API is important because it allows us to make HTTP requests to servers from web browsers.

How does it work?

WE START BY SENDING A REQUEST
The fetch() method requires one parameter to work, which is the URL of the resource that you want to fetch.

WE GET BACK A PROMISE
The fetch method returns a Promise containing the response.

WE HANDLE THE PROMISE
You can use the then() and catch() methods to handle the promise

THE RESOURCE IS AVAILABLE
When the request completes, the resource is available and the Promise resolves into a Response object.

here is an example of a fetch request:

getTopics = () => fetch(this.root+"/topics").then(res => res.json())

Sessions

alelee93 — Wed, 26 Aug 2020 02:34:19 +0000

HTTP (Hypertext Transfer Protocol) is how data is delivered and exchanged on the World Wide Web. HTTP is also stateless, which means that a user’s state is not preserved or “remembered” from page to page. This is problematic if you want your app to display different information depending on a user’s profile. One example of this could be an e-commerce website, where you want to keep track of the items in a shopping cart for all your different users. It would be very frustrating for your users to add five items to their cart, go to the next items page and then all of a sudden lose all their carefully picked cart items. The e-commerce store owner just lost a potentially big sale!

So, if HTTP is stateless how can apps remember a user’s state? Enter Sessions and (Browser) Cookies

What is a (Browser) Cookie?
Cookies are key-value data pairs that are stored in the user’s browser (hint: users can access them!) until they reach their specified expiration date. You could store shopping cart information or even passwords there, but that would be a really bad idea.

But why should I not store passwords?
Sensitive information (like passwords) should not be stored in a cookie as people could access that information to then manipulate it and potentially commit fraud.
Ok then why should I not store shopping cart information?
Storing information that needs to be persisted across browser sessions (like shopping carts) shouldn’t be stored in a cookie as a user could clear their cache and lose their shopping cart information.

If you shouldn’t store passwords or shopping cart information in a cookie, then why are we talking about cookies? What are we supposed to store there? Enter Sessions.

What is a Session?
A session represents all the things that a user does (and you have chosen to remember) usually until the browser window is closed. Think about this, you log into your Amazon Prime Account, add some items to your shopping cart, make a purchase, and then log out. All those pages that you visited before logging out were part of the same session.

So What is the relationship between a Session and a Cookie?
Rails stores a secure and encrypted cookie on the user’s browser containing their session hash. This session hash expires when the browser is closed.

Visually, this is how the session is set (usually in your users_controller):

Set a session:
session[:user_id] = user.id

End a session:
session[:user_id] = nil

Visually, this is how you retrieve information about a user through a session (usually in application_controller)

Retrieve the current user, or create a new one depending on whether a session already exists:
@user = User.find_by(id: session[:user_id]) || User.new

Find out if the user is logged in:
!!session[:user_id]

At this point you may be wondering whether a session and a cookie are the same thing or why we need both a session and a cookie to maintain information.

Well, for starters cookies are only stored on the client-side (on the users browser). A Session key gets stored on the client (through the cookie), and the Session gets stored on the server. This should make sense - the server has the session information (how many items a user added to their cart for example), but for the user to access that information, we need them to use a key, this key would be the unique session id, which is stored on the user’s computer and returned with every request to the server.

Another difference is that the cookie expires depending on the lifetime you set for it, but a Session ends when a user closes his/her browser or when you clear it (like for example when a user logs out)

Lastly, the maximum cookie size is 4KB, however in a session you can store as much data as you like.

Association Promise

alelee93 — Tue, 30 Jun 2020 19:47:29 +0000

An association is a connection between two Active Record models that makes common operations simpler and easier to code. Associations are implemented using macro-style calls, so that you can declaratively add features to your models.

Two important assumptions are made when you create an association:

The class of the model your association points to is based directly off of the name of the association
The foreign key in any belongs_to relationship will be called yourassociationname_id.

If you deviate from these defaults, then you need to let Ruby know what class and foreign key to look for.

Here is an example of the assumptions made:

#app/models/message.rb
Class Message < ActiveRecord::Base
belongs_to :user
End

→ The implied promises that we are making through these associations are:

The class for the belongs_to association is named class User (that is, based off of the name of the association)
The foreign key in the belongs_to relationship will be called user_id (that is, the messages table includes a user_id -foreign key- column)

#app/models/user.rb
Class User < ActiveRecord::Base
Has_many :messages
end

→ The implied promises that we are making through this association is that:

The class for the association is named Message (that is, based off of the name of the association)

Through this scenario, you could call User.first.messages and get all the messages from the first user. How? Ruby looks for the user_id (foreign key) in the Messages table and returns all the messages with the user_id of the first User.

Now, what if we’d like to deviate from this implied promise?

For example what if we are creating a social media app and we would like our users to be able to follow other users?

Ok so first of all we would need a following_users table with at least two columns: following_id and follower_id. These columns will allow us to keep track of all user followers and followings. But how do we set up the associations in our classes so that when I start following someone, that someone shows that I am following her/him?

First, we need a class FollowingUser that inherits from ActiveRecord::Base and has the following associations:

Note that instances of this class would be the rows of our following_users table, which is our join table.

Class FollowingUser < ActiveRecord::Base
Belongs_to :follower, foreign_key: ‘follower_id’, class_name: ‘User’

Belongs_to :following, foreign_key: ‘following_id’, class_name: ‘User’
end

So here we specify the foreign key and class name so that Ruby knows that we want to deviate from the implied promise. We are telling Ruby to look for the class User to build the association and to use follower_id and following_id as the foreign key to match up against user_id (in the User class) to build the association.

What would be the implied promise if we wouldn't have included a specific foreign key and class_name?

If we didn't include a foreign_key, and class_name, then Ruby would assume that we have a class called Follower and Following and that the foreign key in FollowingUser that we want to use is follower_id and following_id.

Once that is done, we would need to add associations to the User model. Now, keep in mind that we are building a relationship between the same type of model - users can follow other users. This means that we will need to specify both associations in our User model, but name them differently - the implication here is that we will need to specify in our has_many association what the name of the foreign_key will be.

has_many :following_users, foreign_key: 'follower_id'

has_many :follower_users, foreign_key: 'following_id', class_name: 'FollowingUser'

has_many :following, through: :following_users, foreign_key: 'following_id', class_name: 'User'

has_many :followers, through: :follower_users, foreign_key: 'follower_id', class_name: 'User'

Here's a line by line explanation of the code shown above:

Line 1: Here we are saying that a user has_many :following_users (implied promise → there is a class named following_users that we will use to build this association, new explicit instruction → use the following_id column as the foreign key to set up this relationship. If we call User.first.following_users, then Ruby will look for all rows in the following_users table where follower_id = 1.
Line 2: Here we are saying that a user has_many follower_users, we are telling Ruby to build this association with the FollowingUser class and the following_id as foreign key.

Now on the next two lines we are building the association between the same User model.

Line 3: Here we are telling Ruby:
Build a macro :following for the User class Build the relationship for this macro on the same class_name 'User'
To build this relationship, use as foreign_key the follower_id, which is available through the following_users association.
Line 4: Here we are doing exactly the same thing as on point three, except that we are now building the process for followers.

The Shebang #!

alelee93 — Mon, 27 Apr 2020 01:15:22 +0000

Lets assume you have a Ruby file ./program with the following line of code:

puts 'hello world'

If you run ./program in your terminal, your computer would be agnostic to what type of program you are trying to run. For your computer ./program might be a Bash script, Perl, Python, or an actual binary executable. This is when shebangs become relevant.

For the terminal, the shebang acts as a hint on how to execute a file if you don't explicitly tell your computer what to use to execute such file. For example, if you run ruby ./program, you are explicitly telling your computer to use ruby to run your program, but if you simply run ./program, your computer would know to use ruby as the interpreter if your program includes a shebang.

Tip: Note that having a shebang at the beginning of your file would not affect the program itself.

So what is a shebang?!

This character sequence is called a shebang:

#!

and it is used to tell a Unix-like operating system (such as OS X or Linux) which interpreter to use to parse or execute a file.

A #! (shebang) is followed by an interpreter directive path, which specifies the program to be run.

See below the structure of a shebang interpreter directive:

#![path to your interpreter directive] argument`

Note that your shebang interpreter directive should be the first line of your script.

There are 2 ways to use the shebang directive and set the interpreter:
1) Using the absolute path
2) Using the env directive

Here is an example using an absolute path:

#!usr/bin/python

In this example, your computer would execute the file using python.

Here is an example using the env directive:

#!/usr/bin/env ruby

In this example the env command would locate the path to the ruby interpreter by itself, whether it is located in the /usr/bin/directory, or somewhere else, you would not need to find the absolute path by yourself, instead the env program would figure it out at runtime.

Tip: Using the env command makes your program more portable.

Why Software Development?

alelee93 — Mon, 16 Mar 2020 01:59:04 +0000

I decided to start learning software development to become a builder of useful programs. I think that being able to understand how programs are built or being able to develop programs from scratch is a very powerful - and fun - skill that is needed in any startup or large company in the modern world. I'm excited to be living in a time where relevant tech companies had their starts in a dorm with just one computer. It's an interesting time to be living in, and I'm learning how to code so that I have the necessary toolset to make the best out of it.