Well this is it.
Finally, we have reached the end of the line and all the coding for Flatiron school has culminated into the first but definitely not my last website: Fic. E (Fictional Entrepreneur).
This website was built from the ground up with React as the front-end and Ruby on Rails (RoR) as the back.
This website is a story-writing app where the user can either write their own stories,
chapters,
and pages
(Not sorry)
The user is also capable of going to the stories database where they can view stories written by other users and add them to their personal reading list.
To spice things up, the user is capable of navigating to the stories written by other users and writing their own chapter if they are reading the story and are struck by inspiration to write something amazing themselves.
The website’s database is built off of 5 models: chapter, page, story_listing, story, and user.
The way that the model’s relationships work is as such:
A user has many story_listings, listed_stories through story_listings, authored_stories, and chapters through authored stories.
A story has_many story_listings, lists through story_listings, chapters, pages through chapters, and belongs_to an author.
A story_listing belongs_to an author and a story_list (Joins table).
A chapter belongs_to an author, and a story, and has_many pages.
And finally a page belongs_to a chapter.
What this means is that a user can write stories or have them on their reading list, and the user has chapters through these stories.
A story belongs to a user author and can have a user reader, they also have chapters and pages.
A chapter belongs to authors and stories and has pages. And pages belong to a chapter.
Now what is interesting about this relationship and was something that I had to learn while creating this relationship was aliasing.
Aliasing is when a model is given multiple masks that it can wear in order to perform different roles and tasks.
Aliasing can often be used for things like differentiating regular users from admins, but for the purpose of this website aliasing is seen for the User and Story model. The aliasing done here was to differentiate the relationship between authors and readers. You can see this being done with: has_many :authored_stories, foreign_key: :author_id, class_name: “Story”, dependent: :destroy,
in the User model and:
belongs_to :author, class_name: “User”,
in the Story model.
Through the User’s controller you can create a user through /signup and see the user through /me. Through the Session’s controller you can login and logout.
The rest of the model controllers perform standard CRUD (Create, Read, Update, and Destroy) operations.
Finally the routes look as such:
Now to get to the most time-consuming aspect of the project, the React front-end.
Despite it’s simplistic CSS, the front-end was deceptively complex to code. It involves many ternary operators ({condition ? (return object if truthy): (return object if falsy)}) that was dependent on a fetch request existing and having a length greater than 1.
The navigation, for the ease of user access, using the useLocation method was tricky to nail down due to my difficulty in grabbing certain params (Console.log(params) was supremely helpful in finding the correct paths).
Some aspects that I found particularly difficult was trying to keep my routes RESTFUL.
This was due to the fixation on making everything as user friendly as possible with my limited tool set.
This was WRONG! In hindsight it was silly that I was even concerned about it, but initially I tried to make the URL short and sweet. As if the user actually ever stopped to look at the URL or even cared if it was over 50+ characters (looking at you Google images). All this would have ended up doing was making the life of any potential programmer behind me very confused and frustrated. Because I was breaking convention.
Thankfully, my cohort lead in Flatiron, was able to steer me away from this difficult and potentially dangerous habit, when she said that this way of breaking away from RESTFUL routing was a no-go.
That was a very long and painful +3 hours, going back and searching for and rewriting my code to make it RESTFUL.
Thankfully, I was reminded of this while I am still learning.
Another hurdle I had to overcome was keeping my code DRY (Don’t Repeat Yourself). But that’s neither here nor there, I’m still green, and making my code DRY is something a developer can always improve on. It does remind me to go back and read more on React component relationships and reviewing parent and child relationships.
Overall… This was fun! It was definitely a difficult challenge to come up with and create my very own complete project with a front and back-end from scratch, but it was certainly rewarding! It showed me what I was capable of, and inspired confidence that I had grown considerable from 7 months ago to now.
I look forward to diving even deeper into this field, and I can’t wait to tackle the new beast ahead of me, job-hunting to be a junior developer.
Wish me luck!
Anyways.
Thank you for listening.
Please be happier.
This has been Aeco, logging off.