DEV Community: independnt

Using CSS Grid to create responsive web design

independnt — Fri, 07 Dec 2018 21:02:10 +0000

If you're at all familiar with web design, then you know that finishing your designs in CSS can really just be the middle ground. We still need to accommodate the user experience for tablets and mobile phones. More than 50% of web activity is now processed on a mobile platform, so nowadays, the mobile first design should really be the mindset. This dawned on me immediately after I brushed my shoulders off after having finished styling my online portfolio, which looked pretty great I might add. However, pull it up on a phone? It looked like hot garbage. That's where I got to learn about the importance of media queries. Altering the CSS based on the screen size. Now, elbows deep in React and using styled components, along with CSS grid, I find myself once again at the divide where queries would normally guide the way. Luckily, CSS grid has handy tools, known as the auto-fill, and auto-fit properties which can alleviate some of these previously tedious tasks.

Media Queries

Previously, if I wanted my application or page to be responsive, I would have to individually choose window sizes, and css that i wanted to scale with it, specifically regarding rows/columns with individual items. For example, it would look something like this:

@media only screen and (max-width: 767px) {
    body { font-size: 16px;}
    section { padding: 30px 0;}

    .row { padding: 0 4%; }
    .col {
        width: 100%;
        margin: 0 0 1% 0;
    }

@media only screen and (max-width: 1200px) {
  .row { padding: 0 2%;}
}

Here, i'm selecting the widths and dictating the specific row paddings and widths, which all works, and definitely makes the site more responsive, but recently working with react and having a page that works with grid, I came across auto-fit and auto-fill which made my life a lot easier.

auto-fit

Taking into example an app that takes an item and places it into a column on a grid format.

export const CoinGridStyled = styled.div `
  display: grid;
  grid-template-columns: repeat(5, 1fr);
  grid-gap: 15px;
  margin-top: 30px;
`

Here this gives us 5 columns, each at a fraction of the page, regardless of size. Even though if we expand the window, or shorten it, there will always be 5 items per row, simply adjusting in size. But if we were to change this to auto-fit like so:

  grid-template-columns: repeat(auto-fit, minmax(130px, 1fr));

Now the row will always fit what it can. So expanding the window, will yield more than 5 items per row, depending on the size, and up to 130px, will do the same. So now, my row will have a minimum of 2 items (the max it can fit at 130px) or up to 10, as the window expands. But this means that even if i only have One item, it will stretch that item to fit the page length. More precisely auto-fit "fits the currently available columns into the space by expanding them so that they take up any available space. So instead, in this case, I like auto-fill.

auto-fit

Here, we'll include this code:

  grid-template-columns: repeat(auto-fill, minmax(130px, 1fr));

Now, with auto-foll it "fills the row with as many columns as it can fit". So now, objects are not being stretched in any way. There is a set amount of space, and each object takes up the space is needs and no more.

Now with gird, we won't always need media queries, thank the lord.

Styled Components pt 2

independnt — Sun, 02 Dec 2018 20:04:35 +0000

Recently I started using Styled Components to make styled divs in order to make styling individual information easier, now that I'm digging a bit deeper, I've been using them to build upon each other's styles in order to make certain components react based on conditionals!

For instance, I've been working on an application that has the ability to add, remove, or nullify certain components based on conditionals. I have a grid at the bottom, which allows the addition of objects, and I have a top section, where the newly added objects are displayed. The bottom grid should allow for adding the objects, the top grid should allow for the removal of objects, and any objects that have already been added should be nullified, thus eliminating the possibility for duplications.

First, we create a styled div, with our default desired styles, this is the base style we expect for every component wrapped in this div.

///Imported 
///subtleBoxShadow = `box-shadow: 0px 0px 5px 1px ${lightTheme ? '#a9b6ff' : '#121d5b'}`;
///lightBlueBackground = `background-color: #061a44`;
///greenBoxShadow = `box-shadow: 0px 0px 4px 2px #5fff17`;
///redBoxShadow = `box-shadow: 0px 0px 2px 2px #e41111`;


export const Tile = styled.div `
  ${subtleBoxShadow}
  ${lightBlueBackground}
  padding: 10px;
`

Now we can create additional styled components building upon our base "Tile". We now want selectable tiles, with a cursor action on hover, so we add one more. This time, instead of styled.div, we do styled(Tile) so we can build upon the already shown base style.

export const SelectableTile = styled(Tile)`
  &:hover {
    cursor: pointer;
    ${greenBoxShadow}
  }
`

Now we build two more to handle our Deletable Tiles and our Disabled Tile (to avoid duplicates).

export const DeletableTile = styled(SelectableTile)`
  &:hover {
    cursor: pointer;
    ${redBoxShadow}
  }
`

export const DisabledTile = styled(Tile)`
  pointer-events: none;
  opacity: 0.4;
`

Now we have our selectable tiles with a green shadow on hover, but our deletable tyles will override those styles and add a red shadow on hover. Lastly our disabled tiles has a pointer-events set at none, with opacity showing it has been selected and removing the click event action.

Now in the desired component, I set the "Current Tile" variable to our imported Selectable Tile that was created and throw in some conditionals. I add a topSection prop to all tiles in the top section, and create a method called "AlreadyInFavorites()" to find if the desired selected tile is already in my favorites state. Now my function which I'm exporting looks like this:

export default function({coinKey, topSection}){
  return <AppContext.Consumer>
    {({coinList, isInFavorites}) => {
      let coin = coinList[coinKey];

      let TileClass = SelectableTile;
      if(topSection){
        TileClass = DeletableTile
      }else if(isInFavorites(coinKey)){
        TileClass = DisabledTile
      }
      return <TileClass>
        <CoinHeaderGrid topSection={topSection} name={coin.CoinName} symbol={coin.Symbol}/>
        <CoinImage coin={coin}/>
      </TileClass>
    }}
  </AppContext.Consumer>
}

For a little "Context".... ahem. I'm using React context and returning a Consumer which will update upon the state changing. I'm passing it "coinList" from my state which houses all the objects. I se Tileclass equal to my Selectable Tile div, and say that if the object has the topSection prop equaling true, then this means its on the top section and should be deletable, so set to Deletable Tile. If the tile already exists on my favorites, then on the bottom section (where it was originally added from) we make it a Disabled Tile, so we can't add it again. Styled components is changing the way I will create styles and hover/click events moving forward in React. Definitely a new favorite!

Random Vanilla Javascript

independnt — Sat, 24 Nov 2018 00:18:12 +0000

Thus far, I've tried to keep myself fresh on ruby, ruby on rails, React, CSS, HTML, Javascript algorithms, and some JQuery. However, recently I went on a job interview that asked me about my skillset on all of the above, except for JQuery. On the contrary, they actually hated JQuery and had entirely removed it from their application. They said and I quote "Thank god we had removed all of our JQuery from our application like 2 weeks ago, now we're running on pure vanilla Javascript". Now I understand the concept of why this is a good thing for their application, but for me? Not such a great thing, because my vanilla Javascript level is what some may call "eh". So I've made it a point to do a little vanilla Javascript every day, one tiny project at a time, and I've learned a few small, miscellaneous things that I didn't necessarily know before.

Now I know all about the DOM, I'm well aware of how to manipulate it, and even how to select items I want to change. Before I began my vanilla Javascript challenge, I would mainly rely on things like "document.selectbyID" or "document.selectbyClassName" but was completely unaware of "document.querySelector" and "document.querySelectorAll". Both of which can be used effectively for grabbing certain elements. Important little tidbits about the two to note is that query selector returns a node, and querySelectorAll returns a node list, so it won't come with all the usual array commands you may be used to. Looking into its prototype you'll see you can utilize functions like forEach(), but not many others. Fear not, you can always use "Array.from()". Another big difference is the syntax and browser support. SelectById and SelectByClassName have been around a lot longer, so it may be safer to just stick with that instead, but interesting either way!

The Query selectors can also be used as a CSS3 selector as well. Setting a variable to a queryselector of a class can be altered, which can come in handy. For instance:


<div class="Random-line"></div>

const example = document.querySelector('.Random-line')

example.style.transform = `rotate(90 deg)`

Now this will go into the CSS and we can set our transoform style to 90 degrees, causing the line to shift 90 degrees.

Also, while playing around with an application that had several different controls, one being an input with the type of "range" and one being "color", i was able to grab all of the controls, by doing the following:

  const inputs = document.querySelectorAll(`.controls input`)

Now I have all my inputs for all controls on the page! Also, we're able to use forEach to add eventListeners on all of them!

  inputs.forEach(input => input.addEventListener('change', handleUpdate))

Now we can create a handleUpdate function to listen for changes and handle those updates! Very cool. These have come in handy and I'm sure will continue to in the future.

Run Time Complexity for Beginners (like me!)

independnt — Fri, 16 Nov 2018 21:20:03 +0000

A majority of the time when we're writing javascript and algorithms, we know that as in all of programming, there is almost always a better way to write something. Sometimes it looks nicer, or may just seem easier to understand, but Run Time Complexity specifically references the amount of time that it takes to run the code you've written or in simpler terms, it describes the performance of an algorithm.

So how do we figure out how we can find out what the complexity of our algorithms could be. There are different kinds of 'runtime', which is decided based on how your algorithm runs. For example, if we have a function that requires a for loop of any kind, and given a single argument, the for loop has more items to iterate through, based on the length of input. For instance, reversing a string.

function rev(str){
    let rev = ""
    for(let i = str.length - 1; i >= 0; i--){
        rev += str[i]
    }
    return str
}

For every input, our computation has to iterate through the string one more time for every additional character in the string. Fairly simple, and because the we're doing one more step for one more character, that would be referred to as a linear runtime. There's a direct correlation between the number of characters and the amount of steps at a 1:1 ratio, thus, linear.

Now, if we were to have something that has more than one for loop, and occasionally, it's necessary. If there are two for loops for whatever function, there is now double the amount of processing power needed. Let's say we have a function that needs to iterate once, and then iterate again. Let's take an instance where a function has nested for loops. This indicates that for every additional input character given, the function now has to do way more work. An example shown to me was a function to console.log a staircase.

function stairs(input){
    for(let row = 0; row < input; row++){
        let stair = '';

        for(let column = 0; column < n; column ++){
            if(column <= row){
                stair += '#';
            }else {
                stair += ' ';
            }
        }
        console.log(stair)
    }
}

Here, as the input increases, the steps the function needs to perform increases exponentially. With an input of 2, we had to perform 4 actions. With 3, we had to perform 9 things and so on. This is what's referred to as Quadtratic runtime, or n*n things (N^2).

The most Common that I've read about are as follows:
Linear Time (discussed above)
Quadratic Time (discussed above)
Constant Time
Exponential Time
Logarithmic Time
Quailinear Time

Lets briefly touch on each of the remainders.

For Constant Time, the word constant is key. All this means is that regardless of input, the operation will always take the same amount of time. so something like this:

function FifthItem(list){
    return list[4]
}

regardless of size, this will always computate at the same runtime, thus the name, constant. (O(1))

Exponential time is considered, among those listed, to be the least efficient. The reason being is that an exponential timed solution means that adding only one additional character, doubles the processing power needed for the solution. This is obviously very bad. (2 ^ n)

Logarithmic Time is if the elements given are doubled, but the outcome does NOT double the amount of work needed. Usually searching through a sorted array of data, or any kind of search, these are usually running with logorithmic time. (log(n))

Lastly, Quasilinear Time. Similair to Logarithmic Time, this is when doubling the number of elements being iterated does not double the amount of work, but adds to it by 1 plus a little more. This is one I dont fully understand yet, but that's why I'm here. (n * log(n))

That's all for today!

React Context

independnt — Fri, 09 Nov 2018 21:25:48 +0000

Since graduating from The FlatIron School, Redux has been the jelly to Reacts peanut butter. The pasta and meatballs. Stone Cold Steve Austin and Beer (Although I hear he's recently quit drinking. Besides the point). I could go on. However, I've recently stumbled upon React Context which is a fairly newer paradigm in terms of handling state in components. Maybe I don't always need Redux, because with Context, I can pass down state to components without having to use props. My thoughts when I heard this? Whaaaaaaaaaaaat. According to the documentation, it should be used sparingly because it can make component reuse difficult. Let's use Context to refactor a crypto dashboard I'd been working on from a previous blog post.

The first thing that needs to happen, is we need to create a Context and in the scope of my current project, I simply created a new file named "AppProvider.js". This is not a component that will render anything other than it's children. It will more so be a container for the projects state. First thing's first, we'll import React and create a new Context using the React createContext function:

    import React from 'react';
    export const AppContext = React.createContext()

Now we have a Context object. The key aspect of understanding how Context works is understanding the Provider and the Consumer relationship. Keep in mind, I'm still learning and this is all to the best of my understanding. Providers are React components that accept a value prop, in this case, state. Once the Providers value changes, all Consumers of that Provider will re-render. A Consumer is also a React component which according to the docs, subscribes to context changes.

With that said, let's move forward. I'm refactoring how state is handled in my current project, in this case, how the application knows which page to render. So in my newly created AppProvider.js I will create the state, as I would in any component like so:

  export class AppProvider extends React.Component {
      constructor(props){
        super(props);
        this.state = {
          page: 'dashboard',
          setPage: this.setPage
    }
  }
}

Now you'll notice that I also have something called setPage in the state. That will be my updater function. I know it's strange to pass functions into the state, but according to the Context docs, it indicates that state should hold the updater function. So let's define that function now:

    setPage = page => this.setState({page})

Last, let's create our Provider, as mentioned earlier.

    render(){
    return (
      <AppContext.Provider value={this.state}>
        {this.props.children}
      </AppContext.Provider>
    )
  }

Now, all children can have access to the state, all that's left is to choose our consumers, and import them where necessary. First, i need to wrap the component that needs access to the state in my new AppProvider object. I'll go into the needed file and import/wrap:

import {AppProvider} from './AppProvider'

class App extends Component {
  render() {
    return (
      <AppLayout>
        <AppProvider>
          <AppBar/>
          <WelcomeMessage/>
        </AppProvider>
      </AppLayout>
    );
  }
}

Now AppBar and WelcomeMessage have access to the information needed. Going into AppBar, we can now create Consumers by creating a ControlButton function and returning a Consumer component:

function ControlButton({name}){
  return (
    <AppContext.Consumer>
      {({page, setPage}) => (
        <div
          onClick={() => setPage(name)}
        >
          {name}
        </div>
      )}
    </AppContext.Consumer>
  )
}

My function takes a name (which is labeled in a name prop in each individual ControlButton) and returns AppContent.Consumer, creating a new Consumer component, which then takes the current page in the Provider state, and the setPage function and returns a div that has an onClick handler, which now uses the setPage function to change the page in our Provider state.

Phew. Well, that's just the basics for now, more experimenting with Context later. Signing off.

Simplifying React state and styled components

independnt — Mon, 05 Nov 2018 00:32:53 +0000

I've been in the middle of a course going through how to create a cryptocurrency dashboard, which has been great for learning new tricks regarding the organization of React Components, and how to structure their code in an organized, efficient fashion. Mainly, how to deal with state, and how to re-use common styles that will be used throughout the coding process.

One thing that the application wanted to do was check to see if this was a visitors first time visiting the application, and this was achieved by setting a state object as "first visit". Our state in its current form is:

this.state = {
      page: "settings",
      ...checkFirstVisit()
    }

You can see, I have no "firstVisit" attribute currently, only a checkFirstVisit function, prefixed by the ... spread operator. This is because with checkFirstVisit, we want to update more than one state attribute. 'checkFirstVisit' was implemented like this:

const checkFirstVisit = () => {
  let cryptoDashData = localStorage.getItem('cryptoDash')
  if(!cryptoDashData){
    return {
      firstVisit: true,
      page: 'settings'
    }
  }
  return {}
}

Here we check for a localStorage item that indicates we've been here before, if it exists, then the checkFirstVisit function returns an empty object, leaving state unchanged. However, should it not be present, we return two attributes to update our state with, firstVisit which sets to true, and the page attribute, which is set to 'settings', indicating what page we should land on. So now, first time visitors will always be directed to settings, all we had to do was make sure that every time state is loaded, we run checkFirstVisit, which is done by including it in the state. I've been trying to implement the spread operator more into my code, along with functions like this to set states based on certain requirements.

I've also been trying to make my code more friendly by not repeating myself, especially in the design department. Here in this application, i had several styles that i wanted to re-use, and instead of using styled components and re-writing every time i wanted a color, or shadow, I instead added a Style.js, which included several exports for styles I would be re-using.

export const fontColorGreen = `color: #03A9F4`;
export const lightBlueBackground = `background-color: #061a44`;
export const subtleBoxShadow = `box-shadow: 0px 0px 5px 1px #121d5b`;
export const greenBoxShadow = `box-shadow: 0px 0px 4px 2px #5fff17`;
export const redBoxShadow = `box-shadow: 0px 0px 2px 2px #e41111`;

Now these styles can be imported into the desired component like so:

import {subtleBoxShadow, lightBlueBackground, greenBoxShadow} from './Style';

and once I created a styled component, i could implement them into the code to style said components like this:

const CoinTile = styled.div `
  ${subtleBoxShadow}
  ${lightBlueBackground}
  padding: 10px;
  &:hover{
      cursor: pointer;
      ${greenBoxShadow}
  }
`

Now anytime i need any of those styles, i can simply call upon them using ${} within any of my styled components, all i need to do is import them from my style.js folder. This leaves my code more organized, easier to edit and debug across the board. That's all for now, adios!

Stateless Components

independnt — Sun, 28 Oct 2018 20:07:46 +0000

When first starting out in React, and even beyond, I had mostly made all of my components stateful, even though the component had no need to maintain a state. But is that a bad thing? Well, short answer is yes, and for more reasons than one.

A stateless component is something that can be declared as a function, and can act as a full on stateful component, granted it’s given the necessary props. Besides the obvious of not retaining it’s own state, stateless components also don’t adhere to the component lifecycle methods. It also has no backing instance (object in memory where the state is stored). So essentially, a stateless component is just a function that’s returning JSX expressions.

Being able to create stateless components allows us to not only save memory, which is always a good thing, but it allows us to keep our code clean and simple. Recently I was working on a React Application that required a navbar, and prior to exporting the nav into it’s own stateless component, it looked like this:

However, now, what we do, is we simply create a new file, and remove the html located within, and move it to a stateless component, and call it as a function like so:

Notice that when i call it as a function, i use the function key word as opposed to arrow functions, the reason being that with arrow functions, we bind this, which we don't want in this particular instance. Now, we can simply replace all that code in App.js and insert our new stateless component.

The reason I’m using .call(this) is to bind the context of this in App.js to the child, so we can access things like this.state from App.js.

Stateless components have really changed the way that I write in React, and I plan on using them as much as possible to save memory for my applications. Perfection!