DEV Community: indiejesus2

Check Yourself: Populated Forms and Checkboxes

indiejesus2 — Wed, 06 Oct 2021 03:30:48 +0000

Last week, I reviewed what I had learned about using Formik when building various forms for my project. As I’ve continued to work on my project and worked more with Formik, I began experimenting with edit forms that are populated with user information from props. This week, I’m going to share how I managed to display data for checkboxes HTML elements.

When working with forms, it is pretty reasonable to make the connection that creating a profile or adding a job leads to needing a page to edit the information. It is fairly easy to develop as most of the code will remain the same, the only difference is the need to populate the information as values in the form. This is pretty straightforward when working with text boxes as the values are set to the corresponding input element.

<FloatingLabel label="Title">
    <Form.Control type="text" name="title" value={formik.initialValues.title} onChange={formik.handleChange}</FloatingLabel>
<FloatingLabel label="City">
    <Form.Control type="text" name="city" value={formik.initialValues.city} onChange={formik.handleChange} />
</FloatingLabel>
<FloatingLabel label="State">
     <Form.Control type="text" name="state" value={formik.initialValues.state} onChange={formik.handleChange} />
</FloatingLabel>
<FloatingLabel label="ZipCode">
    <Form.Control type="text" name="zipcode" value={formik.initialValues.zipcode} onChange={formik.handleChange} />
</FloatingLabel>

This can become slightly more challenging when working with different elements like checkboxes, radios or select elements. As a quick refresher, checkboxes can be used when multiple inputs can be inserted into a table column, very simple when working with the original add form. For a checkbox to be pre-selected when it is displayed on the user interface, the checked attribute must be inserted into the element. Originally, I thought I would have to write out every single element with the differing value, and specify that it should be checked if it matches the values provided, in this case by props.

<Form.Check name="jobType" label="Part-Time" value="PT" id={`inline-checkbox-2`} onChange={formik.handleChange} defaultChecked={formik.values.jobtype}/> 
<Form.Check name="jobType" label="Contract" value="Contract" id={`inline-checkbox-3`} onChange={formik.handleChange} defaultChecked={formik.values.jobtype}/>
<Form.Check name="jobType" label="Temporary" value="Temporary" id={`inline-checkbox-4`} onChange={formik.handleChange} defaultChecked={formik.values.jobtype}/>

I figured there must be a more efficient or DRYer way to write this code, so I approached it by iterating through the proposed values and mapping out the elements. This is a very similar approach to displaying employees or jobs without repeating code. Except this required I define the different values as a constant at the top of the component.

const jobtypes = [
  "Full Time",
  "Part Time",
  "Contract",
  "Temporary"
    ]

Honestly, it didn’t minimize my code but it looked slightly neater. The most important aspect of writing code this way was allowing me to select checkboxes that matched a job’s values. defaultChecked expects a boolean value to define its checked status, therefore if the values includes the value of the checkbox, it will return true.

{jobtypes.map(job => 
  <Form.Check name="jobType" label={job} value={job} id={job} onChange={formik.handleChange} defaultChecked={formik.values.jobtype.includes(job)}/>
                )}

As always, it took some time perusing on the internet for a solution, but most importantly it was my persistence and attempting to think outside the box to solve it. Now I will be able to apply the same concepts to other edit forms for this project and future projects to come. The key to learning and growing as a developer is to keep an open-mind when developing a web page and to keep plugging away until you have that eureka moment. They can happen daily if you stick with it.

Modaling Forms: Modals and Formik

indiejesus2 — Wed, 29 Sep 2021 02:52:33 +0000

I’ve still been working hard on building the website for my client, including adding some design and structure to the interface with React-Bootstrap. I ventured into uncharted territory when I began using Modals for my forms and stumbled upon Formik, a React component that helps minimize the amount of work needed to construct forms. Continuing the theme from the past couple weeks, I thought I’d share some of the techniques I learned while working with these formats.

Since I was first commissioned to develop the website, I’ve been thinking of different ideas I could apply to the interface, including having the login/signup window be a popup. I had encountered this interactive element many times in the past, and I always found it modern and stylistic. Until last week, I was completely unaware that this was referred to as a Modal element, (learned it from an assessment of all places.)

Now that I knew what the element was named, I quickly remembered seeing it on the list of components available through React-Bootstrap, the React version of the popular design framework. Honestly, I haven’t had too much experience with other design frameworks like SASS but I found Bootstrap to be fairly simple to implement and easily reconfigures the user interface to look more professional.

I thought the form for my multi-page questionnaire would be perfect chance to use the Modal element. To start, I created a main page that would house my basic functions (onChange, onSubmit) along with my state, including keeping track of what page of the questionnaire the user was on. Then I included the different components that would render depending on the progress in the questionnaire, Basic, Desired Schedule and Skills entry, along with the necessary props.

 <Form onSubmit={handleSubmit}>
                <Basic
                    currentStep={state.currentStep}
                    handleChange={handleChange}
                    show={state.show}
                    fname={state.fname}
                    lname={state.lname}
                    city={state.city}
                    state={state.state}
                    handleClick={handleClick}
                    />
                <Desired
                    currentStep={state.currentStep}
                    handleChange={handleChange}             
                    show={state.show}
                    jobType={state.jobType}
                    schedule={state.schedule}
                    handleClick={handleClick}
                    />
                <Skills
                    currentStep={state.currentStep}
                    handleChange={handleChange}
                    show={state.show}
                    skills={state.skills}
                    handleClick={handleClick}
                    handleSkills={handleSkills}
                    handleSubmit={formik.handleSubmit}
                    />
            </Form>

Inside of each individual component was React.Fragment to define that it part of a larger component, and the Modal element that includes a Header, Body, and Footer. The Modal element also comes along with some default features including show (default value is true which is necessary to show the element), animation to give it a little flare when it pops up and backdrop to fade out the page behind the Modal. Inside the Modal.Body included the form, also using the Form element supplied by React-Bootstrap.

    if(props.currentStep !== 1) {
        return null
    }

    return(
        <React.Fragment>
        <Modal show animation backdrop>

        <Modal.Header>
            <Modal.Title><img src="/images/blucollar_icon.png" alt="Collar" /></Modal.Title>
        </Modal.Header>
            <Modal.Body>

            <Form.Label htmlFor="first name">First Name: </Form.Label>
            <Form.Control type="text" name="fname" onChange={props.handleChange} />
            <Form.Label htmlFor="last name">Last Name: </Form.Label>
            <Form.Control type="text" name="lname" onChange={props.handleChange} />
            <Form.Label htmlFor="city">City: </Form.Label>
            <Form.Control type="text" name="city" onChange={props.handleChange} />
            <Form.Label htmlFor="state">State: </Form.Label>
            <Form.Control type="text" name="state" onChange={props.handleChange} />
            <Form.Label htmlFor="zipcode">Zipcode: </Form.Label>
            <Form.Control type="text" name="zipcode" onChange={props.handleChange} />
            <Form.Check type="checkbox" name="license" label="Driver's License" onChange={props.handleChange} />
            </Modal.Body>
            <Modal.Footer>
                <Button variant="primary" name="next" onClick={props.handleClick}>
                    Next
                </Button>
            </Modal.Footer>
        </Modal>
        </React.Fragment>
    )

While researching using different input types with Form on React-Bootstrap, the documentation included a recommendation to use Formik to, again, help lessen the amount of code or redundancy when building forms. Needing to use anything that will help me construct the website faster and smoother, I decided this was a perfect opportunity to learn and utilize the React supplement.

The most appealing aspect about working with Formik is it is preset with most methods needed to handle updating state and handling fetch requests with said state. Every form I’ve written has included a handleChange and handleSubmit methods, mostly the same functions written over and over again. With Formik, I only have to define what happens when the submit button is clicked and the rest is handled with the included Formik methods that are easily passed as props to the various questionnaire components. This helps clear up a lot of space and will help shorten the time needed to build out forms.

 <Form onSubmit={formik.handleSubmit}>
                <Basic
                    currentStep={state.currentStep}
                    handleChange={formik.handleChange}
                    show={state.show}
                    fname={formik.initialValues.fname}
                    lname={formik.initialValues.lname}
                    city={formik.initialValues.city}
                    state={formik.initialValues.state}
                    education={formik.initialValues.education}
                    handleClick={handleClick}
                    />
                <Desired
                    currentStep={state.currentStep}
                    handleChange={formik.handleChange}

                    show={state.show}
                    jobType={formik.initialValues.jobType}
                    schedule={formik.initialValues.schedule}
                    minpay={formik.initialValues.minpay}
                    maxpay={formik.initialValues.maxpay}
                    handleClick={handleClick}
                    />
                <Skills
                    currentStep={state.currentStep}
                    handleChange={formik.handleChange}
                    show={state.show}
                    skills={formik.initialValues.skills}
                    certificates={formik.certificates}
                    handleClick={handleClick}
                    handleSkills={handleSkills}
                    handleSubmit={formik.handleSubmit}
                    />
            </Form>

After I completed my seamless and slick questionnaire, I updated my signin and signup methods with Modal and Formik to update the interface with style. The website is slowly coming along and I’m happy with the progress I’ve made so far. I’m even more excited for the potential to learn other supplements and tricks when building a website. Until next time!

Life in the Fast-Json Lane: Working with JSON:API Serializer

indiejesus2 — Wed, 22 Sep 2021 02:54:08 +0000

Last week, I covered tricks and tips with handling forms and updating state, as well as sending the data through fetch requests to the backend. Since then, I have been working endlessly on fetching data from the backend, which included building relationships between my various models and sending the data through a Json Serializer made by Netflix, Fast_JSONAPI Serializer (now just JSONAPI Serializer). I learned some new things while working with the serializer and felt I could impart my wisdom this week.

My application’s database is made up of multiple tables/models that are all connected through belongs_to and has_many relationships. Employees have profiles and previous work experience, and employers have job postings, which are all connected through their job applications. On previous projects, I would make too many fetch requests to acquire necessary data, for example one request for an employer and another for associated applicants. I was slowly realizing that if an employer had a lot of job postings or applicants, the data might take a long time to load.

I had some experience building serializers in the past, which helped define the data in a readable json format. This included iterating through associated data in an attempt to minimize fetch requests. The reducer would receive the results and I would iterate through the nested data to correctly update the state.

class RecordSerializer
    include FastJsonapi::ObjectSerializer
    attributes :id, :date, :daily_allowance, :daily_total, :user_id
    has_many :days
    attribute :days do |record|
        days = Day.where(record_id: record.id)
        recs = {}
        days.each do |day|
            recs[:id] = day.id
            recs[:item_name] = day.item_name
            recs[:item_calories] = day.item_calories
        end
    end
end

It worked fine in the past, but I knew there had to be a more efficient way to deliver the data without it being so nested in the results. Upon reading the instructions for JSONAPI, I found that it wasn’t necessary to define an iterator. By setting up a serializer similar to a model with belongs_to and has_many attributes, I could simply include the profiles and work history when an employee is initially fetched.

class EmployeeSerializer
    include JSONAPI::ObjectSerializer
    attributes :id, :email, :name
    has_one :profile
    has_many :work_histories, through: :profile
    has_many :applicants
    has_many :jobs, through: :applicants
end

render json: EmployeeSerializer.new(@employees, include: [:profile, :work_histories])

Things started to become a little bit clearer, until I started attempting to pull large sets of data that were connected to jobs. When an Employer signs in, I envisioned jobs data associated with the employer would be delivered as well. Then I expanded to include potential candidates (connected through applicants join-table) which also included the profile information and previous work experience. My reducer was becoming larger and filled with too much code, and I could visually see the long logs to fetch the jobs.

I went back to the read me portion of JSONAPI and learned that there was an alternate way to deliver associated records.

class JobSerializer
    include JSONAPI::ObjectSerializer
    belongs_to :employer
    has_many :applicants
    has_many :employees, through: :applicants
    has_many :profiles, through: :employees
    attributes :id, :employer_id, :status, :title, :city, :state, :jobtype, :schedule,
    :skills, :certificates, :description, :employees, :profiles
end

Since both employees and their profiles are already related to jobs, they can be inserted as attributes for JobSerializer. This will deliver all associated employee information already defined in the EmployeeSerializer, along with profiles defined in the ProfileSerializer. With a single fetch request, I have all the necessary data to display an employer’s jobs postings and potential candidates information, rather than fetching employees later on. Originally, I was defining the parameter through object_method_name, but I realized (stumbled upon) that it was only necessary if I wanted to assign the parameter a name different from its given name.

I might have spent a little too much time refactoring my code instead of building on features for my application, but my code is much cleaner and works very well to boot. The real test will be when I have copious amounts of records in my database and how long it takes to load it all on this single fetch request. I’m also attempting to learn how to define related links in the Serializer that JSONAPI says would be helpful in gathering data in later requests. I will attempt it and see how well it turns out. Until next time!

Formally Invited: Forms in React/Ruby

indiejesus2 — Wed, 15 Sep 2021 03:27:26 +0000

I’ve been working long and hard on my project this week, which has involved mostly building various forms along with my database. Every website has one form or another, and I’ve built plenty in past projects, but never with this much wealth of information. So this week I thought I’d cover what I’ve learned about forms and maybe some tricks I picked up along the way.

Most of the forms I’ve built in the past were made of generic text inputs and text areas, maybe a select input, but nothing too complicated. The main purpose of my application is to match potential candidates with employers based on profiles and the job listing. That meant a lot of information would be given to make stronger matches, which also meant a lot of useState variables would have to be defined, and I was afraid my handleChange function would grow too large. Luckily I was smart enough to research a faster method that matches the name of the input with the state variable and updates with the value. Of course it’s important to assign inputs the same name as it is represented in your state.

    const [state, setState] = useState({
        fname: props.profile.fname,
        lname: props.profile.lname,
        city: props.profile.city
    })

    const handleChange = (event) => {
        const {name, value}  = event.target
        setState( prevState => ({
            ...prevState,
            [name] : value
        }))
    }

Most employee profiles I’ve seen include the type of shifts employees are willing to work like weekdays or weekends, or they are seeking a full-time or part-time position. I imagined that there would be some employees that had open availability, or at least would want to select more than one option. The question then became how to handle a post request with a parameter with multiple values as well as updating state when a checkbox is both selected and deselected.

My form included four checkboxes to select for the type of position the employee was seeking, with the ability to select more than one checkbox. If a checkbox is selected, the value of the checkbox is inserted into an array, but not through any simple .push() function. Instead it must be handled by spreading the array being stored in state. When a checkbox is deselected, the index of the value must be found to then be spliced from the array, which will then be used to update the state.

    const handleJob = (e) => {
        if (e.target.checked === true) {
            setState( prevState => ({
                ...prevState,
                [e.target.name]: [...state[e.target.name], e.target.value]
            }))
        } else {
            let group = state[e.target.name]
            let deleted = group.findIndex(job => Object.keys(job)[0] == e.target.id)
            group.splice(deleted, 1)
            setState( prevState => ({
                ...prevState,
                [e.target.name]: group
            }))
        }
    }

If you notice, I also used the trick from above to help handle multiple sections of checkboxes, as opposed to defining a handleChange function for both. Not gonna lie, I was quite pleased with myself to figure that one out on my own.

Now to back up a little bit, I chose to build my database using Postgresql as I had to frequently convert my database from the Ruby default SQLite3 so I thought I’d save myself the trouble. One of the advantages of using Postgresql is that I can designate columns as an array, which I felt would be suitable to store multiple points of information in a single column. The setup is simple as well.

      t.text :jobType, array: true, default: []
      t.text :schedule, array: true, default: []

What wasn’t so simple was permitting the params to update the arrays in the database, at least because it is set up differently from the singular params usually given. Instead of params.require(:profile).permit(:name, :schedule) the params must be told to expect an array to be passed along by simply defining it as params.require(:profile).permit(:name, {schedule: []}). The trickier part comes if you’re trying to pass nested arrays, as then you have to define the keys the controller to expect, such as params.require(:profile).permit(:name, {schedule: => :hours, :weeks}) but I was having issues with this as the parameters were being saved in the database as a distorted string that included the key and the value. Luckily I did away with nested arrays, but I’m sure they’ll come to haunt my dreams eventually.

While these were nice tricks and tips to pick up when working with forms, I still have a lot to learn and figure out. I am currently working on using nested attributes or nested forms, if that is doable in a React frontend. Based on how far I’ve gotten, I’m not sure there is a clean solution but I will keep trying until all else fails, as my params will just not permit the nested attributes. Hopefully I’ll have a working solution next week that I can try to explain. Until next time!

Ruby/React Project: All in One Place

indiejesus2 — Wed, 08 Sep 2021 03:48:03 +0000

I’m beginning a new project this week that has the potential to be a profitable product (no pressure at all). I’ve built and worked on plenty of projects for the past two years, but this will be the first for a client and that could be potentially marketed if all goes well. It’s all very exciting and scary at the same time.

One of my first decisions as lead developer was how to set-up the project, wondering if a Ruby on Rails backend and a React-Redux frontend would be viable for this website. After learning that plenty of major websites and applications were built with the same stack, I felt more confident moving forward with my skills.

Still, I wanted to explore the best techniques for planning and beginning the project, including reading some tutorials. This particular walkthrough had enlightened me to a few things that seemed very helpful for my website, including a React gem built specifically to work alongside Ruby on Rails. I was caught off guard considering I’ve worked exclusively with these coding languages and had no idea that the gem existed. It was also incredibly easy to set up as well.

rails new rails-react-project -d=postgresql --webpack=react

What I also discovered was it was possible to build a React frontend through Ruby as well. I built an application exclusively with RoR but primarily with vanillaJS and erb files. My previous projects had separated the frontend directory from the backend, which meant two different hosts had to be launched to preview my project. Plus every time I went to deploy my project on Heroku, I had to create separate Github repositories, which frankly became frustrating.

I was happy to make this discovery, as the amount of files to work with had shrunk by almost half and I was only required to initialize one server on Ruby rather than two separate. There were some minor changes needed to configure this set-up and allow React components to yield in Ruby compatible files. First, there is a file located under views/layouts directory labeled application.html.erb that already has some generated code in it. These two lines need to be added in the header section.

   <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <%= javascript_pack_tag 'Index' %>

As you may have noticed before, the second line of the code inserted into the application references this index file. It is also necessary to specify the root page in routes to register where React components should be rendered. Based on the advice of the tutorial, I generated a homepage controller to act as the root for the project, which manifested a homepage directory in views along with a basic erb file. I cleared out the contents of the file, making it a blank file, and renamed it index.html.erb. Finally, I specified this as the root landing page in the routes file.

Rails.application.routes.draw do
    root ‘homepage#index’
end

After setting this up, I was a little hesitant to continue on this path as I was out of my comfort zone. Eventually I realized that I could still include multiple directories including containers, actions and reducers. I will still be taking an alternate approach as I will attempt to use Redux and associated packages while working in Ruby, and so far it is working fine. We’ll see what trouble I run into next week. In the meantime, cross your fingers and say a prayer for me!

Technically a Software Developer - Part 2

indiejesus2 — Wed, 01 Sep 2021 03:00:59 +0000

I’m on vacation this week in the beautiful Finger Lakes in New York (walked Watkins Glen today!) so I’ve been taking a small break from building and deploying websites. I’m starting a big project next week so the break won’t last long. In the meantime, I’ve been practicing algorithms at Codility in preparation of a technical assessment. It’s with the same company I interviewed with in the past, which made me realize I never finished discussing one of the problems from a couple months ago. I eventually came up with a simple solution, let me

Just a little refresher, the problem consisted of finding the least amount of steps it would take to a given parameter, N, starting from one by either doubling the number or adding one to it. The sample test case gave the parameter of 18, which should result in 6 steps.

[1] - 1
[2] - 2
[3] - 4
[4] - 8
[5] - 9
[6] - 18

Originally, I approached the problem as it was necessary to begin with 1 and work our way up to N, adding it to a hash. Basically I would double the number unless it was greater than N, then go back a step and add 1, looping this process until it equaled N, and finally returning the length of the hash

function Solution(n) {
    let ladder = {}
    ladder[0] = 1
    let x = 1
    while(!Object.values(ladder).includes(n)) {
        if (ladder[x-1]*2 > n) {
            ladder[x-1] = ladder[x-2] + 1
            ladder[x] = ladder[x-1]*2
        } else {
            ladder[x] = ladder[x-1]*2
        }
        x++
    }
    return Object.keys(ladder).length
}

The biggest issue with this solution was it would exceed the time limit when dealing with different edge cases including the maximum number N could be. Having to repeatedly reverse the accumulator was definitely not optimal, which was accomplished with too many if statements. What I’ve eventually learned is that using conditional statements increases time as well, so regardless if the solution produces the correct result, it would still fail the complexity part.

After banging my head against my desk for a while and scribbling on some scrap paper, I eventually had a eureka moment. The biggest realization, it was unnecessary to begin with 1 and slowly work our way up to N. Why not begin with N and work our way down to 1? This change in perspective also made me realize that I could also reverse my solution. Instead of doubling my accumulator, I could divide N if it was divisible by 2, or subtract 1 if not. Also, it was completely unnecessary to store the sequence in a hash just to return the length of the hash, as I only needed to keep a counter going after each step was made.

function Solution(n) {
    let x = 1
    while(n>1) {
        if (n%2===0) {
            n%2
        } else {
            n-=
        }
        x++
    }
    return x
}

As you could see, this cut my solution by more than half, and would reduce the space and time needed for large parameters. All in all it wasn't a very hard problem, especially evident with this solution. I've used this problem as a major learning moment, to look at things from a different perspective, to step back and approach the problem from a different angle.

While I continue to practice for future assessments, my favorite part is trying to make the solutions even smaller. Ternary operator has become my go to conditional statement. Finally, my final solution.

function Solution(n) {
    let x = 1
    while(n>1) {
        n = (n%2===0) ? n%2 : n-1
        x++
    }
    return x
}

Deploying Rails/React to Heroku: Minor Things with Major Implications

indiejesus2 — Wed, 25 Aug 2021 03:16:43 +0000

The date has finally arrived, the deadline to submit my solo project for assessment by Chingu to determine whether I deserve to be in the Full Stack Development tier. To be honest, I was getting scared that I wouldn’t be able to complete it in time as I was having difficulty deploying both my back-end and front-end to Heroku. I’ve managed to launch two applications on the platform so I thought it would be easy to do it again, but instead I realized I had a lot more to learn about deploying.

The first task was deploying my back-end, which went a lot smoother than my last attempt as I detailed in this blog post. I did have to update Ruby again, but the Heroku build was successful and it went live after two attempts. Except after testing some fetch requests from my front-end, some problems began to arise, mainly with authenticating users. After many attempts at fixing the problem, I realized the JWT tokens were not set up properly and not matching with Cookies being sent over by the browser.

Originally, I had set the token to a variable stored in a dot-env file as I had seen performed by another developer in their blog post about setting up JWT tokens. While this solution worked in my local environment, it wasn’t the correct technique for an external host. As detailed in this blog post, the JWT should be set as Rails.application.credentials.jwt_key which can then be set privately through the terminal by executing EDITOR=”code --wait” rails credentials:edit. This will open a credentials file that is not accessible by the directory, and where the JWT key should be stored for safekeeping. A truly awesome feature that makes complete sense when done properly, and of course fixes everything.

After my back-end was working properly with my front-end hosted in a local environment, it was time to tackle deploying said front-end to Heroku, and my first few attempts were coming up empty. It would barely build itself and the errors I received didn’t seem very common to other developers on StackOverflow or elsewhere. It wasn’t until I began carefully reading about my chosen buildpack, Create-React-App-Buildpack by mars that I realized my stupid mistake.

I had used this buildpack before to launch my front-end for my personal portfolio website, of course I had chosen it for it’s proven track record. Except, as detailed in the purpose section at the top of the ReadMe file, the buildpack was not designed for a React application “with a server-side backend (RUBY!)” This is why it is very important that to read the instructions before trying to force an application to perform an action it is incapable of performing.

Again, another simple fix finally allowed my front-end to be built and deployed on Heroku, just by including the Node.js buildpack on Heroku. :-) But again, the website was still not working properly, as I realized the procfile needed to be updated as well to boot the application upon launch. Simple enough, it was the same command to start the application locally, web: npm start. As I read, web is very important to basically signal that the application is being launched on an external website or browser.

This however wasn’t the only problem with my website, it was also timing out before it could launch. I narrowed it down to my application not setting up a port for the website as is usually performed in Node.js server. Frankly, it seemed like too much work to define it in my index file, especially considering it was never taught in any previous lessons at Flatiron.

I also knew it had to do with my package.json file where the start commands were defined. I eventually had a eureka moment when I defined the localhost address in my scripts to originally coordinate with my back-end. Because the default host is the same for both my front-end and back-end when working in a local environment, it was necessary to set it for them to work properly. But this was also causing my website to crash.

Finally, my website was displaying properly and I could login and make new records, with plenty of hours to spare. There was some minor tweaking and errors to be fixed, but eventually it was good enough to be submitted for assessment by Chingu. I still need to make some improvements to it, including finding a cookie image to display in my calendar, but I was proud to get it launched and confident I could do it again. Even after tearing my hair out and losing some sleep over it, I learned a lot and can’t wait to do it all over again.

A Token of Persistence: JWT Tokens and Redux Persist

indiejesus2 — Wed, 18 Aug 2021 02:41:59 +0000

A couple weeks ago, I implemented a log-in feature on my counting calories application, Counting Cookies. It was a really simplified method but it was necessary to give users private access to their records. What I was really seeking to do was persist my state in order to allow other features to work properly such as updating profile information or a single component for my daily records form.

There seems to be more than a few ways to accomplish this, all with their own strengths and drawbacks. Originally I chose a path I was most familiar with and which I described before, assigning the user’s id to session, which eventually seemed a little too simple and not compatible with keeping a user logged in. I saw a decent amount of developers choose to use tokens, but that are stored in localStorage or sessionStorage, a method that works but can be a security risk.

I chose to use JWT or JSON web tokens that are issued when a user logs in and then stored in cookies. The set-up wasn’t terribly hard, just a few updates to the backend including authenticating the token and checking if there is a current user based on the token. I also added some additional routes for logging in, logging out, and checking for a current user, to help persist state between components.

A token is considered a credential, which must be sent along when making a fetch request to the backend. Sending the credential worked out fine, but if the configuration isn’t set up correctly CORS will throw a hissy fit and prevent the application from working. CORS was originally set up to handle any requests no matter the route by using a * or a wildcard. This is not allowed when sending highly private credentials between the front and backend, so a specific address must be set, essentially giving permission to that particular website to access the data.

Make sure the host location is correct or else you’ll waste hours searching online for a solution for a problem that doesn’t exist. In my case, I was setting my origin to my backend web address rather than the frontend where the request is originally being made. But the errors CORS give you will not give you that hint, instead you will see errors like “Access-Control-Allow-Origin missing“ and other problems with the pre-flight response. I learned about them, but not necessary to this particular problem.

Once I correctly set the origin, the credentials were being sent back and forth, but refreshing my page would still reroute to the root page which is my login page. I had to take advantage of the new current_user validation that I had set up in my application controller in my backend. I created an action, also called current_user, that will fire when the initial component is first mounted, sending a fetch request to check if the user is indeed logged_in?

   def jwt_key
       ENV['SESSION_SECRET']
   end

   def issue_token(user)
       JWT.encode({user_id: user.id}, jwt_key, 'HS256')
   end
   def decoded_token
       begin
         JWT.decode(token, jwt_key, true, { :algorithm => 'HS256' })
       rescue JWT::DecodeError
         [{error: "Invalid Token"}]
       end
   end
    def authorized
       render json: { message: 'Please log in' }, status: :unauthorized unless logged_in?
   end

   def token
       request.headers['Authorization']
   end
    def user_id
       decoded_token.first['user_id']
   end
    def current_user
       @user ||= User.find_by(id: user_id)
   end
    def logged_in?
       !!current_user
   end

Now when I refreshed the page or tried a broken link, it would redirect to the users homepage since they were technically still signed in. That was great, until I realized my signout action wasn’t working. It’s pretty clear how to initialize a token for a user, but the drawback is the token would remain until it expired in the backend. So trying to make a fetch request to destroy the current_user was coming up fruitless, it seemed the best solution was to remove the token from the Cookies in the frontend, no fetching required.

        case 'LOGOUT_USER':
            // localStorage.clear();
            Cookies.remove('eduResourceSession')
            storage.removeItem('persist:key')
            return {user: [],
                loggedIn: false,
                token: ""
            }

Finally, I was able to log-out of my application without it redirecting to the user’s homepage, but the state wasn’t persisting on other pages. When I clicked the link for a user’s homepage, the address bar would briefly show the correct link before redirecting itself to the root page. I needed something to persist the state as it was disappearing when a separate page was called.

Wouldn’t you know it, a kind-hearted person made a package for Redux for just that purpose, Redux-Persist. It meant I had to configure a store that would be passed to the index page when initializing the provider when originally rendered.

import {createStore, applyMiddleware} from 'redux'
import { persistReducer, persistStore } from 'redux-persist'
import storage from 'redux-persist/lib/storage'
import thunkMiddleware from 'redux-thunk';
import usersReducer from './reducers/usersReducer'
import recordsReducer from './reducers/recordsReducer'
import loginReducer from './reducers/loginReducer'
import { combineReducers } from 'redux';

const rootReducer = combineReducers({
    usersReducer,
    recordsReducer,
    loginReducer
    //sessionReducer
  });

  const persistenceConfigs = {
    key: "loggedIn",
    storage
  }

  const persistedReducer = persistReducer(persistenceConfigs, rootReducer)
  const store = createStore(persistedReducer, applyMiddleware(thunkMiddleware));
  const persistor = persistStore(store)
  export { persistor, store }

It worked a little too well for my needs because now I wasn’t able to logout again, before I could try my profile link. I fixed that by adding the signoutUser action as a click function to the link. Next I tackled the profile page, by moving it higher in the Switch statement, which finally got it to start working properly.

At last, my project felt like an actual functional website that people can use. Now I can focus more on the cosmetic look and deploying it to Heroku so it can be reviewed by Chingu before our project starts. I’m sure I’ll tell you all about it next week. Stay tuned!

Nested Arrays and Objects

indiejesus2 — Wed, 11 Aug 2021 02:54:46 +0000

The job search continues and I was lucky enough to participate in two technical assessments. One of the assessments included parsing through some given data and converting it into an object. Within this data were three arrays, families, parents and children, that had to be converted into objects well. The last part of the function is the categories must be grouped by a given entry, such as id or name.

The first task was to take the given data and create a new Object from it to manipulate and configure the values. The data was already an object so it seemed pretty simple at first. It wasn’t until I started testing my solution that I began to notice that if you create a copy of the data and alter, this will also alter the original object. Obviously this wasn’t feasible for my solution when trying multiple test-cases.

At first, I thought using Object.assign(data) would render a brand new object that wouldn’t change the original object given. But because this was a deeply nested object, the assign function wouldn’t be strong enough to handle the conversion. Eventually I found a suggestion on StackOverflow that would be able to copy over the data into a separate Object, JSON.parse(JSON.stringify(data)).

Next, I had to navigate through the nested arrays and reformat each into a nested Object with a key defined by the name or id. The easiest solution seemed to take the array and iterate through each, then defining the necessary key-value pair.

families.forEach(function(family) {
    Brand.families[family.id] = family
}

For this example, the newly created Object would look like Brand: { Families: “F1” {id: “F1”, name: “Bundys”} }. Again, the function requires the identifying key to group each family by. To handle this static parameter, the array would be parsed through for the particular identifier by placing it square brackets as the key is being assigned.

The last part was considering any possible edge cases that could render the solution useless. My first thought was if the desired identifier wasn’t found in the data or in a particular array. An Object with a key of “undefined” would certainly not look good. Therefore I created a function that would take in an object and create a variable of the Object’s keys.

Originally, I tried to iterate through the array of keys with forEach but the loop would continue even after the condition was met. Of course, the purpose of the function is right in the name, no matter if the condition was true or not. Like always, if forEach doesn’t work, I revert back to a simple for...let loop to iterate through the array. If the identifier isn’t found amongst the keys, then the function would return an id number in its place, depending on the place of the object given.

function identity(obj, search, place) {
 let etc = Object.keys(obj)
 for (let i = 0; i<etc.length;i++) {
   if (etc[i] == search) {
     return obj[search]
   } else {
     continue
   }
 }
 return `0${place+1}`
}

I’m still unsure if creating a new Object with an empty hash was the most efficient way to convert the nested arrays into nested Objects. I attempted to define the key-value pairs with the Object that was copied over from the data, but it would combine the existing arrays with the newly formatted Object data.

Besides that, I was almost proud of my submission. It seemed clean and readable, and I thought my added function to check for the identifier was helpful. Hopefully I hear back soon and move onto the interview where I can really shine. Wish me luck!

Days of the Week - React-Day-Picker Part 2

indiejesus2 — Wed, 04 Aug 2021 03:03:57 +0000

Last week, I began making improvements to my Counting Cookies application including adding an interactive calendar made by Day React Picker. This is all in anticipation of deploying the project for consideration by Chingu. I was able to incorporate the calendar and display current records by highlighting the days.

As I left off from last time, I had some ideas on other features I wanted to add along with the calendar. Users would be able to click a date on the calendar and it would be displayed in the record input form. I was also hoping users would be able to click a date with an existing record and the record card would display on top.

This took some experimenting as I originally tried defining a handleClick function that would render the record but that became a dead end. As I am prone to try multiple options, I also tried having a Link component that was similar to the list of links I had originally written but had the same results. In the end, I had to customize the calendar that would display a link to each individual record. This involved creating a separate Calendar component to avoid having extraneous code that primarily involves code from clogging the DailyRecords component.

This wasn’t my fondest solution simply because it made some of my previous work pretty obsolete, but I was excited by the idea of cookies filling up a calendar. While I mirrored the example given by the developer of Day Picker, I had to make some adjustments to handle my records. It followed a similar concept to the SelectedDays option for Day Picker, as the records would be mapped over and any record’s date that matched the date being rendered would be displayed as a link. Now a user can easily view a daily record by clicking on the cookie of a desired date. Plus, the correct dates are being selected on the calendar rather than being a day early with the default selected days option.

<div style={cellStyle}>
                <div style={dateStyle}>{date[8] + date[9]}</div>
                {this.props.records.map(function(record) {
                    if (record.date == date) {
                        return (
                        <div style={birthdayStyle}>
                            <Link to={`/users/${record.user_id}/records/${record.id}`}>Cookie</Link>
                        </div>
                        )
                    }
                })}
            </div>

There are still cosmetic issues that I’d like to address including the daily record form and the card. The biggest task I’d like to conquer is using session storage to persist the users login status as refreshing the page or clicking to a link to add a new record is redirecting to the root page, or login. I’ve written in the past about developing a login feature as my original project didn’t have the capabilities, and while I completed the basic functionality, I obviously have more to add so a user can have a viable experience with Counting Cookies.

Counting Days on React-Day-Picker

indiejesus2 — Wed, 28 Jul 2021 03:17:45 +0000

After deploying my portfolio last week, I started exploring how I could expand it along with increasing my network. I’ve always been interested in participating in a hackathon but been unable to find the right time. Like any person, I googled for software development tips and found a couple suggestions including Chingu, a platform that forms teams to work on a collaborative project to build “technical and soft skills required in a professional software job.” My application was accepted, which I’m sure isn’t very hard to do, and started the process of preparing for the August 30th start date.

Part of the process is having an application to showcase to determine what tier I would be categorized under. While I do have my Sinatra application deployed on Heroku, I felt it wasn’t a good representation of my coding abilities. With some time before the due date, I decided I should upload my calorie counting React application, Counting Cookies. Before I could deploy it, I wanted to give it a serious facelift along with some new features including an interactive calendar.

At first, I was feeling overly ambitious and thought I could build my own calendar. After reviewing some examples online, I quickly realized it would take a lot of time and work considering the differing days in a month and adding basic functionality. Instead I found a React component, React Day Picker, that could be easily inserted into my application.

npm install react-day-picker

import DayPicker from ‘react-day-picker’
import  ‘react-day-picker/lib/style.css’

The first thing I wanted my calendar to be able to handle is highlighting days that have records on file. DayPicker included a feature that could easily perform this action by toggling the display of each date saved in the database so far, the issue was iterating over the multiple days. DayPicker only needed a date to render the highlight on the calendar, and originally I attempted to parse through the props I had already set up in the page to create an array of dates.

Based on the examples provided with the application, I thought I would be able to use an array as the parameter but that prevented the calendar from displaying at all. I also tried creating a new array of the dates that converted them to numbers as I believed that was the necessary format to be used to instantiate a new Date. I eventually realized this was creating more code than was necessary and finally decided to add mapStateToProps to the component that included the array of dates. Then the props would be mapped over again as each date would be used as a parameter when instantiating a date on the DayPicker. I experimented on this for a while before searching for a solution on StackOverflow that was luckily answered by the creator of DayPicker.

<DayPicker class="calendar" selectedDays={this.props.vinyl.map(date => new Date(date))} />

Once Jenny Craig’s records (my demo user) began appearing on the calendar, I moved onto the next task I wanted the calendar to be able to handle. When a date was selected on the calendar, I wanted the date to be then set as the value in the form. The function onDayClick was already developed, all that was needed was to define a function that could perform my desired action.

Of course, easier said than done as passing that information between two different components could be difficult if not taking the proper steps. I originally thought I would be able to set the value by using query selectors and simply changing the value. Upon some research I realized that because my form constructor has set up the values in state, and the state can only be changed from a different component by passing props. I finally settled on adding “date” to state in my recordsReducer as well as adding a new action called SELECT_DATE that simply inserts the date.

export const selectDate = (date) => {
    return { type: 'SELECT_DATE', payload: date}
}

While the state was being updated, the form input still remained the same. I then attempted to use componentDidUpdate that would setState after the state should have been updated to the clicked date. Warning, this will cause the application to stop working as React is preventing an endless loop from going off as setState would be constantly called. I needed to check the current state, this.props.date against the previous props, and only if they were different would the state be updated.

componentDidUpdate = (prevProps) => {
    if (prevProps.date != this.props.date) {
        this.setState({
            date: this.props.date
        )}
    }
}

Along with some styling changes, the addition of the calendar makes my application look a little more professional, but there is still a long way to go. Currently, next to the calendar is a list of links to each record to display a card detailing the items consumed that day. I would also like this same functionality to occur when the highlighted date on the calendar is clicked. I’ve tried a couple techniques but they haven’t been successful, so I’m hoping my next idea has better luck. After some more alterations, I will hopefully adapt React-Day-Clicker to application successfully.

Launching Rails/React App to Heroku: Part 2

indiejesus2 — Wed, 21 Jul 2021 01:56:34 +0000

When we last left off, I had finally deployed the backend of my portfolio and was working on getting the frontend to launch as well. At the time, I thought Heroku was having trouble finding the root index page, at least that’s what I was assuming because I was receiving a 404 error that simply said ‘nginx’.

After examining the logs provided by Heroku, I noticed that it was running into an error before it initialized the nginx server to begin. It was not finding the build in the default location. At first I had no idea what it meant, and the log was directing me to the Create-React-App buildpack section on customizing the JS_RUNTIME_TARGET_BUNDLE which made me think I had to set up environmental bundles.

What I eventually realized was the default target location was a build folder that contained the static directory with the necessary js files. It couldn’t be found because it was being ignored in my .gitignore file. Even though this was a default option, I commented it out of the ignore file as a last ditch effort to get my website to launch.

When the background color changed from white to forest green, and my name was proudly displayed on top of the page, it felt like I hit a homerun. My portfolio website had finally been accepted and launched on the world wide web. I can breathe a sigh of relief knowing that it wouldn’t take more than 50 deployments to get it working.

Unfortunately, my hairy face wasn’t anywhere to be found on the welcome page, just my alternate text taking up the space instead. When I clicked over to my resume page, the skills icons were missing as well. I spent some time formatting them correctly, I couldn’t settle without them. However, the images on my projects page were all accounted for so some of the images were working properly

My first instinct was that the images weren’t being correctly referenced in the resume component, which in the end turned out to be the case. The image source was directed out of its directory to the root directory where the images were being stored in a public folder. Compared to the images rendered in the projects page, the only difference was the source directly referenced to the images folder rather than being directed to the root.

Because I decided to render my projects by fetching the data from my backend, the image source couldn't be referenced from its root directory since the images didn’t exist there. The same concept had to be applied to all image sources as the browser was incorrectly being redirected to an address that didn’t exist.

After that was fixed, along with making sure the root address was redirected to the welcome page, I pushed the updates to Github and expected to see it working on my website. Except nothing changed, so I naturally doubted my code was working properly. Upon further inspection with the browser tools, I noticed the image sources weren’t changing with the updates. It seemed I needed to run the build command npm run build each time to update the static files. Doesn’t seem like the best solution, but everything was running as it should so I was happy.

It feels great to have my own personal website online for everybody to see. It's not the best looking portfolio, but it's better than nothing and I'm looking forward to giving it some facelifts. You're more than welcome to check it out! Daniel Ste. Marie