#100DaysOfCode: Days 1-7

November 8, 2018 •8 min read

I have been focused on learning React the past couple of months, taking a Udemy React course to learn the concepts and start writing code. Now that I have finished the course, I am committing to 100 Days of Code to get practice in React and build my React portfolio.

Commitment

I will code in ReactJS and related tech (NodeJS, SCSS, etc) for at least an hour every day for the next 100 days.

Start Date: November 2, 2018

100 Days Of Code - Log

Day 1: November 2, Friday

Today's Progress: I set up the git repository and boilerplate code for my React project, ChaiCMS. I upgraded the packages in package.json that were outdated from the Udemy React course. This caused issues with webpack that I went through and fixed.

Thoughts: I thought diving by myself into webpack once everything broke after the upgrades was going to be really scary since I am new to webpack config, but it wasn't too bad. Some googling and documentation reading got me going in the right direction. It was great seeing the dev server fire up successfully after getting everything set up.

Link(s) to work: ChaiCMS

Day 2: November 3, Saturday

Today's Progress: I created the Sidebar component for ChaiCMS, hard-coding the links for the moment to point to the dashboard page. I added initial styles for the layout. I then created the Settings page and settings form, adding functionality to edit and display the site title and site description, integrating with the Firebaase database.

Thoughts: I feel like I made fast progress building out the components I worked on today, helped by the boilerplate project from the React Udemy course I just completed. So far, I am feeling pretty comfortable modifying the boilerplate code to build what I need. Tomorrow I plan on creating the tests for the Sidebar and Settings components, actions, and reducers.

Link(s) to work: PR #2

Day 3: November 4, Sunday

Today's Progress: I built out Content Types, Fields, and the start of Entries for ChaiCMS, including updating the Sidebar to populate content types dynamically. I built a basic integration of fields with content types.

Just before bed, I looked into the new React Hooks API and switched two class components (the SettingsForm and ContentTypeForm) over to functional components using Hooks. I for the second form, I created a custom hook, useSlugify.

Thoughts: I know I was planning on building out all the tests for the Sidebar and Settings components, actions, and reducers today, but I found myself much more interested in building rather than testing. I will need to build out the tests at some point, but it is interesting observing myself and my tendencies. I love working with the more visual aspects of coding and being able to see what I am creating. Tests seem more like a "have to do" task rather than a "want to do."

So far, I'm liking Hooks. They seem cleaner and more straightforward than the Class component method of handling state. Moving away from using this for state and props is nice, as is being able to use custom hooks that can be re-used in different components.

Link(s) to work:

Day 4: November 5, Monday

Today's Progress: Today I continued building out the Entries functionality for ChaiCMS, focusing on the EntryForm. I changed the EntryForm component from a class component to a function component, and implemented Hooks to handle state.

Thoughts: Working with the Entries functionality is an interesting challenge since they are meant to have dynamic fields. Unlike Content Types or Fields, I don't know what the fields are going to be, so I have to build with that in mind. Up to now I have been outputting form fields and object properties that I know the object must have, but with Entries the object properties could be anything.

I am loving working with Hooks. Changing from the Class component to the Function component was a relief and I had to think about this.props.whatever and this.state.whatever less, and just code!

Link(s) to work: Changed EntryForm to functional components with Hooks, started building it out; fixed some bugs

Day 5: November 6, Tuesday

Today's Progress: Today I continued building out the Entries functionality for ChaiCMS, working on handling the EntryForm submission of data to the database. I also worked on implementing the list of entries per content type.

Thoughts: Submitting entry data was an interesting little challenge since the fields and consequently key-value pairs in each entry object could vary and would need to be dynamic depending on the fields available for the content type. I had an issue where React didn't like me updating the entry state whose initial value was an empty object {} but when edited had key value pairs. It was expecting the empty state to already have those keys with some default data: { key: "" }.

I tried using a useEffect() hook to populate the state immediately after render and before the text input was used by the user, but that didn't work either. I then passed the calculated state (with all keys that would be used based on the fields available in the content type) from the parent component as a prop and passed that into useState() as the default state, and that worked well.

Link(s) to work:

Day 6: November 7, Wednesday

Today's Progress: Today I worked on the Edit Entry functionality for ChaiCMS. I then changed the route where the edit entry page would live to /entry/:slug/edit/:id and fixed the affected components. Finally, I wiped the database to start from a clean slate for further building, and fixed some issues that came from the empty database.

Thoughts: Today's work was pretty straightforward. I learned more about passing multiple objects as props using the spread operator. I also had to figure out how to debug an issue with an action where it appeared that the updates being passed to it weren't getting through. It ended up being fairly simple once I figured it out.

Link(s) to work:

Day 7: November 8, Thursday

Today's Progress: Today I worked on the add page for content types to redirect to the edit page after a new content type is created. I also added the createdAt and lastUpdated properties to content type database entries. Finally, I changed content types and fields to use apiKey instead of slug in camelCase instead of slug-format.

Thoughts: I wanted the add content type page to redirect to the content type's edit page after it was edited so the user could continue to work on it if they chose instead of redirecting to the list of content types. I ran into an issue where dispatching the startAddContentType action did not return any of the data that firebase return with the generated ID that I would need to redirect to the edit page for that content type. I tried adding a promise .then(()=>{}) to the action, but that didn't work. After a bit of Googling, it seemed that action dispatches were supposed to be "fire and forget," and not return something back after the action was fired.

So then I added createdAt to the content type properties and updated the selector to accept sorts by createdAt. In this way I was able to sort the content types in the state (that was updated in the action) by createdAt and grab the ID of the newest one and use that for the redirect to the edit page. I still did need to add the promise to the action dispatch on the add page so I got the latest state after it resolved.

Link(s) to work: