DEV Community: DylanC

Simple Calendar Functions

DylanC — Thu, 30 Jan 2020 03:27:48 +0000

I recently created a Search Bar to see the process of creation and how I could get it to work. It was a tremendous help in getting my head to wrap around the intricacies of creating and running such a thing.

So when it came time to implement a few calendar features, I chose to do the same thing. I feel most comfortable implementing features and tools when I can understand what makes them truly work. Building the features/tools myself (when I have time) is my preferred method of accomplishing this goal.

I had some experience creating minimal calendar functionality with Ruby on Rails before this. This post was my first time attempting these features with a ReactJS Frontend & Rails backend. After completing this task, I plan to test and implement a calendar library to see the differences, which I'll be writing about next week.

The main functionalities I need are:

Ability to create a lesson on a particular date. Preferably with a calendar date selector.
Have start and end times for each lesson. Preferably with an easy to use time selector.
Have both the date and times associated with the lesson object on the backend.
Last but not least, have all of these properties accessible for viewing and editing later.

One

With the help of React Bootstrap Forms, the first goal was easy to achieve.

<Form.Group as={Row} controlId="dateGroup">
      <Form.Label column xs={1}>Date:</Form.Label>
            <Col xs={2}>
                <Form.Control required type="date" rows="1" name="date" onChange={this.handleChange} />
            </Col>
</Form.Group>

Two

After a bit of research into trying different options with date and time connected, I decided to separate the concerns. After discovering there was a 'date' type for form, I also discovered there's a time type.

<Form.Group as={Row} controlId="timeGroup">
      <Form.Label column xs={1}>Start Time:</Form.Label>
           <Col xs={2}>
               <Form.Control required type="time" rows="1" name="start_time" onChange={this.handleChange} />
           </Col>
      <Form.Label column xs={1}>End Time:</Form.Label>
           <Col xs={2}>
                <Form.Control required type="time" rows="1" name="end_time" onChange={this.handleChange} />
           </Col>
</Form.Group>

While my original goal was to create and associate at the same time, this method is simplistic, even with dealing with the separation later.

Three

This goal took slightly more work. Because of the separation of date and times, I would deal with them individually. This method ended up working out in the end, as it gave me more flexibility to manipulate and send data back and forth the way I wanted to. To start, Javascript and Ruby have different beliefs on the format a date should be by default. Ruby: Mon, 01 Jan JS: Wed Jan 01 2020 12:00:00 GMT-0500 (Eastern Standard Time)

In usual fashion, JS is trying hard to be overly helpful while Ruby keeps things simple. Depending on the use case, one can be more helpful than the other. But in this scenario, I needed a universal standard. In addition to the different language date formatting, when passed through a fetch request, like all things over the internet, it becomes a string. Because I prefer to keep objects as objects, especially when going from front to back end, I converted them each way to a standard. This function took care of formatting when displaying to the user:

The start and end times had similar obstacles, which I dealt with similarly. The previous separation of date and times allowed for easier conversions. The counterpart to the previous formatDate function:

Four

The majority of my time went into this goal. Partly due to deciding to add new features as I went on. The last goal previewed viewing date and time. The editing became a mixture of the creation and viewing of a lesson.

However, after making the create, view, and edit functionalities, I decided I wanted one more feature. In most calendar implementations, there's the ability to create recurring events. This goal was the most challenging and enjoyable.

Five

I started with what I knew. It needed a way for the user to select the frequency (Once, Weekly, Monthly):

With my first attempt, I left it a once, one week, or one month. But I quickly decided I wasn't happy with having such limited options. So I added an amount for the frequency:

This option allowed the user to select how many weeks or months.

I used a simple switch statement to handle the user input:

switch (this.state.occurrence) {
    case 'Weekly':
      [...]
    break;

    case 'Monthly':
      [...]
    break;

    default:
      [...]
  }
};

Default would handle the 'Once' option as it's the only option that did not require an additional choice. The fun part came next. Creating the algorithm to add weeks or months to the user input. After trial and error and some mixed results, this was the final weekly case statement:

case 'Weekly':
    this.props.createLesson(this.state, this.props.history)
    let i = 1;

    let dayDate = new Date(this.state.date);

    while ( i < this.state.occurrenceNumber){
        const newDayDate = this.addDays(dayDate, 7)
        dayDate = newDayDate

        this.props.createLesson(this.state, this.props.history, dayDate)
        i++;
};

this.addDays() was the heavy-lifting function:

addDays(date, days) {
  const nextDate = new Date(Number(date))
        nextDate.setDate(date.getDate() + days)
  return nextDate
};

Monthly was similar with addMonths adding 30 days to the date. Unfortunately, this simple implementation does not take into account over 30 day months or leap years. Something that given more time, I would like to change.

The Default case had a simple one liner:

this.props.createLesson(this.state, this.props.history)

After taking care of how to make the calculations. I needed to connect the changes to the Rails backend:

The create lesson action:

export const createLesson = (lesson, history, date) => {
    if (date) {lesson.date = date.toISOString().split("T")[0]}
    return dispatch => {
        fetch(`[...]`, {
            method: 'POST',
            headers:{
                'Content-Type': 'application/json',
                'Accept': 'application/json'
            },
            body: JSON.stringify({ lesson })
        })
        .then(resp => resp.json())
        .then(lesson => {dispatch({ type: 'LESSON_CREATED', payload: lesson})
        history.push(`/lessons`)
        })
        }
};
```



I won't go into too much detail as most of it's a standard asynchronous fetch request between JS and Rails. A couple of key points; The `history.push()' commands are there to redirect the page after creating/editing. 

The `if (date) {lesson.date = date.toISOString().split("T")[0]}` was added after creating this goal. It takes into consideration that if the date is undefined because the frequency is 'Once', the request won't break. However, if there is a date argument, it converts into the universal format I chose before sending it to the Rails side.

### Conclusion 

Coming up with elementary solutions to solved solutions isn't always possible with time and resources. But I find it incredibly rewarding, educational, and the best way to understand what I'm asking the code to do. Reinventing the wheel every time doesn't make sense, understanding how the wheel works to manipulate it down the road better, absolutely makes sense to me. For my post next week, I'll take a look at the different calendar library solutions, how to implement them, and how they differ from my simple solution.



### Attribution
Cover Photo by [Roman Bozhko](https://unsplash.com/@romanbozhko?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)

Quick React Bootstrap NavBar

DylanC — Thu, 23 Jan 2020 02:15:36 +0000

React-bootstrap's documentation is incredibly helpful. Probably some of the best I've come across. However, as a newbie, getting to the point of implementation and testing can seem a little confusing at times. If you'd prefer to read the technical side without the introduction, skip to 'The Bar' section.

The Need

My experience with designing user interfaces is quite small. Before The Flatiron School, at my job at an IT consulting firm, I created terminal/command prompt tools for mostly automation or limited user/technician interaction. While you can thoughtfully place prompts, colors (which quickly become too much.), and information, there aren't many options to make it a more desirable interaction.

In my previous projects, I dabbled with a bit of CSS. Putting bits of code together to make something like this:

And others to create more reactive star ratings like this:

My next attempt was using the Bootstrap gem to create a navbar:

It was simple and served it's purpose entirely at the time.

For the latest attempt, I wanted a navbar that felt a little more fluid and enjoyable, especially since a user has to stare at it throughout the app. After trying other components with React-Bootstrap, it was an easy decision to give their styled navbar a try. Once implemented, following the documentation to fulfill your needs is rather simple. There are a plethora of options you can test and use to make a professional and attractive Navbar. So, on to the good part, how I quickly implemented it.

The Bar

The Navbar component itself is simple and pretty much covered on the Navbar documentation. Here's the code I used for interest and reference:

import React from 'react';
import { connect } from 'react-redux';
import { Navbar } from 'react-bootstrap';
import NavDropdown from 'react-bootstrap/NavDropdown'

const NavBar = () => {
  return (
    <Navbar bg="black" variant="dark" sticky="top">
      <Navbar.Brand>
      <img
        src="./logo.png"
        width="30"
        height="30"
        className="d-inline-block align-top"
        alt=" "></img>
      </Navbar.Brand>
        <NavDropdown bg="black" title="Menu" id="collasible-nav-dropdown" style={{ color: "#5299d3" }}>
        <NavDropdown.Item style={{ color: "#5299d3" }} href="/">Home</NavDropdown.Item>
        <NavDropdown.Item style={{ color: "#5299d3" }} href="/welcome">Admin</NavDropdown.Item>
        <NavDropdown.Item style={{ color: "#5299d3" }} href="/users">Users</NavDropdown.Item>
        <NavDropdown.Item style={{ color: "#5299d3" }} href="/lessons">Lessons</NavDropdown.Item>
        <NavDropdown.Item style={{ color: "#5299d3" }} href="/challenges">Challenges</NavDropdown.Item>
      </NavDropdown>    
    </Navbar>
  );
};

export default connect()(NavBar);

To import the component, it's as you would expect in a React app: import NavBar from './components/Navbar';

Which I included in the App.js component, which is where I also implemented react-router-dom to route the component pages: import { BrowserRouter as Router, Route} from 'react-router-dom'

Integrating the navbar into the rest of the components threw me off a bit. Ultimately I found the simplest was also the best solution (Other routes replaced with '...' for presentation purposes):

Conclusion

With this navbar version, I was able to add a simple logo, dropdown menu, and the app's universal font I previously chose. While I decided to have the navbar remain at the top as the user scrolls, the transparency keeps the fluid aesthetic across the app.

Attribution

Cover Photo by Alexander Andrews on Unsplash

The Great Search [bar] - Part 2 - Deep Dive

DylanC — Wed, 15 Jan 2020 18:48:08 +0000

Part one was more about the overview of why I bothered to create my search bar instead of copying other code. This time, I’ll focus on the technical or how and why I implemented it.

Retrieval

Before I even started with the search bar, I needed to ensure the component wouldn’t break if the users’ list took a bit longer to fetch. Slower networks may not respond in a desirable amount of time. After beginning the fetch request for the list, I used a simple ‘if’ statement with a more user-friendly react-bootstrap spinner component, if the fetch was still completing.

Display

After retrieving the current lesson for the user. The search bar needs to render and connect to the component state for later use.

I used a simple form to display the bar, with a bit of react-bootstrap for styling and positioning.

With the state holding the search term, or last name:

While the state updates with every keystroke by the user:

The first iteration of the search bar required the last name to be input and submitted before the search began. As the form is submitted, it invokes the function ‘handleSubmit’:

Once I had completed the search bar functionality, I found it very cumbersome and not as intuitive for the user as I would have liked. Whenever I do create something that requires user interaction, I prefer it to feel effortless and, if possible, familiar. So I added a function that we’ll see later on in another component which rendering invokes. With this, the search would perform with each input change. Thus, giving the user faster and distinct confirmation of the search functioning.

Then the important step. Rendering the results and giving the option to check-in. I felt this was a good point to separate the concerns of rendering the interface and the actual searching. We’ll get back to why this.props.history passes to <SearchResults/>

Search

Before I built the search bar, I rendered another component,<RetrieveCurrentLesson/>, which (you guessed it) renders the current lesson. Understanding how it functions isn’t as important as it’s output. If there were no lessons for the day, it would display ‘No lessons today.’ Otherwise, the current lesson would display with start & end times. The code responsible for this:

I chose this way for a few reasons:

It showed the user there were ‘No Lessons’ instead of blank or undefined.
I thought there would be more confusion if I chose the next lesson to display even if it wasn’t for that day. Even though theoretically, there should be no students if there are no classes. I was building for a less specific and more scaled use.
I could leverage the response of ‘No Lessons’ for the next component.

If there were no lessons for the day, I had to ensure that not only was it stated, but there was also no way to check-in by accident. So, as the component renders, it invokes a simple function to determine whether the check-in button should be enabled or not.

After handling the no lesson errors, the search functionality comes next. When the component renders, it invokes this.filterUsers(this.props) and maps over the output to display the user that matches the search term. The function itself filters the user list and compares the last name to the search term.

With the selected user now being displayed with first name, last name, and rank. The button to check-in and attach the user displays with the following code <Button variant="success" disabled={!isEnabled} onClick={() => this.attachUser(user)}> Check-In </Button>:

Association

When the button is enabled and clicked, it invokes the attachUser function and passes the user as an argument. attachUser has a few responsibilities.

First, it grabs the currentLesson from the redux store or props. It can then add the user to the list of users associated with the lesson and invoke the associateUser action, made available through redux export default connect(state => ({ currentLesson: state.currentLesson }), {associateUser})(SearchResults).

As you can see, associateUser is a pretty standard fetch asynchronous request. It updates the provided lesson and expects the updated lesson back as the payload. I also added the history prop we previously passed down, which allows me to use this: window.location.reload(false). It reloads the page, leaving it ready for the next user to check in with a cleared search bar. The 'false' argument tells window.location.reload to reload from cache if possible. Reloading with cache is faster and won’t affect the search bar functionality.

Conclusion

I enjoyed going through each step and having to research every option to decide what was best for my situation.

In the future, I’d like to experiment with large data sets to see if the constant rendering of components due to user input change, makes a performance difference. With the small data set I used and the overall better user experience, I preferred this way.

If you have any questions or comments on how I can improve this, let me know! I’m a ~~junior~~ developer, I’m always learning and improving.

Code Repo

If you'd like to check out more of the code or suggest improvements. Here's the repo:

dclements9 / Hara-Frontend

Martial Arts Studio Management System (Frontend)

Attribution

Cover Photo by Andrew Ridley on Unsplash

The Great Search [bar]- Part 1 - Context

DylanC — Thu, 09 Jan 2020 03:14:45 +0000

I’m new to writing blog posts. So I’m trying something out. I’m splitting the more technically detailed portion from the less technically. Feel free to let me know if it feels silly to be separated or keeps it more coherent. Part 2 - Deep Dive coming soon.

While a simple Google search reveals many ways to create a Search Bar with React & Javascript, I wanted to create my own to understand how it works. If you’d like to skip the extended version, head to 'The Implementation’ section or check out the technically detailed post coming on Tuesday.

The Project

My most recent project was creating a React client for a Rails API. I created an uncomplicated martial arts studio management system. The administrator can create users/students, lessons/classes, and student challenges. While the student side would be able to sign in when they attend class.

For the student sign-in, I planned to implement a clean and intuitive search bar. The student would type their last name, and their information would populate with the option to check-in. Keeping it simple, easy, and to the point was my main focus. Unfortunately, I had no idea where to start. Like my time with The Flatiron School had taught me, I started with what I knew:

The search bar had to be able to fetch all the users
After retrieving the users, it would have to filter the users
It would then need to display the user’s information clearly for the user to read.
It would also need to display a functional button to check the user in
The current lesson would need to be retrieved to be attached to the selected user.
Ideally: It would be able to do this all while the user was still typing

The Knowledge

All of this felt reasonable to achieve, and while I wrote the pseudo-code, it started to come together. I knew how it should function, but I was hazy on how the implementation. So as any developer does when confronted with a lack of knowledge, I went to Google. Unsurprisingly, there are many methods people use to implement a search bar.

While I read through the various techniques, I could understand the processes, but I couldn’t understand the reasons for their designs or why I would prefer one over the other. I didn’t feel comfortable using code I couldn’t fully explain the reason behind using. So I decided to create my own.

The Implementation

First Step - Search Bar

The search bar renders a form for user input assigned to the searchTerm state.

Second Step - Current Lesson

On the initial render of the home page component, <RetrieveCurrentLesson /> retrieves the current lesson. Once mounted, the component fetches all lessons. It then filters the lessons by date & time to find the nearest lesson to the current date & time. Afterwards, <DisplayCurrentLesson lesson={nextLesson} /> is called to handle displaying the contents.

Third Step - State

As the user input changes (the user enters or removes a character), the searchTerm state is updated:
handleChange = (e) => { this.setState({ [e.target.name]: e.target.value })}

This state is then passed to another component: <SearchResults searchTerm={this.state.searchTerm} />

Fourth Step - Search

The users list passes to the SearchResults component after being fetched from the home page component. Much like the current lesson, the user is then filtered based on the searchTerm state from User input.

As a user’s last name matches a user in the users list, it is displayed along with a button to ‘Check-in’.

Fifth Step - Association

The button rendered with the searched user associates the user with the current lesson. The home page then renders a cleared form, ready for the next user to ‘Check-In’.

Conclusion

As they say, “There’s more than one way to skin a cat.” Ultimately, I’m glad I went through the trouble of creating my method. It forced me to understand the workflow and design. Even if it’s not the most efficient method, I’m proud of it and can always improve.

Attribution

Cover Photo by Andrew Neel on Unsplash

Second Photo by Evgeni Tcherkasski on Unsplash

The Flatiron Experience

DylanC — Mon, 06 Jan 2020 21:45:42 +0000

I originally posted this on my Flatiron blog on November 29, 2019. But I wanted to share my experience with others. So here it is:

373 days, that’s how long it’s been since I was accepted to The Flatiron School and began my life long journey of learning to code. At the time, I understood it would change my life, but I didn’t truly understand the magnitude of change. But before I get to my experience of the past year, a little backstory/introduction.

Introduction

I discovered coding first in college after spending a couple of years searching for what I wanted to pursue. I fell in love with code and graduated with an Associates in Computer Science. After graduating, I found an internship at an IT consulting firm, which unfortunately didn’t involve much coding. Long story short, life has a way of changing our plans, and I ended up spending 7 1/2 years there.

Two kids and a few gray hairs later, I found myself missing coding more than ever. I fell in love with the whole process: creating and debugging code, diving deep to find the real “bug”, and even that headbanging feeling when you just can’t figure out what’s going wrong. Enter ‘The Flatiron School’.

The Search

I spent a couple of months researching different boot camps. The on-campus boot camps were either too far away or a bit too late to make it to every week, so I focused on online programs. As I narrowed it down further and further, it began to feel a little like pulling a random name out of a hat. They all seemed terrific, graduates were happy for the most part, and employment rates were relatively high. Ultimately, it was The Flatiron School that won out for me. But it wasn’t until I thought about what I wanted to get out of a program and what I enjoyed doing, that I decided.

The Flatiron School is big on community and support. Of course, every school says the same thing about the importance of both. But Flatiron talks the talk and walks the walk. They not only give you a support group in the form of an educational coach, cohort lead, and a cohort of like-minded learners; they also teach you how to make your own community going forward. Sounds too good to be true, right? Exactly what I thought as I decided to take the plunge. Happily, I discovered it is quite real.

The Coach

With all the forms of support intertwined, it’s difficult knowing where to start. So let’s begin with the educational coach, the person I didn’t realize I would need as much assistance from as I did. She introduced herself by explaining the difference between an educational coach and a therapist. On your journey, there will be ‘potholes’, an educational coach will help you navigate around them and get you back on the path, while a therapist will stop for a while and help you dive right into the hole. Turns out, when you’re on an accelerated learning path of dealing with complex ideas, this is incredibly useful and precisely what you need.

About halfway through the program, I was finishing up with my second project and decided to venture out to the local tech/coding group meetup. I was terrified. I consider myself a social introvert. I love interacting and working with people, but a roomful of strangers is a little daunting. My coach told me exactly what I needed to hear. Not just the usual ‘You’ll be fine. Push through it. You’re worth it!’ Sort of thing. She gave me specific, actionable advice. She taught me how to manage my anxiety, get my feet wet without throwing myself in the ocean, and how to push past my comfort zone while remaining calm. After I successfully survived the meetup, it was much easier when it came to Codeland 2019 and a couple of other conferences this past year.

Comrades in Arms

Which brings me to the next part of community and support, your classmates. During the Flatiron program, it can feel very intense and overwhelming. While having loved ones to support and assist you through all of this is imperative; no-one understands quite like other Flatironers. My cohort quickly became an immense help in not only the technical support side of things, but making me feel like I wasn’t alone in all of the stress, worry, and of course the dreaded imposter syndrome (Which knocked me down a few times). They’re always there to lend a helping hand when they can, or to remind us all that we’re still very much students and don’t know everything!

So when Codeland Conf 2019 time came around (Which by the way is one of the most amazing experiences, even if you’re not a beginner), I took the plunge into the great unknown of going to a conference by myself gasp . I ended up having the time of my coding life! I met up with other Flatiron students, both past and present. We all seem to unspeakably understand one another’s trials and found a little piece of ourselves in each other. Even after the conference, they were (and are) one of the essential points of coding community and support.

The Lead

My last major point of community and support was anything but the least. Every cohort is given a cohort lead, which is a little bit deceiving of a title; at least I thought it was. I thought they would be strictly leading the way by lessons, giving pointers here and there. But she was so much more. Flatiron has spent a significant amount of time on both their program material and fostering supportive cohort leads.

Our lead taught us not only extra bits of material each week, she also taught us how to learn, how to dig into the problem and find the solution, how to push through failure, how to believe in ourselves without second-guessing (this one was big for me), and how to enjoy the process without becoming overwhelmed. She was very subtle about it all too. I slowly found myself internalizing all her lessons beyond the technical aspect and found myself becoming a better problem solver, which in turn made me a better coder and code partner. She especially had a talent for asking the right question to make you work your way to the answer, not give you the answer, even in the most ‘stuck’ situations. She’s a big reason I didn’t throw my code out and give up. Instead, she empowered me to keep moving and give my best’ till the end.

The Point

I can easily make blog posts for each point I spoke about, and I’m sure other boot camps have similar aspects. But I can only speak of my experience. I feel like I made the right choice in the end and didn’t regret a moment of it. Flatiron is so much more than a school or boot camp, it’s a family. This family takes care of each other; whether they’re separated by years or countries, they’re always there for each other when they can be.

To me, that is what made this experience truly special, successful, and well worth every ounce of blood, sweat, and tears I gave to it. I’m going to miss every single person who has changed my life so drastically this past year. I can’t thank everyone enough. They have all contributed to the mindset I now have of breaking problems apart, starting with what I know, and solving the problem step by step. Career coaching (via the Flatiron program) and job hunting here I come!

Attribution

Cover Photo by Duy Pham on Unsplash

First Photo by Banter Snaps on Unsplash

Second Photo by Banter Snaps on Unsplash

Practice Makes Perfect

DylanC — Thu, 09 May 2019 04:50:04 +0000

Six weeks go by quickly, especially when you’re learning a skill that plunges you ever deeper into an endless world of excitement. Looking back, I can hardly believe I’ve learned as much as I have.

I started my CLI project about two weeks ago, thinking I knew what I needed to complete it. But I wanted to solidify that knowledge. Practice makes perfect. But creative practice fills in the gaps you didn’t know were there.

The project needed to scrape a website, provide the user with information, and have a command-line interface to interact with the program. I chose to scrape an event schedule to create an agenda for the user (GDG DevFest 2018). While properly learning to iterate through, filter, and attach my scraped results to an object, my best friend was Pry.

I could go on and on about my love for Pry. But I’ll try to share a few of my favorite commands of Pry instead. While the most fundamental benefit of Pry is to essentially ‘pry’ open code, there is so much more to it.

If you’re familiar with the terminal on a Unix system, you’ve probably used the ‘ls’ command to list files and folders. Pry has something similar. The ‘ls’ command will show you a list of possible methods and variables for the location you pried open. While this may seem like a trivial command by itself, when combined with other commands, it becomes mighty.

Which brings me to my next command, ‘play’. More specifically, ‘play -l’ will play the line specified next. This command also provides a relatively easy way to step into or around blocks and iterations. When it’s combined with ‘ls’, you can follow changes to variables and methods as they happen.

My last command is more of a tip of how to use a command than an actual command. While outside of a ‘do’ block, ‘exit’ will exit from the program. But while inside, it can provide valuable information about each iteration the block goes through, giving much needed debugging support.

Overall, this was a very tiny piece of what I’ve learned about this project. But I’ll save that for another post. The journey continues!

Attribution

Cover Photo by Jordan Sanchez on Unsplash