Forem: Cristal

Responsive Web Design

Cristal — Mon, 20 Jul 2020 05:07:43 +0000

Hi friends! I'm back! It's been a little busy with my internship but I'm happy to report that I AM still working on my Front End Developer Blueprint from Skillcrush.

I covered a little bit of Flexbox today and got some good labs in. I learned a few technical things, of course, but also realized that while rote memorization is impractical, rote practice is totally helpful. Both of today's labs involved doing the same thing- the first time totally guided and the second unguided. I feel like I'll be more likely to remember how to do what I learned just because I did it twice in a row.

Anyway, you may just be here to learn with me, so let's get to business.

What is Flexbox?

Flexbox is a collection of CSS properties that is designed around the idea of having two planes- one vertical and the other horizontal. Think x and y axes!

(I know you're having an "Oh, this is when I'd use geometry in real life" moment.)

What does Flexbox allow us to do?

Flexbox allows us position not only the content within a tag, but tags themselves. It allows us to arrange our elements as we'd like!

How do I turn it on?

Give your HTML the following property:

  display: flex;

and BAM! It's ready for use.

What properties do I need to use Flexbox?

Well...

  flex-direction: column;
    /*this property will create a vertical axis*/
  flex-direction: row;
    /* creates a horizontal axis */
  justify-content; 
    /* tells the content where it should be aligned on *main* axis */
    /* possible values:*/
      flex-start;/* aligns things on the left if horizontally aligned or at the top if vertically aligned.*/
      center; /* centers, of course */
      flex-end;  /*aligns an element on the right of the page if horizontally aligned, or the bottom of the page if vertically aligned*/
      space-between; /*items aligned across the container with an even amount of space in between each one*/
      space-around; /*elements have an event amount of space before, between, and after each element*/
      initial; /*uses whatever the default value is*/
      inherit; /*takes on the position of the parent element*/

Then there are the ones you'll use for the cross-axis!

  align-items: /*same as justify-content except on a different axis*/
    /*Possible values: */
      flex-start;
      flex-end;
      center;
      initial;
      inherit;
      /* ...and add */
      baseline; /* positions items at the container's baseline*/
      stretch: /* stretched an element vertically to fit the container */

  align-content /* has the same effect as justify-content, but only if that content is wrapped. Will have no effect otherwise! */

  flex-wrap /* dictates if elements should wrap or not */
    /* Possible values: */
      wrap; /* tells items to wrap */
      nowrap; /* the opposite of the above */
      wrap-reverse; /* wraps items in a reverse order */
      inherit; & initial /* same as before! */

&& that's all for today on the TL;DR version of what I'm learning. If you care to see it in action, you can take a look at my last two labs here & here. I've been committing every step as I walk through these labs, so you can actually see what happened when and what effect it had.

Happy Coding!

Responsive Websites: Typography!

Cristal — Sun, 12 Jul 2020 06:36:36 +0000

Hey friends!

So I was heading over to write something up on responsive typography when I realized that my writing style is totally TL;DR.

I'm not here to pretend I'm an expert. I am, like many of you, blogging to learn and share those learnings. Thus, I'll leave the big kahuna explanations to the pros and no doubt the plethora of existing resources.

Full disclosure: I'm currently learning about front-end web development through Skillcrush's Front-End Developer Blueprint and most of these learnings come from their fab course!

Now without further ado...

Font basics:

Make sure your text is easy to read- never size anything smaller than 16px. Didn't define the font size in your stylesheets? Most browsers will have a default size of 16px!
Keep the line length between 45-75 characters in length.
Use black text on white backgrounds, or even dark grey, for better readability.
Keep fancy fonts to a minimum!

Pixels, ems, and rems, oh my!

Now, if you're like me, you probably had no idea that there was any other way to define your font sizes besides pixels. It turns out there are SO many more, but for now we'll only cover the most common three.

1. The Pixel

A pixel is fixed and does not scale. It's computed value is the same regardless of the context in which it occurs. In other words, it's pretty static. Not exactly what we want for a responsive site.

2. The em

Em's are pretty neat because they are scaled units of measure.

1em is the equivalent of the font-size set on the parent element of the current element.

So if your site's base font-size is 16px:
1em = 16px
2em = 32px
3em = 48px

This means that if you know you want your h1 to be 2, 3, 4 times bigger than your paragraph fonts, for example, you would just set H1 elements to 2, 3, 4 ems.

BUT WATCH OUT! Nesting elements can have an unexpected effect on your sizes. Here's an example:

  <html>
    <div class="greeting">
      <h1>Hello World!<h1>
    </div>
  </html>

Here you can see I've nested an h1 within a div with a class of greeting. So what happens when I do this?

  html {
    font-size:16px;
  }

  .greeting {
    font-size: 2em;
  }

  h1 {
    font-size: 3em;
  }

You might expect everything in our greeting div to be 32px in size, with the exception of our h1s, which would be 48px in size.

Instead, our h1s are actually 96px in size! WHAT?!?

Well, em's are based on the parent element. Because our h1's parent is the div with the class, "greeting", it's 1em was actually 32px.

32px * 3= 96px

You get it, right? So, handy, but can sometimes be problematic.

Which brings us to...

3. The rem

Okay, the rem is pretty neat, but before I tell you about how great it is, know that it's not supported on Internet Explorer 8 or below.

With that out of the way, let me tell you why the rem is great.

While em's are based on the font-size of the parent container, an rem is based on the root element of the document and its size.

So in our example above, we could skip the headache by just changing ems to rems.

That's all, folks

I hope this was just the right length to be informative but not pedantic! If you have any questions, comments, suggestions, please reach out to me any ol' time :)

Responsive Websites: Media Queries

Cristal — Mon, 06 Jul 2020 02:32:49 +0000

Hi friends!

Today I want to tell you a little bit about media queries! Let's keep it short and simple as usual, yes?

What is a media query?

THIS is a media query:

Simple looking, right?

Our media queries specify what css to display in a browser given a device's specific dimensions. It gives our browser information about the device a user is on, the width of that device, and the orientation of the device, amongst other things.

Without specifying a type of media like say, "print" or "screen", the query will default to "All". Read about more media query types here.

What goes in a media query?

As you can see, we create the @media rule, add the query type, and then specify widths. Not all media queries will include both a min and max width, but notice that you can specify different conditions using logical operators.

What does this mean for mobile-first design?

Well, this means that you should design websites mobile-first, and then use media queries to size up your sites, not down.

*tablets: use a min-width of 768px.
*desktops: use a min-width of 1200px

These are pretty good standards according to Skillcrush.

DON'T FORGET

Don't forget to include the following line of code in the head tag of your html!

It is the HTML5 method that allows us to control the size of the viewport, or the user's visible screen, and gives it instructions for the width and scale. Read more about it here.

Care to see an example of media queries in action?

Tada!

body, html {
      font-family: Gotham, Helvetica, Arial, sans-serif;
      font-size: 1em;
      text-align: center;

    }

    section {
      width: 50%;
      margin: auto;
    }

    h1 {
      font-size: 2em;
      color: #7b7d70;
    }

    h2 {
      font-size: 1.5em;
      color: #4eafb8;
    }

    p {
      color: #ff8641;
    }




/***** TABLETS *****/
@media (min-width: 768px){
  h1 {
    color: #02cbd2;
  }

  h2 {
    color: #fcc02a;
  }

  p {
    color: #7b8f8e;

  }
}


/***** DESKTOPS *****/
@media (min-width: 1200px){
  h1 {
    color: #6e4b61;
  }

  h2 {
    color: #cabd61;
  }

  p {
    color: #c19e74;
  }
}

This CSS is written mobile first, which is why we don't specify the widths for viewport widths smaller than 768px. Then, we create a note in our CSS to separate sections for tablets and desktops. Notice the min widths, as well as the lack of a media query type.

That's all, folks!

As always, feel free to comment, critique, and make suggestions! Happy coding!

Learning About: Building Responsive Websites

Cristal — Mon, 29 Jun 2020 01:47:24 +0000

I'm currently learning about designing and coding responsive websites.

To get a good understanding of what a responsive website is, it's pretty important to understand what a responsive website isn't. Or, in other words, it's important to understand what other types of websites exist and that we interact with.

3 types of non-responsive websites:

Static:
These websites are designed for desktops and desktops only, and are built with a fixed width. We want to avoid building these as much as possible!
Fluid:
These websites are, well, fluid. All websites are fluid if you don't specify a width, actually. Fluid sites work on all devices and if widths are specified, they are done so in percentages as opposed to pixels. The thing to note here is that the layout never changes.
Adaptive:
Adaptive sites, you guessed it, adapt to the width of their device. The hitch? Widths have to be specified for EVERY. SINGLE. DEVICE. Which means that you need different stylesheets for EVERY. SINGLE. DEVICE.

Responsive Websites:

Are a fabulous combination of easily maintained fluid websites with user optimized adaptive websites.
Combine the ability to specify widths in percentages and also declare minimum widths in pixels.
Use media queries to specify sizes, and can coexist in the same stylesheet. SCORE!

Next up: Media Queries

A Dev Newbie Refocuses

Cristal — Sun, 28 Jun 2020 23:50:26 +0000

Hi Reader,

I've been thinking a lot lately about who I want to be and what I envision making of my life as a developer. When I decided to switch gears from the world of nutrition and health research I only knew one thing: I wanted to code.

So I went to a bootcamp, put in the hours, graduated, and just recently emerged onto the job market.

I thought the the quickest and most effective way to land a job fast would be to deepen my skills in Ruby and Rails given that those were the focus of my software engineering immersive. I gathered the best resources I could find and took off to the races.

Here's what actually happened:

As you can see, I had a pretty steady cadence going on between October of 2019 and March of 2020. There are a few gaps during the holidays, but on the whole I held pretty steady in github contributions.

It was in late March that I decided to focus on Ruby and Rails, and as you can see I didn't make a whole lot of progress. Why?

I wasn't interested

Did I love the challenge of back-end programming? Absolutely. Solving logic-based problems provided me with hits of adrenaline... But I learned from my time in the program that I didn't want to be an algorithm master. And yet, here I was trying to force myself to love it and consequently getting nowhere.

Have you ever done things you knew you hated and were against your own best interest but for some reason you persevered after them because your brain said you had to? That was me.

Then a tweet saved my life.

Seriously, this tweet was the best thing that could have happened for me. I read it and found myself giving myself permission to just do what I want. I gave myself permission to go out and seek out joy and not just employment.

I won't say it wasn't difficult. Having committed to an income share agreement for my 15k tuition at my coding bootcamp, I carried a lot of guilt about my decision to not pursue a job in the technical skills I had learned during my program. I wallowed in my sunk cost fallacy for a little while, even.

But unemployment can't go on forever.

Having been out of the workforce for a while, I felt time clipping away at my heels. I had to do something, but I was back at square one it seemed. How does one become a front-end developer without proficiency in HTML, CSS, and JS? You can't.

So I pulled out the Skillcrush Front-End Developer course I bought SIX MONTHS prior to starting my bootcamp and got to work. I'm currently learning about responsive web design, and I couldn't be any happier.

I also started looking into internships that didn't require any experience so that I could start doing on the job learning. I'm lucky enough to have found one, and I'm excited to see where it goes.

And that's where I am now.

There's so much I need to learn and a whole lot more to grow as a developer. I try not to beat myself up about it- I've only been coding for 10 months, and only just three weeks ago gave myself permission to follow the beat of my own drum instead of following what everyone else says is best for me.

It's going to be worth it.

So expect front-end content content from me moving forward.

I'll definitely be going back to my Ruby course at some point to make sure I hold on to the technical skills I do already have, but that's not where the bulk of my energy will be going.

Happy Coding!
-Cristal

Up next: Responsive Web Design

Hosting on Github Pages: A Quick and Short How To

Cristal — Thu, 18 Jun 2020 22:43:28 +0000

So you have a website that only uses HTML, CSS, & JS? What an exciting time to be alive, you can host your site straight to Github without spending a dime!

The main benefit is that you don't have to worry about buying a domain name and setting up your hosting site. If you've pushed your project up to Github, you've already done the bulk of the work!

Ready to see how easy this is?

1. Create a new branch

In your terminal (command line), cd your way into your project directory (folder). Once there, create a new branch by running the following command:

git checkout -b gh-pages

You must name your branch gh-pages in order for this to work correctly.

2. Push to origin

Next, run the following command:

git push origin gh-pages

3. Verify it worked!

Go to your repo on Github and click on the 'Branch' dropdown. You should see gh-pages there now!

4. Visit your site

In your browser, head over to:

your-user-name.github.io/repo-name

Et voila! Your site!

Happy Coding!

Ruby Gotcha #1

Cristal — Wed, 10 Jun 2020 23:14:27 +0000

Hi dev friend!

Today I want to tell you about how I recently started The Complete Ruby on Rails Developer Course on Udemy, by Mashrur Hossain and Rob Percival. I'm aiming to deepen my the knowledge I obtained at Flatiron School, and strengthen the concepts that I feel comfortable with.

If you're looking to do the same, I'm happy to report that I will be taking notes as I progress through the course, and plan to upload them to Github. What I want to do right now, though, is share that first Ruby Gotcha! I've run into.

Ruby Gotcha #1: The difference between pass-by-reference and pass-by-value

In general, according to the instructor:

"In Ruby, if a variable is pointing to another variable, it's actually pointing the location in memory the variable is pointing to."

Here's an example:

If you weren't aware of this gotcha, you might think that the variable "new_name" now points to "Joe". Here's what happens instead:

The new_name variable is still pointing to that location in memory that holds the string "Cristal". Is your mind blown? Mine was!

It starts to get tricky once you actually start passing that variable around into methods. Let's take a look at that!

pass-by-reference

In Ruby, dynamic variables that can change in size are passed-by-reference, as in the location in memory. This means strings, arrays, and hashes.

By passing these variables around to methods using their reference, we are able to mutate them.

!!!IMPORTANT NOTE!!!
Remember that mutation is different from reassignment!
Here's what happens if you pass in a mutable variable to a method and then reassign it:

As you can see, name is still pointing to "Cristal" in memory.

But if we mutate the string, here's what happens:

"name" is pointing that spot in memory, but because we mutated the string, it is now permanently "Cristal Moz"

pass-by-value

Static variables- meaning that they don't change in size and are immutable- can be passed around as the actual value, instead of their reference. These include integers, fixnum, floats, and booleans. So let's look at an example...

As you can see, when we pass previous_age to the birthday method, it returns what we expect, but the value of previous age does not change. We cannot mutate an integer, fixnum, float, or boolean so that space in memory will always and forever point to that value.

Pretty neat and pretty confusing, right?

Maybe you're feeling like I did- you're thinking "WHAT?" In some of these scenarios, I thought the variable would be the same and then in others I thought it would be different. It helps to open up your terminal, get IRB going, and practice! Try passing different variable types around and seeing what happens!

Have a comment, question, suggestion?

Please reach out, I don't bite!

OOP Fundamentals: What is an Object ?

Cristal — Mon, 08 Jun 2020 05:23:22 +0000

Hello again, reader and fellow Dev. If you've been here before, you know I've been a Flatiron School student for the last few months. It's been some time since I wrote a piece here on dev.to, but I'm back at it now, writing blogs as an alumn!

I'm actively job hunting at the moment and so it's a great time to review some foundational concepts that will certainly be asked about during the interview process.

Today, we'll start at the beginning...

Why objects?

Objects, as you might guess, are incredibly important in Object Oriented Programming, otherwise known as OOP. They're important because by creating objects we eliminate the need to write redundant and repetitive code. When we create an object it can be called from anywhere within a program instead of having to be recreated every time it is needed.

What are objects, and what do objects have?

Objects are the basic units of object-oriented programs and have two basic things- state and behaviors.

The state reflects that objects current state, which is stored in variables. The behaviors associated with that object are typically called methods, and can be called on that object.

A simple example would be your car. As an object, it has a current state- it can be on, running, or off. Some methods you might be able to call on your car object would be things like:
turnOn(); drive(); reverse(); and so on.

The most important thing about objects is that they are little packages of information. An object knows its own properties and carries its methods with it. Unlike procedural programming, where a variable is declared and a function is written separately from it, in object-oriented programming we are able to call methods on the object itself. Additionally, having objects makes it possible for objects to interact with other objects.

Next up: Classes. See you soon!

A CLI Project Built With Love

Cristal — Sat, 04 Apr 2020 06:46:53 +0000

This post was imported from my Medium account, which I will be taking down shortly!

I know what you're thinking- "the title says "CLI Data Project… where's the code"?
I promise we will get there, but every story starts at the beginning.
You're looking at Duchess. She's been up for adoption for the last 43 weeks and no one knows why. I've been following her on Instagram for months now, and every single day that passes is another day I wish that I could take her in.
I often spend my time thinking about her, half hoping no one has adopted her so I can adopt her myself, half hoping her picture will stop appearing in my timeline, signifying that she's found a new home.
This project is dedicated to her.
If code is supposed to solve real world problems, maybe this small work of love will get Duchess into a home where she can love and be loved.
If you'd like to learn more about Duchess and her canine pals, and/or learn about how Paws4Life K9 Rescue also saves lives by helping prison inmates receive sentence commutations, please visit https://pawsforlifek9.org/
And now to our scheduled program.

The Setup: Getting my local environment ready for the project was ground zero. Many students have used the Bundler gem to create a project repository, but I found it produced many unnecessary files for my project's purpose. I chose to configure my files manually. My project folder includes a bin folder that houses my executable file(dogs), and the config folder, which houses environment file.The environment file is home to all of the program's required files and gems. The gems must be downloaded onto the computer on which the program will run. From the command line (your terminal), you need only type: gem install If you come across an error message that states that you do not have write permissions to install the gems (as I did), it is possible to solve the issue by instead typing the following into the terminal: sudo gem install Lastly, I established a lib folder that holds each class in a separate file. It is important to separate them based on class responsibility. The CLI class handles the logic, the Dog class instantiates Dog objects, and the Scraper class scrapes the data that is handed to Dog objects to give them attributes. Note: the initial setup involved only an executable file and the three class files. Once the word on those files was done, an environment file was added, and file dependencies were moved into their appropriate places.
The Dog Class: I started the project in the most logical place- creating dog objects. If the whole program is about showing what dogs are up for adoption, and giving the user information about them, it makes sense that we want to create them first, and then think about how to give them attributes. Creating this model was pretty standard. Defined the class, gave it the ability to set and get (or write and read) attributes for each dog object (or instance), and provided a class variable @@all set to an array- so that the class can hold all of its dog objects. Each dog object saves itself to the array upon initialization, as defined by the initialize method. The class method self.all returns all of the dog objects with all of their attributes. We will need to access the dog objects in our other classes.
The Scraper Class Our Scraper class "scrapes" the desired webpage to acquire the information that is necessary to the application. Recall that both the Nokogiri gem and Open-Uri gems are part of our program's requirements. Open-Uri allows the program to open the url as if it were a file, while Nokogiri grants the ability to parse HTML and XML. Without these, our program is unable to obtain the information that we need for our program! As you can see, I have set the variable 'doc' to a url that is being opened as a file by open-uri and parsed with nokogiri. Now we can get to selecting what we need by using css selector methods. But how do we do that? If you right click on a webpage and select "Inspect Element" in the drop down menu, you're given a set of developer tools to play with within the browser. There are two ways to approach the task of finding our selectors. The first is to press the cursor-in-box button at the top left hand corner of the developer tools pane, then using our cursor to float over the elements on the page. Our job is hard enough, so make your life easier by using the elements inspector in the developer tools pane. By moving the cursor over the element's css code, the element itself is highlighted on the page! In the example above you can see how the first class "fl-post-grid" denotes the container for all of our dogs, and each dog is contained in the class "fl-post-column". So what can we do with this information? We can iterate. The syntax: What next? Let's make some dogs to pass the information to! Line 7 makes a new dog object. Line 8 gives our dog a name based on the information obtained from our scrape, while line 9 gets a short description, and 10 gets the profile url. Neat! Those attributes were set. Is our dog holding on to those? You bet! Think back to our Dog class: Our attr_accessors are both readers and writers. When we write: doggo.name= dog.css('a').text.strip .name isn't something magical that just gave the dog it's name. It's a method! The attr_accessor :name is doing two things: Setting/writing the name instance variable from the name variable that is being passed into the method: def name=(name) @name=name end & getting/reading the name instance variable: def name @name end Magical, but not quite magic. The other attr_accessors function in this same way, setting instance variables in setting and getting methods that can be called upon in other parts of our program. The rest of the scraper class follows the same process for gathering data passed to the dog object. We'll come back to the second method later, however, to demonstrate how the dog object that already existed is passed into it to set other object attributes.
The CLI Controller The CLI controller is responsible for controlling the program's logic, taking in user inputs, and presenting program outputs. The CLI controller does NOT scrape data, and does NOT give our dog objects any attributes. Looking at this code (which will be refactored at some later point in time), it's obvious that it is styling that the end user sees. sleep(x) produces a short delay so that not all output appears at all at once. Series of underscores and dashes provide division to make it easier for the user to see and understand the information presented. Scraper is called within the run method to get the information needed for the next method, list_dogs (which is established in the lower portion of this image). The program outputs some instructions, and then takes an input, stripping it of whitespace- leading and trailing- and downcasing it (strange, but remember, our user is allowed to input strings as well as integers). The while loop is established and given an If-Elsif statement to handle different input cases. Validations are put into place so that our program runs properly even if given an erroneous input (negative numbers, numbers that exceed the range, random strings). As you can see, nothing is set by our CLI class, it merely calls upon other methods to run. If you look closely enough, you might think- but what about the second scrape, Scraper.dog_details ? Aren't you setting something there? Well… no. Here's what's happening: Our program gets an input, and if that input converts to an integer between 1 and the length of our @@all dogs array (from our Dog class), it sets a local variable dog to Dog(the class).all(the dogs)[at the index which equals our users input, converted to an integer minus one(because arrays start at index 0)]. Then it scrapes dog details. Our program switches tasks and jumps from our CLI class, to our Scraper class.That dog variable (which, remember, is an object that was previously created), is handed to the Scraper class method dog_details . The urls are passed in as files, the html is parsed using nokogiri, and our passed in dog object is given it's attributes using attr_accessors. Magic? Magical. The program executes this code, and jumps back to the CLI class, and continues to execute the rest of the program. It's important to note that scraping a few times is fine, but excessive scraping can lead a website to block you. Make sure to scrape only once. Easy way to do this is to make sure that you are not including the scrape as part of a loop (as with the first scrape) or including a validation. Our scrape below only happens IF it hasn't happened once before. Final Touches The 'colorize' gem was installed and required by our program environment. Colorize gave the program a nice pop of color that makes the terminal less dull. The config folder was created, and dependencies were moved to their appropriate places. Here is the final product!

A special thank you to Nancy Noyes, our cohort lead for the Flatiron School Full-Time Online Software Engineering Program, for her extensive help, and to the Flatiron school for an incredible first module in the curriculum.
Other honorable mentions: Stefanie Davis, Victoria Hale, and Huda Usif for their enduring support and willingness to critique, guide, and help as I moved through the process of building this project.

Performance Review: React/Redux

Cristal — Mon, 30 Mar 2020 06:22:48 +0000

What's this about?

I had my "final" project assessment, which covered React and Redux, this past Friday. I ran over the 45 minute timeframe, and will need to complete the remainder of the assessment early in the upcoming week.

Rather than be upset about it, I thought I'd do the next best thing: analyze it. Here I'll be covering both the bright spots and the pain points, as well as giving the major highlights in the hopes that they might be helpful for you, fellow dev.

Lesson Learned #1

Demonstrate your understanding without becoming verbose.

During my assessment, I was asked a simple question:

Why is dispatch so important in redux?

A simple question deserved a simple answer, something short and elegant:

The dispatch function sends an action to the reducer.

If I wanted to get fancy, adding

it is the only way to trigger a state change,

would have been perfectly acceptable as well. Boom, done. That would have been a total of perhaps 10 seconds. My answer took much longer, and I found myself giving the snake legs, invariably turning it into a lizard when the assessor asked for a snake.

Simply put, while I understood what dispatch did, I spoke so much that not only did it seem like I was speaking in the hopes that the right answer was somewhere in my explanation, but also so much that it appeared as if I did not know that answer at all.

This happened several times during the assessment, which led to us running out of time.

My assessor was kind enough to chalk it up to nerves.

Lesson Learned #2

Just because you made it work, doesn't really mean you understand WHY it works.

Okay, so this lesson is one I learn time and time again. It's easy as a new developer to think you know why things are working simply because they do. In my case, I thought I fully understood the connect() function because I had used it.

I knew, for example, that connect() connects us to the store, which holds global state.

I knew that the connect() function took in several optional parameters, the first being mapStateToProps, the second mapDispatchToProps, as well as two others that I haven't yet used, such as mergeProps and options.

I also knew that if a component did not need access to the store to pass state down to props, I'd need to pass in null as the first parameter.

What I didn't fully understand was what was happening as I handed an action-creator function to connect.

import { connect } from 'react-redux';
import {getDecks} from '../actions/decksActions';

this.props.getDecks();

export default connect(mapStateToProps, {getDecks})(GetterApp);

What I thought, and subsequently stated, was that I needed to pass {getDecks} to connect to make it available for the component to use.

Even though I knew that I had made the function available for use by importing at the top of the file, I thought that passing it to connect was the only reason I was able to use it. However, I could have called the function by simply writing:

getDecks();

Doing so wouldn't have required redux at all. It also wouldn't have worked.

Passing the action creator function to connect made it possible to invoke the function by preceding getDecks(); with this.props. It also, and most importantly, bound the dispatch of the store TO the action creator.

So here, in my action creator function:

export const getDecks = () => {
  return(dispatch) => {
    dispatch({type: "LOADING_DECKS"})
    return fetch('/decks')
    .then(resp => resp.json())
    .then(decks =>
      dispatch({type: "DECKS_LOADED", payload: decks})
    )
  }
}

I HAVE ACCESS TO DISPATCH BECAUSE IT WAS ACTUALLY BOUND TO THE FUNCTION .

Lesson Learned #3

Doubting yourself out loud is a major no-no.

When my assessor asked me to guess the order that a few console.logs would be fired, the first words out of my mouth were something along the lines of "this is going to be difficult."

While this thought spoken out loud helps me stay calm and promotes me taking a deep breath, it certainly doesn't inspire confidence.

So this lesson was short- only think out loud to show your assessor how you work through a problem.

And finally, a bright spot in Lesson #4

Be proud of however far you make it

It is SO easy and SO tempting to believe that you have to be right 100% of the time, to be afraid to make mistakes, to not want to say "I don't know." Especially when you're in an assessment.

But it's okay to make mistakes and say I don't know. Ultimately, the person on the other side is there to help you succeed either as a student, or an employee. No one wants to see you fail.

By admitting the shortcomings in your understanding, or by giving a SUPER quick explanation of why you think something works even if you're wrong, you're making it possible for the person assessing you to steer you in the right direction, or simply to explain to you what part of the puzzle you're missing.

And THAT is a win in everyone's book.

React/Redux Basics... In English

Cristal — Tue, 17 Mar 2020 01:40:13 +0000

If you've stumbled across this blog post, it is quite likely that you are a Flatiron School student and are looking for examples of projects and/or blog posts. This particular post is intended to provided some general information that might help you understand some of the necessary concepts and components(pun intended).

Friendly Reminder: it is normal to feel overwhelmed and/or anxious as you approach this and any project. You are not alone in this feeling, and it behooves you to reach out to classmates, your cohort lead, and/or your educational coach if you should ever feel this way. The Flatiron and general dev community is very supportive!

React

Container vs. Functional Component

(AKA Stateful vs Stateless, respectively)

You've likely heard all of these terms (if you're a Flatiron Student, you've read them all in the curriculum).

Let there be no confusion- a container component simply has local state. A functional component, on the other hand, does not.

CONTAINER COMPONENT / STATEFUL

import React from 'react';

class ContainerComponent extends React.Component{

  state = {
    someInfo: ""
  }

  render() {
    return(
      <div>
        <p>Hi! I'm a stateful component! You can hand me props by writing something like this.props.yourPropName!</p>
        <p>Being stateful makes me a "Container Component". Take away my state, and I'm a functional component.</p>
        <p>It doesn't matter that I look different from the functional component below! </p>
      </div>
    )
  }
}

export default ContainerComponent;

Functional Component / Stateless

import React from 'react';

const FunctionalComponent = (props) => {
  return(
    <div>
      <p>Hi! I'm a stateless component! You can hand me props by passing them into the arrow function!
      </p>
    </div>
  )

}

export default FunctionalComponent;

Local vs Global State

Remember how a stateful component (container component) holds state? That is a "stateful component"... its state is local.

Redux (which we'll get to in a moment) allows us to create global state.

What's the difference? Let's go back to our stateful component above...

import React from 'react';
import Button from './components/Button';

class ContainerComponent extends React.Component{

  state = {
    showingButton: false
  }

  showButtons = event => {
    this.setState({
      showingButtons: true
    })
  }

  hideButtons = event => {
    this.setState({
      showingButtons: false
    })
  }

  render() {
    return(
      <div onMouseEnter={this.showButtons} onMouseLeave={this.hideButtons}>
        <p>Hi! I'm a stateful component! You can hand me props by writing something like this.props.yourPropName!</p>
        <p>Being stateful makes me a "Container Component". Take away my state, and I'm a functional component.</p>
        <p>It doesn't matter that I look different from the functional component below! </p>

//look here:
        {this.state.showingButtons ? <Button /> : ""}
//
      </div>
    )
  }
}

export default ContainerComponent;

this.state.showingButons ? is a ternary statement. If true, a button is displayed when the mouse scrolls over the div. If false, nothing is displayed but an empty string.

The component itself has access to it's state BECAUSE IT EXISTS IN THE SAME PLACE. Much the way you have access to your own kitchen, your component has access to what's immediately available in its local state.

So how do we get access to global state? What IS global state anyway?

Global State and Redux

Redux allows us to create a global state that every component has access to.

If local state is the equivalent of you walking into your kitchen and going into your pantry, global state is the equivalent of you taking your grocery cart into the supermarket.

To get access to a global store, we import createStore from react-redux.

createStore takes in an argument, a reducer (or a root reducer that combines all your reducers.... one per resource). It accepts additional arguments, such as applyMiddleware, too.

What in tarnation is a reducer?

A reducer is just a function, my dude. It has two arguments- a state, and an action. A switch statement is involved, and includes an action type, provided by dispatch (don't worry, we'll get to that, too). It looks a little something like this:

export default (state={decks: [], loading: false}, action) => {
  switch(action.type){
    case "LOADING":
      return {
        ...state,
        loading:true
      }

    case "LOADED":
      return {
        ...state,
        resource: action.payload,
        loading: false
      }

    case "ADD":
      return {
        ...state,
        loading:true
      }

    case "ADDED":
      return {
        ...state,
        resource: [...state.resource, action.payload],
        loading: false
      }


    default:
      return state
  }
}

If you're thinking, "well, that's not that scary!" you're absolutely right! All you're doing is telling your application, "Hey! If you get this message (case), give me this thing, ok?"

Getting Things out of Global State

Let's think back to our first component, the stateful one. It had local state. It could go into its pantry by stating this.state.someInfo.

What if you wanted access to THE store? Well, redux gives us access to the store by giving us connect, which is imported at the top of our file as so:

import { connect } from 'redux';

Importing connect, and then providing the connection when we export the component...

export default connect(mapStateToProps)(YourAppName);

and handing connect a first argument of mapStateToProps, which we can declare like so:

const mapStateToProps = state => {
  return {
    resource: state.resourceReducer.resouce,
  }
}

Now, in our component, we can call this.props.resource and get whatever is in global state. It's like showing up at your house party with the groceries you just bought and yelling "CHECK OUT THIS.VONS.CHIPS&DIP".

How did we get to the point of getting global props?

Okay, so this is where we come to both dispatch and reducers. Our store takes in an argument of a reducer, like so:

const store = createStore(reducer);

Our reducer is something that was imported and passed on to the createStore function provided by redux.

As we saw, our reducer takes in an an initial state, and an action type. Where does this action type come from?

Well, one way to get this is by creating an action creator function. It might look something like this:

export const addResource = (resource) => {
  return(dispatch) => {
    dispatch({type: "ADD"}, resource)
    return fetch(`/resources`, {
      method: 'POST',
      body: JSON.stringify(card),
      headers: {
        'Content-Type': 'application/json'
      }
    })
    .then(resp => resp.json())
    .then(resource => {
      return dispatch({type: "ADDED", payload: resource})
    })
  }
}

If it looks confusing, just focus on the parts that matter:

export const addResource = (resource) => {
    dispatch({type: "ADD"}, resource)
}

What you should be getting from this is:

the function addResource is called, with an argument that accepts a resource.
dispatch, given to us by redux, fires off a message (or action type), and a resource.
our reducer takes the message, and the action ( a resource), and returns something to us.
mapStateToProps gives us access to whatever is returned by simply calling this.props.resource!

The equivalent would be something like having a central market, with anyone and everyone in the area (components) being able to go into the store by using { connect }, {actionFunction}, and mapStateToProps.

In other words, all these things come together to help you program an application where local state helps you deal with the here-and-now (local state) and the always(global state).

I still don't get it

I feel you. If you're not sure how to get everything working together, build a simple application. Just get it to display things on the page. Use fun event handlers and state to get some fun effects. Practice makes better, after all!

Passing Data Around in Javascript

Cristal — Mon, 17 Feb 2020 04:29:49 +0000

The Project

The purpose of this project is to take your Ruby on Rails knowledge, and add a layer of complexity to it by creating a one page application using Vanilla JS as opposed to ActionView.

Using fetch();

So you've built your backend API, and upon running your server, you're successfully displaying json. Perfect! The next step is to retrieve this information.

The boilerplate code for making this request is as follows:

fetch('http://example.com/movies.json') 
//Fetch takes in one argument here:
//the path whose resource we're trying to retrieve information from. 
  .then((response) => {
    return response.json();
  })
//we are returned a promise that contains the response object. This is 
//NOT the information we can use just yet. It is simply the HTTP 
//response.
  .then((myJson) => {
    console.log(myJson);
  });
//This second .then extracts the information we want from that HTTP 
//response.

To get a feel for the flow of information, we're going to go through the process of fetching information, creating an object from it (in this case, a pin), and then using that object's information to create a child object (a memory).

The models:

class Pin < ActiveRecord::Base
  has_many :memories, dependent: :destroy
end

class Memory < ApplicationRecord
  belongs_to :pin
end

Here is my API, displaying json rendered by my Rails application.

[
  {
    "id": 41,
    "address": "11 Broadway, New York, NY 10004",
    "label": "// Flatiron School <3",
    "latitude": 40.7053111,
    "longitude": -74.0140526
  }
]

What we see is that each pin is stored as an object in an array. Below, jsonData is returning this array, and .forEach is used to comb through each object key for its values below.

    fetch(BASE_URL)
    .then(response => response.json())
    .then(jsonData => {
    //iterates through each location object & sets variables
      jsonData.forEach((location) =>  {
        let pinId = location['id'];
        let pinLabel = location['label'];
        let pinLatitude = location['latitude'];
        let pinlongitude = location['longitude'];
    //creates a pin using above variables
        pinInfo = {
          id: pinId,
          label: pinLabel,
          coords: {
            lat: pinLatitude,
            lng: pinlongitude
          }
        }
        dropPin(pinInfo); //We're going to need this later. 
      })

PASS THE DATA!

We're going to pick up where we left off above. The last function called was dropPin, with an argument of the each pin that was created with data from the fetch function.

Our pin is dropped (code redacted to focus on the important matter at hand - passing data). A dialogue box is created when a user clicks on the pin; one of the options is below.


//Each pin carries the following:
//id, label, coords object(which include lat and lng)


    function dropPin(pin){

    <a href= "#" onclick= 'createMemoryForm(${pin.id});'> Add a Memory </a><br>


  }

Let's say our location is Disneyland. We clicked on the pin, and now we want to jot down a memory for this location. The onClick attribute in the link fires off 'createMemoryForm()', with a passed in parameter of ${pin.id} (which holds the value of id for that location). Where does this function come from?

You. It's you. You need to write the function.

Let's do that.

function createMemoryForm(pinId){
//First, we declare the function. We have it take in a parameter, and we 
//name that parameter in a way that helps us remember what we're passing 
//in. 

console.log("The function createMemoryForm has been triggered. The form should be displayed below the map.")
  console.log(`This pin has an id of ${pinId}`)
//I've logged my parameter and function namein the console for easy 
//debugging!

  let contentContainer = document.getElementById('content-container')
  //grabbed the container I want to put my form in

    contentContainer.innerHTML =  `
      <br>
      Add your memory to this location by filling out the form below:
      <br>
      <br>
      <form onsubmit="createAndDisplayMemory();return false;">
        <label for="date">Date (YYYY-MM-DD)</label><br>
        <input type="text" id="date"><br>
        <label for="description">Description:</label><br>
        <input type="text-area" id="description" ><br>
        <input type="hidden" id="pin_id" value=${pinId} >
        <input type ="submit" value="Add Memory!"><br>
    </form>  `
   //created the form

}

Can you spot the handshake between our dropPin function and the createMemoryForm function?

Let's do that again, but let's only grab the pieces we need.

// in dropPin();
<a href= "#" onclick= 'createMemoryForm(${pin.id});'> Add a Memory </a>
//clicking the link triggers createMemoryForm(); below and hands it pin.id (from above) 

//in createMemoryForm(pinId)
<form onsubmit="createAndDisplayMemory();return false;">
//focus on this next line! 
//the pinId that was handed to this function by dropPin() is given to 
//the hidden field with an id of "pin_id". 
<input type="hidden" id="pin_id" value=${pinId} >

<input type ="submit" value="Add Memory!">

The user goes on and clicks submit. Where are we going onClick? To createAndDisplayMemory();! Again, we're going to break this function into several chunks to try and make it easier to understand. Try to spot the handshake!

function createAndDisplayMemory(){

  let contentContainer = document.getElementById('content-container')
  let date = document.getElementById('date').value
  let description=  document.getElementById('description').value
  let pin_id = document.getElementById('pin_id').value

  const memory = {
    date: date,
    description: description,
    pin_id: pin_id
  }
}

Did you see it? Our form had included
<input type="hidden" id="pin_id" value=${pinId} >

The following line of code grabs that value
let pin_id = document.getElementById('pin_id').value

and then we use all the information from our form to create a memory object.

const memory = {
    date: date,
    description: description,
    pin_id: pin_id
  }
}

Do you see the critical piece? We grabbed pin_id! What is pin_id on our memory table?

A FOREIGN KEY!!!!!!!!!!!!

What this means for us is that our memory will be sent to our database and given its own unique id. That memory will also know who it belongs to. Done over and over again, each new and unique memory will have a foreign key that corresponds to its has_many resource. Cool, right?

Let's finish creating a memory for this pin.

fetch(BASE_URL+'/memories', {
    method: "POST",
    body: JSON.stringify(memory),
    headers: {
      'Content-Type': 'application/json',
      'Accept': 'application/json'
    }
  })

We send a POST request, and hand our newly created memory to the body of the request :
body: JSON.stringify(memory)

 .then(response => response.json())
  .then(memory => {
    contentContainer.innerHTML =""
    contentContainer.innerHTML = `
    <br>
    Date: <br>
    ${memory.date}<br><br>
    Description:<br>
     ${memory.description}<br>
     <a href='#' onClick='editThisMemory(${memory.id})'; return false;>Edit this Memory</a><br>
     <a href= "#" onClick= 'deleteThisMemoryWarning(${memory.id});'> Delete Memory </a>
    `
  })

Then we executed our remaining .then functions to return the newly created memory. We can expect to see that memory's date, and description.

If you're reading closely, you'll also notice that we have two new links with onClick functions:

<a href='#' onClick='editThisMemory(${memory.id})'; return false;>Edit this Memory</a>

and

<a href= "#" onClick= 'deleteThisMemoryWarning(${memory.id});'> Delete Memory </a>

Each function is handed a memory id. Can you guess what happens next?

.....

We write those two functions, and continue the handshake, of course.

Some hot tips:

HOT TIP 1

When POSTing, PATCHing, DELETEing, you don't necessarily need to use the two .then's that are part of the boilerplate fetch code. Only use your .then's if you need data returned to you so that you can display it.

HOT TIP #2

BUILD YOUR CODE AS YOU GO, AND GIVE VARIABLES SEMANTIC MEANING.

Naming things in a way that is easy to read, and that simply makes sense, will save your life. Especially if you build the functions you need as you go.

&& that's all, folks!

As always, thank you for reading, and please feel free to reach out with critiques, comments, suggestions, and/or questions.

Keep it real, y'all!