DEV Community: Eric

The very basics of Active Record Validations

Eric — Wed, 22 Jun 2022 19:38:52 +0000

Active Record Validations are a feature of Active Record that gives us the ability to validate data, before it reaches our database. This has a few benefits, but most importantly, we can make sure our database doesn't have unwanted values that could break our application later on.

This guide will attempt to explain how Active Record Validations work, using the Active Records Validations guide as a general reference.

Why use validations?

First of all, why should we use validations? As alluded to before, validations are vital for making sure that all the values in our database are exactly within our expectations.

According to the Ruby on Rails guide:

Model-level validations are the best way to ensure that only valid data is saved into your database. They are database agnostic, cannot be bypassed by end users, and are convenient to test and maintain.

For example, if our database has a column for phone numbers, we know (within reason) that there every number should by 10 digits long (including area code) and by made up of only digits (0-9). So, before creating a new phone number in our database, we should validate it first. If it's invalid, we should reject it.

By making sure our database is valid, we can prevent potential bugs down the line.

Validation Helpers

Validation helpers are the meat of Active Record Validations. These are pre-defined helpers that provide a set of built-in validation rules. We define our validations directly in the model class. With just the built-in validation helpers, we should be able to handle most, if not all, of our necessary validations.

Some of the most useful helpers include: presence, uniqueness, length, comparison, and format. The full list of built-in validation helpers can be found here.

presence

Presence validates that the specified attribute(s) are not empty (nil or an empty string: ""). It is, by far, the simplest helper, as well as, one of the most common helpers.

  class Person < ApplicationRecord
    validates :name, :phone_number presence: true
  end

Now, Active Record won't allow us to create a new person unless there is a name and phone number present. Notice, by the way, that we define our validations directly in each model.

Alternatively, the helper absence does the opposite, ensuring that one or more attributes are absent before saving a new record.

uniqueness

This helper ensures that each value of one or more attributes are unique. One of the most obvious use cases for this would be to ensure every created user had a unique email address.

  class User < ApplicationRecord
    validates :email uniqueness: true
  end

length

This helper is exactly what you think is; it validates the length of the attribute value. There are a few different options available with length, to be as precise as you'd need to be. They are: minimum, maximum, in (or within), and is.

  class Customer < ApplicationRecord
    validates :phone_number length: {is: 10}
  end

For more info about the other options, visit the Ruby on Rails guide, here

comparison

Comparison compares two values and will only validate if the comparison is true. Like length, comparison has several options to choose from. They are: :greater_than, :greater_than_or_equal_to, :less_than, :less_than_or_equal_to, :equal_to, and :other_than.

  class Employee < ApplicationRecord
    validates :hourly_wage comparison: {greater_than_or_equal_to: :minimum_wage}
  end

This examples validates that each employee's wage is never below minimum wage.

format

The last validation helper in this blog is format. Simply put, it validates that a attribute value matches a pre-defined regex pattern. This is useful for making sure an email address or a password follows a specific format.

  class User < ApplicationRecord
    validates :email format: {with: /^\w{2}\w*@\w+\.\w+$/}
  end

format basically allows you to be as flexible with your validations as regular expressions are. The only drawback is having to use regular expressions...

Conditional Validation

To make our validations even more dynamic, Active Record gives us the option to run our validations based on specific conditions that we can define. To add conditions to your validations, simply tag on an :if or an :unless, with the name of a function that evaluates to true or false, in symbol format. I like the example code for custom validations in the Rails docs:

  class Order < ApplicationRecord
    validates :card_number, presence: true, if: :paid_with_card?

    def paid_with_card?
      payment_type == "card"
    end
  end

In the example above, each payment has a "payment_type" associated with it. When using a credit card, we need to use the credit card number to process the payment. It would be wise to validate the credit card number before doing so, to ensure that only cc numbers in a specific format get processed, or else, the payment could fail and that is not ideal.

Adding conditions to our validations greatly enhances our ability to write complex validations in a easy to read manner. With what we now have, we can setup just about any validation we can think of with the Rails built-in validation helpers. But, as an alternative to using the built-in helpers, we can define our own validation methods that will even do the few things the built-in helpers cannot.

Custom Validations

Although the built-in validation helpers that Active Record gives us are awesome, we don't have to use them at all, and, in fact, won't always be enough for the type of validation we need. Instead, we can define our own custom validations to do any sort of validating we could possible desire. Custom validations are generally used for more complex validations while the built-in helpers are efficient for using more straight-forward validations, as their name's imply.

Here's an example of a custom validator that fails if it's not the first of the month:

  class DeliveryOrder < ApplicationRecord
    validate :promise_time_cannot_be_in_the_past

    def promise_time_cannot_be_in_the_past
      errors.add(:promise_time, "cannot be in the past") if self.promise_time < Date.today
    end
  end

The example above is for a delivery order at a restaurant or whatever. There's no way the we could possibly promise to deliver anything that is before the order was placed. This validation ensures we won't have to deal with this later down the line.

This could be written using the built-in validation helpers, but, for whatever reason, I decided I liked this better. Without having to understand the logic behind the validation, it's still obvious that this model is validating that the promise time cannot be in the past, as the name of the validation method eludes to. I guess it's up to preference for which way you'd like to use.

Conclusion

In the article, I've only covered the absolute basics of Active Record Validations. The most glaring area I omitted was error handling. If you'd like to know more (and I encourage you to do so), please check out the main page on validations for Active Record here. The other bigger topic I didn't cover were the "Common Validation Options". They add a few additional ways to make your validations even more dynamic.

Just like everything else in Rails, once your comfortable writing validations and don't need to flip back to the docs regularly, you can write very easy validations in only a few lines of code that are basically human readable. It's pretty incredible.

Resources & Acknowledgements

This article basically cherry-picks and summarizes parts of the guide on Active Record Validations from the Ruby on Rails guides and can be found here.

Besides the Rails guides, these two YouTube tutorials were extremely helpful in understanding how validation worked in Rails:

That's it. Thanks for reading. Go Twins!

Associating Distant Table with Active Record

Eric — Thu, 14 Apr 2022 18:02:52 +0000

With Active Record, database tables can be connected together through Active Record association, allowing us to easily work with our database. Consider the diagram below:

By creating different associations between these tables, Active Record will give our models access to additional methods, making it much easier to work with our database. In the end, I'll be able to interact with my tables like so:

playlist = Playlist.first

p playlist.name # => "Very Best of the 90's"
p playlist.tracks.sample.name # => "Step By Step"
p playlist.albums.sample.name # => "Siamese Dream"
p playlist.artists.sample.name # => "Alanis Morissette"

p playlist.albums.sample
          .tracks.first
          .playlists.sample
          .artists.first.name # => "Fleetwood Mac"

Setup

In the interest of making this article as short as possible, I won't go over how to setup Active Record or how to create the initial database tables & table models. To start off, I have a database schema that looks like so:

# db/schema.rb

# ...

  create_table "albums", force: :cascade do |t|
    t.string "name"
    t.datetime "release_data"
    t.string "img_url"
  end

  create_table "artists", force: :cascade do |t|
    t.string "name"
    t.integer "popularity"
    t.string "img_url"
  end

  create_table "playlists", force: :cascade do |t|
    t.string "name"
    t.string "img_url"
  end

  create_table "tracks", force: :cascade do |t|
    t.string "name"
    t.integer "duration_s"
  end

Setting Up Associations

Notice the diagram at the beginning of this article. The "Playlists" table and "Artists" table are nowhere near close to each-other, but by using Active Record associations, we can directly access all the artists represented in a specific playlist by simply calling .artists on an instance of Playlist.

playlist = Playlist.first
artist = Artist.first

p playlist.artists.pluck(:name).uniq
  # =>  ["Post Malone", "Kid Cudi", "Mr. Probz", "Miley Cyrus",
  #       "Fleetwood Mac","The xx", "Elton John", "Wiz Khalifa"]

# It works both ways
p artist.playlists.pluck(:name)
  # => ["Oldies", "Classic Hits"]

Quick Explanation for `#pluck`:

#pluck is very useful method, provided by Active Record. It return an array of values when called on a collection of records. apidock.com says this about #pluck:

"Use #pluck as a shortcut to select one or more attributes without loading a bunch of records just to grab the attributes you want."

I've created four models (so far) representing the Playlists, Albums, Artists, & Tracks tables.

Now, I'll create the table associations for each model, starting with Artists. Let's look at our database diagram again:

Thinking it through, it seems reasonable to say that each artist would have many albums. So inside our artist model, we can describe that association with a has_many macro, like so:

# app/models/artist.rb
class Artist < ActiveRecord::Base
  has_many :albums # <- plural
end

And, inside our album model, we can reciprocate this association by using a belongs_to macro:

# app/models/album.rb
class Album < ActiveRecord::Base
  belongs_to :artist # <- singular
end

Note - make sure to use the correct singular/plural form of the table name when creating the associations.

Continuing, each album has many tracks & each track belongs to a single album (in our case). Adding to our album model:

# app/models/album.rb
class Album < ActiveRecord::Base
  belongs_to :artist
  has_many :tracks
end

And inside the track model:

class Track < ActiveRecord::Base
  belongs_to :album
end

Before going any further, I want to check if what we have so far works. But, first, I need to add foreign-keys to my album & track models, by creating a new migration.

#db/migrate/20220402193754_add_foreign_keys_to_albums_and_tracks.rb
class AddForeignKeysToAlbumsAndTracks < ActiveRecord::Migration[6.1]
  def change
    add_column :albums, :artist_id, :integer
    add_column :tracks, :album_id, :integer
  end
end

Now, I can retrieve all an artist's tracks by calling:

Track.joins(album: [:artist]).where(:artist => {:name => "Nine Inch Nails"})`
  # returns an array of all tracks by "Nine Inch Nails"

Note - #joins & #where are finder methods, provided by Active Record, for querying a database. You can learn more about them here.

Everything is good, so far, let's continue.

Our last direct association is a different from the previous two. Continuing to think it through, each playlist has many tracks, but each track could also have many playlists. In order to represent this relationship, we need to create a new table to join together our tracks table & playlists table (see diagram above).

Creating a Join Table

In a new migration file, I'll put the following:

class CreatePlaylistTracksTable < ActiveRecord::Migration[6.1]
  def change
    create_table :playlist_tracks do |t|
      t.integer :playlist_id
      t.integer :tracks_id
    end
  end
end

This will create the joins table to link our tracks & playlists tables together in a many-to-many relationship. Next, I need to create a new model for this table.

class PlaylistTrack < ActiveRecord::Base
  belongs_to :playlist
  belongs_to :track
end

With that, my entire database is now connected. I can now chain together methods to make queries like...

artists = Artists.joins(album: [tracks: [:playlists]])
                 .where(:playlist => {:name => "Very Best of the 90's"})

which should give me a list of artists represented in the playlist, "Very Best of the 90's".

I should now be able to retrieve any data I'll need from the database. But the query above is kinda ugly. I'd rather write something like this:

artists = Playlist.find_by(name: "Very Best of the 90's").artists

In order to be able to make this call, I need to set up some more associations.

Wrapping Up Associations

To supercharge my database queries, I added a few more associations to my models:

# app/models/playlist.rb
class Playlist < ActiveRecord::Base
  has_many :playlist_tracks
  has_many :tracks, through: :playlist_tracks
  has_many :albums, through: :tracks
  has_many :artists, through: :albums
end

# app/models/track.rb
class Track < ActiveRecord::Base
  belongs_to :album
  has_one :artist, through: :album
  has_many :playlist_tracks
  has_many :playlists, through: :playlist_tracks
end

# app/models/album.rb
class Album < ActiveRecord::Base
  belongs_to :artist
  has_many :tracks
  has_many :playlists, through: :tracks
end

# app/models/artist.rb
class Artist < ActiveRecord::Base
  has_many :albums
  has_many :tracks, through: :albums
  has_many :playlists, through: :tracks
end

With this setup, I can now make super simple queries like so:

artists = Playlist.find(10).artists.pluck(:name).uniq

This will return a list of all the artists in a playlist. That's pretty cool.

Conclusion

And that's it. Now my queries are supercharged and I can write methods that work with this setup to make complex queries a breeze.
Thanks for reading!

I Made a Hook!

Eric — Sun, 16 Jan 2022 03:51:04 +0000

Introduction

In 2021, you can't learn React without learning about Hooks. According to the authority, React:

Hooks are functions that let you “hook into' React state and lifecycle features from function components. ...A custom Hook is a JavaScript function whose name starts with ‘use’ and that may call other Hooks.

In other words, Hooks are functions that are able to use React features and syntax, most notably, the built-in Hooks useState & useEffect.

In my VERY early journey into learning React, Hooks have been useful to me for separating complex or distracting logic from React components into their own files/functions, which cleans up my components. I like this because it makes the more important logic standout and my components easier to comprehend overall. Refactoring custom Hooks into their own files also makes them reusable throughout my entire application. As my applications grow, this versatility will become more and more critical in keeping my code DRY and easy to comprehend.

One almost unavoidable task when building an app is requesting data with a fetch request. For my second of five projects in my coding bootcamp, I’m building a restaurant point-of-sales (POS) application. Important setup data, like a menu or a list of saved customers, are stored in a json file that requires a fetch request to retrieve and use. For this article, however, I'll be using the POKEAPI in my examples, if only to make them easier to follow. You can check out my restaurant POS here if you'd like.

First, I'll quickly explain how I make basic fetch requests in React, without using any custom Hooks. After that, I'll demonstrate how I created a custom Hook to do the same thing, as well as, go over their differences.

Making a basic fetch request (in React)

Below is an example of how to make a fetch request inside a React component and store the results/error within a piece of state.

import { useState, useEffect } from 'react';

const POKEMON_URL = 'https://pokeapi.co/api/v2/pokemon';

export default function App() {
  const [pokemon, setPokemon] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    setIsLoading(true);
    fetch(POKEMON_URL)
      .then(res => res.json())
      .then(pokeData => setPokemon(pokeData))
      .catch(err => {
        console.error(err);
        setError(err);
      })
      .finally(() => setIsLoading(false));
  }, []);

  // Example usage of pokemon data
  const pokemonCards = pokemon.results.map(poke => {
    // function logic...
  })

  return (
    // Conditional JSX template...
  );
}

I initiated three separate pieces of state to handle the fetch call:

pokemon – stores the value of a successful fetch request,
error – contains any errors that may occur,
isLoading – a boolean indicating whether or not a fetch request is currently taking place.

If the request is successful, the response is stored in results, otherwise, I have a catch function that stores the error in error, if the fetch fails. After the fetch is resolved, regardless of the results, I need to set isLoading back to false, which is handled inside finally() Since fetching data is asynchronous, meaning it takes some time to complete, isLoading gets set to true until the fetch either succeeds or fails, and is false while nothing is being fetched. Now, I can use the pokemon data I've fetched in the rest of my application just like any other piece of state.

As mentioned above, I find custom hooks useful for separating the logic inside my components into their own functions and/or files, leaving only the essence of what my component is intended for. This lightens up my component and makes comprehending it a lot easier. Also, my useFetch Hook can now be reused by any component, giving my fetch call more utility, as it’s no longer confined to only one component.

My custom Hook - `useFetch`

The block of code below does exactly the same thing as the previous code block, only the fetch logic is entirely inside of my useFetch Hook (function), including my three state variables. I've also added an AbortController to my Hook to "cleanup" my useEffect Hook.

App.js

import { useState, useEffect } from 'react';

const POKEMON_URL = 'https://pokeapi.co/api/v2/pokemon';

const useFetch = () => {
  const [pokemon, setPokemon] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    const { signal } = controller;
    setIsLoading(true);
    fetch(POKEMON_URL, { signal })
      .then(res => res.json())
      .then(pokeData => setPokemon(pokeData))
      .catch(err => setError(err))
      .finally(() => setIsLoading(false));
    return () => controller.abort();
  }, []);
  return { pokemon, isLoading, error };
};

export default function App() {
  const { pokemon, isLoading, error } = useFetch();

  // Example usage of pokemon data
  const pokemonCards = pokemon.results.map(poke => {
    // function logic...
  })

  return (
    // conditional JSX template...
  );
}

Moving my fetch logic into it's own custom Hook makes my component easier to understand. I think it's pretty obvious that useFetch is a function that makes a fetch call. Code that's easy to read is highly encouraged, from what I've gathered, and it makes sense, especially when collaborating with others. I hate when I have to reread my old code a few times to understand what it does.

Note: it’s always best for custom Hooks to start with the word ‘use’ followed by whatever you want (useFetch, useState, useEffect). This is to let other programmers and react know right away that the function is a react Hook. I'm probably oversimplifying it, so if you want to know more, you can check out the docs for React, here.

Refactoring into `useFetch.js`

Technically, I did it. I made a custom Hook. It doesn't need to be refactored into a separate file to be a custom Hook (I only say that because that was my impression, at first), but doing so but doing so has a couple advantages for me. First, it will make my component MUCH cleaner and, more importantly, I can make it even more reusable, allowing me to import it into any custom Hook or component.

App.js

import useFetch from '../hooks/useFetch';

const POKEMON_URL = 'https://pokeapi.co/api/v2/pokemon';

export default function App() {
  const {results: pokemon, isLoading, error} = useFetch(POKEMON_URL);

  // Example usage of pokemon data
  const pokemonCards = pokemon.results.map(poke => {
    // function logic...
  })

  return (
    // conditional JSX template...
  );
}

useFetch.js

import { useState, useEffect } from 'react';

export default function useFetch(url) {
  const [results, setResults] = useState(null);
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    setIsLoading(true);
    const controller = new AbortController();
    const { signal } = controller;
    fetch(url, { signal })
      .then(res => res.json())
      .then(data => setResults(data))
      .catch(err => setError(err))
      .finally(() => setIsLoading(false));
    return () => controller.abort();
  }, [url]);

  return { results, isLoading, error };
}

I think that looks WAY cleaner and makes reading it MUCH easier. This way, I'm able to get rid of all of the useFetch logic in App.js, including my three state variables, as well as, my useState & useFetch imports. All I have to do is import useFetch at the top and invoke it, destructuring the my three state variables from it's return. Notice I've changed the name of the 'pokemon' state variable to 'results', to make it more universal. Notice I did, however, rename it to 'pokemon' when destructuring it inside App.js.

The logic inside of useFetch.js is basically cut right from App.js. The only difference is I've made it more dynamic by creating a 'url' parameter so I can use my Hook to call other endpoints, if necessary.

When creating custom Hooks, I always store them inside a folder called hooks, located just inside the src folder (/src/hooks/useFetch.js). This is the most common way to structure your hook files, from my experience.

It’s also best-practice for the file name and the Hook name to be the same. Also, you should export the function by default.

Conditional rendering

Once I've destructured my state variables from useFetch(), I can use them to conditionally output JSX based on the their current values.

From my App.js examples above...

  return (
    // conditional JSX template...
  );

This portion of code is commented out to make my examples shorter and less overwhelming, but now I'll open it up and show one way to use state to conditionally output JSX.

Hopefully, your familiar with conditional rendering, in general, but if not, you can learn more about it here.

return (
  <>
    {pokemon && !isLoading && (
      <div className="FetchHook">
        {pokemon.results.map((poke, i) => (
          <div key={i + 1}>{poke.name}</div>
        ))}
      </div>
    )}
    {isLoading && <div>Loading...</div>}
    {error && !isLoading && (
      {console.error(error)}
      <div>
        <h2>ERROR:</h2>
        <p>{JSON.stringify(error)}</p>
      </div>
    )}
  </>
);

Above, there's three possible templates being rendered, but none at the same time. First, I checked if the pokemon variable was truthy, meaning it wasn't empty, and I also made sure isLoading was set to false, meaning the fetch request was resolved. Currently, I'm simply outputting each pokemon's name inside a div, but if I were to take this further and make a pokedex, I could map through the results to create an interactive list of pokemon cards or whatever.

Second, whenever isLoading is true, I wanted to output a message saying so. This is where a loading spinner or a skeleton could be rendered.

And third, if errors is ever true, meaning there was an error while fetching the data, I wanted to output that information to let the user know, as well as, make sure isLoading was set back to false.

To bring this article full circle, because I extracted useEffect into it's own file, the rest of my App component can focus on it's intended purpose, which is to output a list of pokemon, making the code easier to comprehend on the first read-through.

More info on Hooks

Unlike React components, Hooks can have any return value, not just valid JSX. For example, useState returns a state variable and a function to set it, that is destructured from calling useState(). useEffect, on the other hand, doesn't return anything.

By definition (see above), Hooks can call other Hooks, including useState, meaning Hooks can initialize and manipulate state. That's part of what make custom Hooks so powerful! This also means that my three state variables can only be updated from within useFetch.js, unless I include their set functions in the return. There should never be a reason for me to update these variables from outside the file it lives in besides refetching the data, but if there ever is one, I can always go into useFetch.js and simply export whichever set function I need.

Conclusion

So with that... I made a Hook! If you want to know more about Hooks, custom Hooks, or React in general, the best place is at reactjs.org.

There were a few videos on YouTube that really helped me understand making custom Hooks, specifically making a custom useFetch Hook. In general, I owe these guys a lot for teaching me everything:

If you've made it this far, thank you, sincerely, for reading my article. This is only the third blog post I've ever made, so if I've made any huge mistakes or you want to give me advice on how to do this better, please, let me know!

That's it.

- END -

Retrieving Client’s Current Position in the Browser

Eric — Sat, 30 Oct 2021 01:36:58 +0000

One of the projects that comes up in just about every YouTube video with a title like, “10 projects every beginner should make,” is a weather app. It’s a project that requires making a request for weather data from an API and displaying said data in the DOM. It’s actually the first real project I've attempted and it's the final project for phase one of my coding bootcamp. It helped me to learn the Fetch API and asynchronous JavaScript. I would definitely recommend it.

I wanted my weather app to automatically fetch and display the weather for the client’s current position, on page load. Learning to do so also taught me how to use the browser’s built in Navigator object to retrieve the latitude & longitude for the user's device. I thought it was pretty cool, so I wanted to share with y'all how I did it.

If you would like to check out my weather app, you can find it in GitHub, here. As of being published, I'm nowhere close to being done building the app. It successfully fetches data from three separate external APIs, but there is much work to do, still, on the frontend. Let me know what you think! Like I said, it's the final project for the first phase of my coding bootcamp, so feel free to give me some feedback on GitHub! Here's a screenshot of how it currently looks.

Note: You will need to generate your own API keys from openweathermap.org and console.developers.google.com/ if you would like to see it in action. I'm currently learning how to deploy the app on netlify.com, and I will post a link to the finished app when it's ready.

**What is the Navigator Object?**

According to MDN:

The Navigator interface represents the state and the identity of the user agent. It allows scripts to query it and to register themselves to carry on some activities.

So, that’s clear enough... Honestly, I don’t really know what the Navigator object is. As far as I can tell, from perusing the MDN page on it, it’s a global(window) object that contains all kinds of information about the client’s device, like information about the network connection or the device’s battery life. It also contains the navigator.geolocation property, which is an object we can work with to obtain the latitude & longitude of the user's device.

To do this, we’ll use the Geolocation object’s built-in method “getCurrentPosition” (navigator.gelocation.getCurrentPosition). After this, check out the other properties of the Navigator object, as well. They’re pretty cool.

If you pull up the console in the browser, you can enter the following code to retrieve your current position:

navigator.geolocation.getCurrentPosition( position => {
    console.log(position.coords));
}

You should see this familiar pop-up:

Pretty cool right? It was to me, at least, when I first made this alert happen. My alert says it's from www.google.com, because that was the website I was currently at when I entered the above code into the console.

A Quick Aside

Whatever you do with the user’s location data is 100% up to you. I do, however, want to emphasize the importance of using this data ethically. Obviously, we are just fiddling around here and not creating the next Facebook or Google, but, also, don’t trick anyone into using your app, just to get them to opt-in and give away their location (I was brainstorming ways to use what I’m demonstrating unethically, and that’s the best I could come up with).

Finally, ignorance does not excuse you from unethical behavior, so always be aware of the ethical implications of whatever you happen to be making at whatever company you happen to work for.

Back to the Code

Click “Allow” to give yourself permission to know your own location and you should see this in your console:

As you can see, a GeoLocationCoordinates object is logged with the latitude & longitude. Feel free to google those coordinates to check if it’s accurate.

Breaking it Down

First off, the Navigator object is a property of the Window object, in the browser, similar to the Document object. It’s a global object, so we can just type navigator instead of window.navigator.

Inside navigator.geolocation lives the method getCurrentPosition (navigator.geolocation.getCurrentPosition). That’s the part of this code that actually does anything.

getCurrentPosition is an asynchronous function that takes in 1 required argument and 2 optional arguments.

The first argument is a callback function that executes once the location information is retrieved - this is where you have access to the location information and can choose what to do with it. Because it’s asynchronous, any code you want to execute afterwards is put inside this function, much like a regular fetch call chained with .then().

It takes one argument, a GeolocationPosition object. GeolocationPosition objects have only two properties: coords & timestamp. Above, in the code we ran inside the console, we logged the coords objects. Check out the second image and you'll see the latitude & longitude of the GeolocationCoordinates object getCurrentPosition.coords returned.

The second argument is another callback function that handles any errors while trying to retrieve the location information. It would normally look something like this:

function error(error) {
    console.error(error);
}

Finally, the third argument is an object where you can specify certain options. I won’t be going over the options object at all, since I’ve never used it myself, but the MDN documentation explains all about it, if you want to check it out.

How I Used the Latitude & Longitude

For my weather app, I used one of OpenWeather's amazing free API's for getting weather forecasts. All I needed was a valid latitude & longitude, and with one call (One Call API) I was able to get all the weather data I needed for a basic weather app. I destructed the lat & lon from the GeolocationPosition object returned from getCurrentPosition, and sent it away to OpenWeather.

Here's what the final code looks like:

function getLatLon() {
    navigator.geolocation.getCurrentPosition(success, error)
}

function success(position) {
    const {latitude: lat, longitude: lon} = position;
    fetchWeather(lat, lon);
}

function error(error) {
    console.error(error);
}

fetchWeather is a function I made myself that actually makes the fetch call to OpenWeather.

I Guess That's All

And that's how I did it. It was a super fun experience, figuring out how to do this, and I'm glad I could share it with someone else. There are two YouTube videos, in particular, that were instrumental in helping me understand this topic. The first is from my favorite channel for learning anything JavaScript, Steve Griffith - Prof3ssorSt3v3 and his amazing video, JavaScript and Geolocation. The other is from one of my other favorite channels, The Coding Train and his wonderful video, 2.2 Geolocation Web API - Working with Data and APIs in JavaScript. Thanks for reading!

Before You Go

It's been 213 days since I first started learning how to code (from 3-30-21) and I'm coming up on the conclusion to phase one of five for my coding bootcamp, Flatiron. This is my first technical blog post (2nd ever) and, in fact, is a prerequisite to moving onto phase two (my weather app, mentioned at the top, is the biggest prerequisite). These last few months, since I started this journey, have been the best. I'm grateful to have stumbled onto something that, already, means so much to me.

I very serious about being the best programmer, period, so I'm completely open to, and encourage, constructive criticism, as long as it's well meant. And, of course, if anything I write is incorrect or if I failed to mention a critical piece of information, please let me know as well! I sincerely appreciate you reading this whole post. Thank you.

References and Resources

Credits

cover image from browserstack

FIRST! - An Introduction

Eric — Tue, 19 Oct 2021 05:58:32 +0000

You are now reading my first blog post. Not just wherever you happen to be reading this, but my first blog post, ever. I am being encouraged/made-to start a technical blog by my coding boot-camp: Flatiron. Sharing my thoughts and opinions publicly, in a forum, is not something I’m naturally comfortable with, but I really love coding (whatever that means) and I’m willing to do whatever it takes to be the best, and maybe help/inspire others, as well.

What to expect?

At first, you can expect articles centered around basic HTML/CSS/JS, like “making a fetch call”, or “the difference between findIndex() & indexOf()”, etc., but coming from a novice. Sharing my own struggles with a given topic will hopefully be more endearing to other novices facing similar struggles.

Who am I?

My name is Eric Hafvenstein. I’ve been learning HTML/CSS/JS for around seven months now and I’m about five weeks into a 40 week software-engineering course, on-line, with Flatiron. I’m still pretty green, but programming feels natural to me. I’m 33 years old, so thinking about all the years I should have been programming is dismaying, for sure. I was so close too! I remember, as a teenager, moving files around and hiding them from my mother in the File Explorer and using MS-DOS. I couldn’t tell you what I was doing with MS-DOS, but I did use it. I was one nudge away, but life became about more than computers and video game, I guess (mostly girls).

Although I am sad that I’m not a programmer with close to 20 years experience, I am overjoyed that I finally found something I’m this passionate about! Programming is just fun! Whenever I get a relatively complicated piece of code to execute, I feel like I cleared a grueling dungeon.

Finally

These last seven months of programming have changed my life! In fact, it’s led me to Flatiron and to here, this blog post that you’re still reading. Thanks, btw, I really appreciate you getting this far. This is the end of, what I hope is, the first of many articles I post throughout my adventures in programming.

DEV Community: Eric

The very basics of Active Record Validations

Why use validations?

Validation Helpers

presence

uniqueness

length

comparison

format

Conditional Validation

Custom Validations

Conclusion

Resources & Acknowledgements

Associating Distant Table with Active Record

Setup

Setting Up Associations

Quick Explanation for #pluck:

Creating a Join Table

Wrapping Up Associations

Conclusion

I Made a Hook!

Introduction

Making a basic fetch request (in React)

My custom Hook - useFetch

Refactoring into useFetch.js

Conditional rendering

More info on Hooks

Conclusion

Retrieving Client’s Current Position in the Browser

What is the Navigator Object?

A Quick Aside

Back to the Code

Breaking it Down

How I Used the Latitude & Longitude

I Guess That's All

Before You Go

References and Resources

Credits

FIRST! - An Introduction

What to expect?

Who am I?

Finally

Credits

- pixellife font in cover image by William Clifford

Quick Explanation for `#pluck`:

My custom Hook - `useFetch`

Refactoring into `useFetch.js`

**What is the Navigator Object?**