DEV Community: Michael Porter

Drag and Drop with the GRANDstack

Michael Porter — Wed, 19 Aug 2020 20:23:06 +0000

This tutorial assumes you have basic familiarity with React, Apollo, and Neo4j

While planning my most recent side project, I decided to play with a feature that I've always wanted to mess with on the front end, drag and drop functionality. It didn't take long to find out that there are a number of highly regarded drag and drop libraries for React but, after reading docs and reviews I decided that React-beautiful-dnd was going to fit my use case. In addition it came boxed up with a very nice free tutorial course which you can find here. None of the code pertaining to the drag and drop functionality is mine, I adapted it from the tutorial, my only contribution being that I created it with hooks vs. class components. You'll need to complete their tutorial before you start this one

Lets get started!

After you've completed the drag and drop tutorial from Egghead, to start here all you need to do is pick up the starter GRANDstack project, clone it and get it spun up in your preferred IDE. After you've got the project up and running we'll need to add these types to your schema.graphl file:

type Task {
 id: ID!
 content: String!
 column: Column @relation(name: "BELONGS_TO", direction: "OUT")
}
type Column {
 id: ID!
 title: String!
 tasks: [Task] @relation(name: "BELONGS_TO", direction: "IN")
 table: Table @relation(name: "BELONGS_TO", direction: "OUT")
 taskIds: [ID]
}
type Table {
 id: ID!
 title: String!
 columns: [Column] @relation(name: "BELONGS_TO", direction: "IN")
 columnOrder: [ID]
}

When our data is added our graph will look something like this.

Lets go ahead and add data to our graph, open the Neo4j desktop, copy and paste this Cypher code:

CREATE(t1:Table {id: "t1", title: "Test Table", columnOrder: []}),
(c1:Column {id: "c1", title: "New Test Column", taskIds: []}),
(c2:Column {id: "c2", title: "New Test Column 2", taskIds: []}),
(c3:Column {id: "c3", title: "New Test Column 3", taskIds: []}),
(tk1:Task {id: "tk1", content: "Task 1"}),
(tk2:Task {id: "tk2", content: "Task 2"}),
(tk3:Task {id: "tk3", content: "Task 3"})
with t1, c1, c2, c3, tk1, tk2, tk3
CREATE (t1)<-[:BELONGS_TO]-(c1)
CREATE (t1)<-[:BELONGS_TO]-(c2)
CREATE (t1)<-[:BELONGS_TO]-(c3)
CREATE (c1)<-[:BELONGS_TO]-(tk1)
CREATE (c1)<-[:BELONGS_TO]-(tk2)
CREATE (c1)<-[:BELONGS_TO]-(tk3)

This will create the graph structure we're after. Next, run these two cypher commands:

match(t:Table)
match(c:Column)
with t, collect(c.id) as ids
set t.columnOrder = ids

and

match(c:Column {id: "c1"})
match(t:Task)
with c, collect(t.id) as ids
set c.taskIds = ids

This sets up the initial ids and ensure that our columns start out correctly. With that done we'll be able to get started.

Here's a link to GitHub repository for the completed project. You'll be picking up at the point where you've got multiple columns and are able to swap the order of tasks and also swap them between columns. Up until this point, there's been no back end for the project so any changes that you've made will be undone when you refresh the browser or navigate away. Additionally, we're getting our application state from an object that's been created vs. calling API and that's what we'll add and fix next.

If you haven't cloned the repo and have instead been following along with the Egghead.io tutorial adding Apollo to our project is going to be easy. Simply install it with yarn or npm whichever your preferred method for me, it's yarn:

yarn add @apollo/client

In previous versions of Apollo you'd need to install quite a few other packages but in V3 they all come bundled together. After we've installed Apollo we need to create a new client in the root of our application:

index.js
import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import '@atlaskit/css-reset';
import App from './App';
import {ApolloClient, ApolloProvider, InMemoryCache} from "@apollo/client";
const client = new ApolloClient({
 uri: process.env.REACT_APP_GRAPHQL_URI || 'http://localhost:4001/graphql',
 cache: new InMemoryCache(),
})
ReactDOM.render(
 <React.StrictMode>
 <ApolloProvider client={client}>
 <App />
 </ApolloProvider>
 </React.StrictMode>,
 document.getElementById('root')
);

And that's all we need to get up and running with Apollo Client, make sure you've changed the appropriate environment variables or pointed the client at the correct locally running GraphQL API. With that done we're able to go ahead and start querying our Neo4j instance and making the application update and maintain our data in real time. In our App.js file we're going to add a GraphQL query and some mutations that will allow us to capture our application's state. First we'll need to import our needed tools from @apollo/client:

import { gql, useMutation, useQuery } from "@apollo/client";

Then we can create our query, for brevity I'm including this in the App.js file but as the size of your application grows you might consider breaking queries and mutations out into their own files. First, we'll want to get our table or page and it's associated columns and tasks from our Neo4j instance.
In this case, I'm calling the table by name:

const GET_TABLE = gql`
    query GetTables($title: String){
        Table(title: $title){
            id
            title
            columnOrder
            columns{
                id
                title
                taskIds
                tasks{
                    id
                    content
                }
            }
        }
    }
`

This query allows us to get the specific table we're after. It pulls the columns out and tasks along with it. In order to use the query we need to add it to our component:

const {loading, error, data} = useQuery(GET_TABLE, {variables: 'Test Table'});

This allows us to add directly query our Neo4j instance and get that data we need but first we'll need to make some changes to the application as a whole and manipulate the data returned to fit our current structure.

Data Object From Egghead tutorial
At the current state of the application you should be using this initialData object to set your state. However now that we're going to be pulling data in via our API well need to change it from this:

const initialData = {
  tasks: {
    'task-1': {id: 'task-1', content: 'Take out the garbage'},
    'task-2': {id: 'task-2', content: 'Watch my favorite show'},
    'task-3': {id: 'task-3', content: 'Charge my phone'},
    'task-4': {id: 'task-4', content: 'Cook dinner'},
  },
  columns: {
    'column-1': {
      id: 'column-1',
      title: 'To do',
      taskIds: ['task-1', 'task-2', 'task-3', 'task-4'],
    },
    'column-2': {
      id: 'column-2',
      title: 'In Progress',
      taskIds: [],
    },
    'column-3': {
      id: 'column-3',
      title: 'Done',
      taskIds: [],
    }
  },
  columnOrder: ['column-1', 'column-2', 'column-3'],
};

to this:

const initialData = {
  tasks: {

  },
  columns: {

  },
  columnOrder: []
}

This gives us the structure of the data we expect before the application is actually able to load it, keeping us from getting rendering and null errors. To ensure that we're getting our data correctly from the API and not encountering async errors we're going to add useEffect and make use of Apollo's loading, and error states.

useEffect(() => {

  if (data) {
    setTable(data)
  }
}, [data])

if (loading) {
  return <div>...Loading</div>
}

if (error) {
  console.warn(error)
}

These actions take place before the component has rendered allowing data to be fetched and more importantly for our fetched data to be reshaped into the form our application is expecting. We do this in our setTable function, which is called in useEffect once it's verified that we have data.

const setTable = (data) => {
  const {Table} = data;
  const tasks = {};
  const columns = {};
  const columnOrder = Table[0].columnOrder;
  // Pull all tasks out into their own object
  Table[0].columns.forEach((col) => {
    col.tasks.forEach((task) => {
      tasks[task.id] = {id: task.id, content: task.content}
    })
  });
  // Pull out all columns and their associated task ids
  Table[0].columns.forEach((col) => {
    columns[col.id] = {id: col.id, title: col.title, taskIds: col.taskIds}
  })

  const table = {
    tasks,
    columns,
    columnOrder
  }

  setState(table)
}

This step is important because our data returned from our GraphQL API is in the shape we requested in it from out GET_TABLE query, and needs to be reshaped in order to properly fit our application. As it is, this gives us a basic frame work to start saving the state changes of our data in our data base.

Saving Column Order
The first thing we're going to add to the application is the ability for the application to save changes in the order of tasks on a particular column. To do this, we'll add a mutation to update the state of the column, this Mutation is automatically created for us by the GRANDstack's augmented schema functionality. In application we need to send the mutation with all of the info that the column has and in this case we're interested in returning the column ID.

const COL_UPDATE = gql`
    mutation UpdateColumn($id: ID!, $title: String, $taskIds: [ID]){
        UpdateColumn(id: $id, title: $title, taskIds: $taskIds){
            id
        }
    }
`

We'll then add the useMutation hook to our application:

const [colUpdate] = useMutation(COL_UPDATE)

I've omitted the optional error and data properties and I'll be handling this in a very simple way in our onDragEnd function. Where there's a column update we'll add the update function, pardon the wall of text that follows:

const onDragEnd = (result) => {
  const {destination, source, draggableId} = result;

  if (!destination) {
    return;
  }

  if (
    destination.droppableId === source &&
    destination.index === source.index
  ) {
    return;
  }

  const start = state.columns[source.droppableId];
  const finish = state.columns[destination.droppableId]
  if (start === finish) {
    const newTaskIds = [...start.taskIds]
    newTaskIds.splice(source.index, 1);
    newTaskIds.splice(destination.index, 0, draggableId);

    const newColumn = {
      ...start,
      taskIds: newTaskIds
    };

    const newState = {
      ...state,
      columns: {
        ...state.columns,
        [newColumn.id]: newColumn
      }
    };

    setState(newState);
    colUpdate({
      variables: {
        ...newColumn
      }
    })
      .catch(error => console.log(error))
    return;
  }

You'll see that after the new column state is updated, we do the same with our UpdateColumn Mutation changing the order of the taskIds array and preserving the order of the tasks. At this point, our application will be saving the order of the tasks no matter what column they're moved to but it will also be duplicating tasks because we're not removing them from their old columns. Also because this data is stored in a GraphDB we've got swap the relationships as well. Meaning that when the task moves from one column we have to sever the relationship with that column and create a new [:BELONGS_TO] relationship with the new column. We accomplish this with another set of auto-generated mutations:

const REMOVE_TASK = gql`
    mutation RemoveTaskColumn($from: _TaskInput!, $to: _ColumnInput!){
        RemoveTaskColumn(from: $from, to: $to){
            to {
                id
            }
        }
    }
`

const ADD_TASK = gql`
    mutation AddTaskColumn($from: _TaskInput!, $to: _ColumnInput!){
        AddTaskColumn(from: $from, to: $to){
            to {
                id
            }
        }
    }
`

These mutations allow us to remove the relationship between a task and a column and then also create a new relationship between the same task and a new column. We bring these useMutation hooks in as:

const [addTask] = useMutation(ADD_TASK);
const [removeTask] = useMutation(REMOVE_TASK);

and add them into our onDragEnd function along with our UpdateColumn mutation to capture all the changes occurring when we swap a task between columns.

colUpdate({
  variables: {
    ...newStart
  }
})
  .then((data) => {
    const {data: {UpdateColumn: {id}}} = data;
    removeTask({
      variables: {
        from: {id: taskId},
        to: {id}
      }
    })
      .catch(error => console.log(error))
  })
  .catch(error => console.log(error))

colUpdate({
  variables: {
    ...newFinish
  }
})
  .then((data) => {
    const {data: {UpdateColumn: {id}}} = data;
    addTask({
      variables: {
        from: {id: taskId},
        to: {id}
      }
    })
      .catch(error => console.log(error))
  })
  .catch(error => console.log(error))

The promise chaining is a little ugly but it works and now our tasks properly change relationships when moved. In our original graph we had:

And now we're able to see our changes if you move "Task 1" to "Test Column 2" you'll get this result from your graph:

And finally move "Task 3" to "Test Column 3" and you'll end up with:

And now we've got drag and drop functionality enabled in our GRANDstack application. You can see that it's a little more complicated than it might be with a SQL data base because you have to work about the relationships but luckily the auto-generated mutations and Apollo make it super easy to work with. So go forth and drag and drop all the things!

Trying Out Recoil - Facebooks New React State Management Library

Michael Porter — Wed, 20 May 2020 20:34:19 +0000

Recently pretty much out of the blue we've had the Facebook team's new React state management library, Recoil, dropped on us at React Europe. You can watch here as Dave McCabe, breaks down the new library and it's features. He does an excellent job of explaining the types of the problems that the library is trying solve and in the video he demos a neat looking canvas application. After watching the video I wanted to try my hand at the building a similar app with React, Recoil, and D3.js.

To get started all you need to do is spin up a create-react-app and then add recoil to the project at the root. Like so:

import { RecoilRoot } from 'recoil';

<RecoilRoot>
  <App />
</RecoilRoot>

This will give you the ability to access recoil elements anywhere in your application.

To begin with, the most basic elements of Recoil are called atoms. You create an atom to represent a piece of Recoil state:

import { atom } from 'recoil';

const newAtom = atom({
   key: 'someUniqueKey',
   default: {}
})

You can then use Recoil's many different hook methods to use the atom's value anywhere in your application that's wrapped by the RecoilRoot. Almost all of the hooks will be familiar to anyone who's used React Hooks but you'll see some changes such as, useRecoilValue, useSetRecoilState which allow you to purely consume the Atom's state or provide a callback function to manipulate the Atom's strength. This takes a little getting use to vs the normal:

const [value, setValue] = useState(''):

That you see in regular react hooks but to me it's a welcome change that allows you to be very specific with what you're calling and how.

In addition to Atoms, Recoil brings with it Selectors which allow you go manipulate the state of atoms and return derived state. Using an example directly from the Recoil docs:

const filteredTodoListState = selector({
  key: 'filteredTodoListState',
  get: ({get}) => {
    const filter = get(todoListFilterState);
    const list = get(todoListState);

    switch (filter) {
      case 'Show Completed':
        return list.filter((item) => item.isComplete);
      case 'Show Uncompleted':
        return list.filter((item) => !item.isComplete);
      default:
        return list;
    }
  },
});

You can see that selector allows you the ability to get the value of an Atoms state, manipulate it, and then return a new value as derived state. While I didn't make use of this in my demo app, I'm going to try to do more with it in the future. Speaking of which.

You can find my demo app here.

The app allows you to create D3 element circles and squares and then manipulate them in via a simple interface. There's a link provided to the github repo on the page where you can check out the code but the basics are I use Recoil to create individual Atoms for each circle and square that you create. The Atoms are simple:

export const circleWithID = (id) => {
    return (
        atom({
            key: `item${id}`,
            default: {
                id,
                cx: 50,
                cy: 50,
                r: 15,
                fill: "#3942e0",
                offset: {

                }
            }

        })
    )
}

This provides me a default circle and I can then retrieve it no matter where from anywhere in the application with the unique key or identifier:

const [circleState, setCircleState] = useRecoilState(circleWithID(props.key))

In my demo I'm directly accessing the state of each item in two components. The SVG circle or square it's self, to manipulate the state while dragging and also the card that pops up with each component. This way the SVG element in fully interactive. If I wanted to create something to select and deal with multiple elements I could then create a selector and have access to selected items, something like this:

export const selectedItems = selector({
    key: 'selectedItems',
    get: ({get}) => {
        const items = get(itemList).map(i  => get(itemWithID(i)))
        return items.filter((item) => item.selected)
    }
});

At any rate, that's my small example of Recoil please check out the offcial docs and announcement video for more info.

Neo4j and GraphQL Heavenly Match #1 - Directional Relationships

Michael Porter — Sun, 05 Jan 2020 15:11:00 +0000

Easily one of the most useful features of the GRANDstack's integration with GraphQL is the ability to create and express directional relationships between nodes in your graph, or entities in your data. A simple example would be two friends, which you could express in your GraphQL Schema like:

type Person {
  name: String
  friends: [Person] @relation(name: "FRIEND", direction: "OUT)
}

You can easily expand on this simple schema and add any amount of relationships that you desire like; favorite restaurants, hangouts, workplaces, family, etc. In addition if you want to place properties on the relationship you can do that as well by making the relationship itself a type in your schema, lets say you want to track a persons work history:

type Workplace {
  name: String
  address: String
  pastEmployees: [Person] @relation(name: "WORKED_AT", direction: "IN")
  currentEmployees: [Person] @relation(name: "WORKS_AT", direction: "IN")
}

type WorkedAt @relation(name: "WORKED_AT"){
   startDate: Date
   endDate: Date
   startSalary: Float
   endSalary: Float
}

You then expand your Person type:

type Person {
  name: String
  worksAt: WorkPlace @ relation(name: "WORKS_AT", direction: "OUT")
  workedAt: [WorkPlace] @relation(name: "WORKED_AT", direction: "OUT")
}

This gives you the ability to easily create a complete history of work for your Person and allows you to track current and past employees of your Workplace. The connections between the two then provide you the ability to dig deep into the history of both. What if you wanted to know the life time average ending salary for your person? Because you're using the GRANDstack you have access to Cypher directives via Neo4j:

type Person {
  name: String
  worksAt: WorkPlace @ relation(name: "WORKS_AT", direction: "OUT")
  workedAt: [WorkPlace] @relation(name: "WORKED_AT", direction: "OUT")
  avgEndingSalary: Float @cypher (
     statement: "MATCH (this)-[r:WORKED_AT]->(:WorkPlace) return avg(r.endSalary)
}

You can see how this ability to query relationships and the properties on them allows you to add a wealth of depth and detail to your application. You don't have to stop there, with the dates provided you can track avg time spent at each job or get the exact amount of days a person worked somewhere, the number of details you can now extract from this data only grows. The directional nature of the relationships set also allow you to control the flow of information and you can begin to use Graph Algorithms to make sense of your data. Want to find the shortest path between two companies via past or present employees? There's a Graph Algorithm for that! Want to find a person who can act as a bridge between two companies? There's a Graph Algorithm for that too! Being able to create and track these numerous relationships and their properties is just one of the reasons that GraphQL and Neo4j with the GRANDstack are a match made in heaven.

note: This is a simple use case and would not be optimized for very large data set queries.

Video - How The GRANDstack Makes Handling Complex Data Easy

Michael Porter — Thu, 17 Oct 2019 16:06:16 +0000

NODES Neo4j Online Developer Summit

click on the picture for video

Neo4j & GraphQL - A Match Made In Heaven

Michael Porter — Fri, 23 Aug 2019 14:57:58 +0000

For the last 8 months, I've been working on my first paying job as a freelance software developer. It's a project that I conceived of, pitched, and sold to a business despite the fact that up to that point, I'd never built any kind of enterprise level software project. I've written a bit about my journey as a software developer and if you care to you can read some of my posts both here or on Medium that delve deeper into that part of the story. But it suffices to say, this project was a huge leap for me. So you might be wondering, how I was able to sell this idea much less accomplish it?

The answer, probably given away by the title, is that I was able to leverage the power of graphs, specifically, the Graph Database Neo4j and GraphQL everyone's favorite jumped up query language. When I discovered Neo4j I was immediately impressed by the way it was able to express highly connected data and how I could easily use the built-in data visualization tools to explore the data. I could “see,” the data in a way that I’d never been able to when using a SQL database or thinking in terms of tables and foreign keys. When you look at a graph you can literally understand how to traverse it, which makes getting from A to B and all points in between easy.

When it came time to the pitch the project I was able to give the clients a detailed view of how their data was connected and I was going to handle the complexity of their use case. Essentially, I showed them this:

Instead of this:

One is easily understandable with no training or special knowledge, the other is not. Anytime the client had a question about to handle certain situations I could pull up a simple example from the data I had and walk them through it step by step, with labeled relationships. It was a slam dunk, I convinced a room full of technology adverse people to let me digitize their data and take a chance on an untried software developer.

In the same way, pairing Neo4j with GraphQL via the GRANDstack gives me the ability to get exactly the data I want, how I want it. Do I want an assignment doc, with all it's accompanying info? No problem. Build it out in your schema like this:

type Assignment {
    id: ID
    volPage: String
    book: String
    effectiveDate: String
    dateFiled: String
    docType: String
    comments: String
    wellsDrilled: String
    grantor: Operator @relation(name:"GRANTOR" direction: "IN")
    grantee: Operator @relation(name:"GRANTEE" direction: "OUT")
    totalAcres: Float @cypher(
        statement: "MATCH (this)-[r:ASSIGNMENT_INTEREST]->(:Tract) return sum(toFloat(r.acres)) "
    )
    assignmentInterests: [AssignmnentInterest]
}

and when you query, you get an object back shaped like this:

query {
  Assignment {
    id
    volPage
    book
    effectiveDate
    dateFiled
    docType
    comments
    wellsDrilled
    grantor {
      id
      name
    }
    grantee {
      id
      name
    }
    totalAcres
  }
}

Neo4j-graphql-js allows you to make direct use of Neo4j's graph features in your api. Want to link two nodes? Simply tell your schema that a relationship exists. Want to place properties on the relationship? Make it a type:

type AssignmnentInterest @relation(name: "ASSIGNMENT_INTEREST"){
    id: ID!
    from: Assignment
    to: Tract
    acres: String
}

Want to do some math or something a little more complicated? Use Neo4j's query language Cypher to do the dirty work for you.

avgMineralPercentage: Float
    @cypher (
        statement: "MATCH (:Tract)<-[r:MINERAL_OWNERSHIP]-(this) return avg(r.mineralPercentage)"
    )

The ability to traverse the graph from one end to the other in a single network request is amazing and at times feels a little like having data super powers. I won't get too far off into the weeds of specific examples, it's enough to say that pairing Neo4j and GraphQL have given me the ability to tackle a difficult problem and make it look easy. I will write more soon about specific use cases and examples. Until then, if you're looking for a way to make your make your data wrangling easier check out these two technologies and see if you feel like I do, that they were meant to be together - a match made in heaven.

The Tipping Point - Part 2: The Stack

Michael Porter — Fri, 07 Dec 2018 12:21:24 +0000

Let me begin by saying that my introduction to databases was pretty rocky. At the time I encountered ORM and it's assorted concepts I was working 60 plus hours a week, attending an online boot camp, and going to my local community college full time. Looking back on it, I may have bitten off more than I could chew. There were certainly areas that suffered because I wasn't able to focus on them as much as I would have liked and databases, specifically SQL databases fall squarely in that category.

I can lay the blame on being busy but mostly I just looked at the way SQL databases were organized and thought, "There's got to be a better way." The entire system of primary and foreign keys, immutable schemas, and data normalization just didn't make sense to me. I passed the class, by the skin of my teeth, but mostly it left me with a distaste for SQL databases that can be summed up for me as the real world just doesn't work that way. Now before the hate piles up on me, I know that these databases have existed since well basically the invention of modern computing. That they've stood the test of time and are widely used the world over but that doesn't mean they're the best or only way. So began my search down the road of NOSQL databases.

Because of its massive popularity, I almost immediately found my way to MongoDB. I liked that it was schema agnostic, I liked that the concept of documents and collections made almost immediate sense. I picked it up and begun to play around with it on some small MERN stack applications, working through tutorials and using it for a python web scraping application. Despite all of this it still wasn't really exciting, it didn't bring anything new to the mix besides being more intuitive and easier to use so I kept searching. That's when I found Neo4j.

Now for a database professional or data wrangling master Neo4j might not have been any kind of revelation but for me, it was immediately revelatory. Finally, I had found something that just made sense. There was an almost audible click inside of my head the first time I saw a Neo4j representation of a graph and how easy the relationships were to understand and traverse. In it, I knew I had found a way for this SQL simpleton to finally be able to model the relationships that I was hoping to work with. On top of that, the built-in visualizations for data beat the hell out of any ERD diagram I'd ever seen. Just look for yourself.

For me, the difference was clear. The Neo4j diagram requires no explanation to understand vs. the ERD diagram with its crows feet and non-intuitive structure. Now, of course, I've said before that I'm biased but having used Neo4j on projects for clients it's also great to see how quickly they can absorb the data and relationships right along with me. It's an incredible tool for presentations and explaining data. The patterns it helps to map are incredibly intuitive to people regardless of their knowledge of databases. People are visual, and having such a great visual way to show their data, hooks clients, almost immediately. In addition, the relationship labels are immediately humanly understandable which makes a massive difference when dealing with well just about anyone.
I'm going to wrap this up by saying that I've chosen the Grand Stack because of its use of Graphs and how easy, to me, they are to understand. GraphQL for the API, Neo4j for a Graph Database, graphs all the way down. In my next post, I'll go over Neo4j's GraphQL integration and how much easier it makes the development experience. In the meantime, you can check out the GRANDstack for yourself.

The Tipping Point - Part 1

Michael Porter — Fri, 09 Nov 2018 02:54:30 +0000

I began working toward my goal of becoming a software developer since 2016. I've blogged about it off and on when I find the time and inspiration. My most popular effort has been my first, When Going it Alone Quit Working(Or How I Learned to Love Programming) and a year and a half after writing that post I'm happy to be able to say a few things:

One, that I've been a working software developer for almost a year.

Two, in addition to my day job, where I write mostly Python web scraping code, I've been able to teach myself full stack web development using React, Node.js, and NoSQL databases like MongoDB and Neo4j.

Three, I'm ready to take all of this to the next level and build something that quite honestly, I'm not sure I'm ready to and it looks like this.

Now you may be looking at this, scratching your head, and wondering what exactly it all is. To make a long story short, it's a graph of relationships that exist between land and mineral owners and the oil companies that lease their land to drill oil and gas wells. Here's a subset picture of those relationships. The problems involved in tracking these relationships are myriad but I think I know how.

In case you haven't read anything I've written before, just know that I live in the middle of a massive oil boom in West Texas. While I've been successful in getting myself out of my muddy boots and into an office writing code, I've been unsuccessful in getting myself to a different geographical location (which is changing soon) and so many of the jobs that I find to do are still oil related. It's simply where the money is here. I do side work for a family-owned company automating some of the more arduous tasks and out of that work I've identified a problem that I think I can solve for them with the skills that I've learned.

The past year has been an amazing learning journey. I've entered into a mentorship program to learn JavaScript and it's best practices. I got a Udacity Nanodegree from their React/Redux program and whenever I get the chance I've been taking every tutorial I can get my hands on to learn GraphQL and how to build databases, my favorite being the NOSQL offering Neo4j. I've worked to round myself out and be a true full stack developer. I've reached the tipping point where I feel like I can take all of these skills and create something real. I hope to detail the problem I'm trying to solve, the technologies I've chosen and why in this series.

ES6 Destructuring with Crayons

Michael Porter — Sat, 22 Sep 2018 23:03:31 +0000

Recently I've begun a mentorship program to become a better developer. In my day to day work, I focus mainly on Python but I like to try to keep my hand in other languages and so I spend time working on Express.js, Node.js, and React.js projects as well. I was in one of the first Udacity React Nanodegree classes and though I made it through the program and earned my Nanodegree, it was mostly because I worked my tail off and ground through the concepts. To make a long story short, I made it through but I was far from mastering the content.

One of the core concepts that the course went over but that I didn't really grok on the first pass was ES6 destructuring, specifically the spread and rest operations. I was able to barely get through the Redux portion of the course with a rough understanding of the concept and a lot of help from the mentor Udacity assigned me. Since then, I've gotten a pretty good handle on the concept and as a former Marine, I've decided to break it down crayons and glue style, in true jarhead fashion.

If you don't get the joke or understand the reference suffice to say that when Marines make fun of each other or other branches do, we're basically assumed to be dumb enough that eating crayons and glue is something we do. Now, I've been out of the Marine Corps for almost 20 years but I still think of myself as one and when I really want to make sure that I understand something I try to break it down "Crayon" style for myself and others. So, in keeping with a true crayon breakdown of a concept here's how I came to understand the concept of the Rest and Spread operations.

For my example, I'm going to use a Javascript object representing a box of crayons.

const boxOfCrayons = {
 yellow: "yellow",
   blue:  "blue",
   red:   "Red"
}

Let's say we're super happy with our crayons, just making little suns, and pools of water and red houses but after a time we get bored drawing basic things over and over and we'd like a little more variety in our drawings or our hour devours if we're Marines. Here's where Spread comes in.
To make a new object we Spread the crayons out and add our new objects:

const biggerBoxOfCrayons = { ...boxOfCrayons,
                purple: "purple",
                green:  "green",
                orange: "orange"
               }

This copies all of the objects in our original box, adds the new color objects into our box, and now we have an even larger box of crayons to use in our art projects or to add just the right amount of new wax for our culinary endeavors. However, we might be purists. We only really like to eat our yellow and blue crayons. The rest are just overcomplicated and overwhelm our basic pallets. So we destructure the Bigger Box of Crayons:

const { blue, yellow, red, purple, green, orange } = biggerBoxOfCrayons

and make a smaller box, a pure box:

const pureBox = { blue, yellow }

Now, we've got our pure box of only the most delicious crayons. But what if we're more adventurous? What if we like every crayon except those? Well, this is where Rest comes it.

Very literally, the Rest operation gives you the rest of an object. In this case, if we don't want our yellow and blue crayons we just want the rest all we have to do is pull those out of our bigger box, like this.

const { blue, yellow, ...keepers } = biggerBoxOfCrayons

We take our box of crayons, designate the colors we don't want and then simply mark the ones we want as keepers or as the REST!
Then we make our new Delicious box:

const newDeliciousbox = {...keepers}

That's the simplest way this crayon chomping, glue swilling former Jarhead could figure out how to break down how to use Spread and Rest in ES6. Thanks for taking the time to give it a read. May your crayons always be fresh and your glue always be Elmer's.