# Strapi Series, Part 9: Thinking In Data
Source: https://www.dandenney.com/posts/front-end-dev/strapi-series-part-9-thinking-in-data
Date: 2023-05-03
Tags: front-end-dev
Summary: Lessons learned from my first attempts at modeling this Strapi project's content as data instead of pages.
---
I learned a ton in trying to create these, and this is my third attempt at creating this blog post. Between attempts two and three, I even started to make a video instead. I am going to do the videos, but I figured out some important things that I want to be sure to share in text and images as well.
## Everyone Has A Plan Until They Get Punched In The Mouth
That quote from Mike Tyson is a close second to my favorite quote about web development: "No plan survives contact with the enemy," by Moltke the Elder. I'm leading with the Tyson one here because it's how I feel after trying to get this blog post written. If I was just creating the header and the footer like the original plan, it would have been maybe 30 minutes of learning. I have made things more challenging by trying to write the post as I stumble through things. The stumbling was way too much for anyone to endure, and it's challenging to write about the UI without screenshots. I would need so many screenshots to make sense of things that video feels like the better choice from now on. This post will make a good transition point, with the future ones focusing on the implementation in Strapi and then hooking up the data in code.
## The Plan
I'm breaking this down into pieces with an idea of how I was thinking about creating items. One important note is that my day-to-day is often implementing designs from Figma, with very little CMS usage. That's changing, and it's why I'm doing this series, but it's important for grokking how I was applying code component thinking to data organization.
1
Logo
The logo will need to be able to be altered when the theme changes, so I know I need it to be SVG to avoid image swapping. I want it in the CMS for this scenario I've run into over my years in marketing/growth where campaigns apply styles to site items. The blocker that I hit is that adding an SVG via the media upload will return an image as a URL and the existing Babel config won't parse the code from an SVG that comes from a URL. There is technically a way to use a rich text field and paste in the SVG code, but that felt too hacky. The result is that the logo will not go into the CMS.
2
Page Links
A "collection" of page links that I originally thought would use a shared "link" component that had the attributes that links could have: text, slug, maybe target if the need arose in the future. Using a component led to some interesting challenges since it was the sole item in a Page Link. This meant that when creating a relation, you could only use the ID, which felt rough for the UX in the admin. I also learned that while I think it's a collection of "Page Links", Strapi sees it as a "Page Link" collection. That's important for naming because you need singular and plural for collections. The result is that there will be a "Page Link" collection and each "Page Link" will have text and hash attributes.
3
Text for the existing customer link
Since this would lead to the page for authentication, it doesn't seem like a good idea to allow for full customization. This plan remained the same, with the only oddity being how to think about naming a "sign in" link something that makes sense if it's changed to "log in." The result will be an optional field named NewCustomerLinkText.
4
Text for the new customer link
Similar to 3, this will only allow a text change since it goes to the registration page. The style of the button won't be customizable because it's the same throughout the UI for authentication-based inputs. The result will be an optional field named ExistingCustomerLinkText.
5
Social icons and links.
These have the same problem as the logo, plus one. We could get away without a hover style on the logo, but these should have default and hover styles that work well with the light and dark theme. Arguably, the social links for a company don't change often, so it's not a major deal to not have these customizable. The result is that they will be handled in the code until a possible future, where I work out adding SVG code in a clean way.
6
Header
I originally had a "Header" component that had the fields for the customer links and a relation with the "Page Links". It was a single type because I could see the potential for having another header for the authenticated experience, but they wouldn't be the same patterns with different content. Once I realized the footer would only query the "Page Links" and I was ready to grab data from the API, I realized I'd be requesting that data twice. It'd be the same if I had created a "Footer" as well. The result is that there is no "Header component, but I will need to add "Authentication Links" or something to that effect.
7
Footer
With all of the other changes, it became apparent that we didn't need a "Footer" component. It might group things in the admin, but it would increase the data requests. The result is no "Footer" for now.
## The Recovery
The main thing that I have learned is to think about the data and not the UI or the component composition in the front-end. The tasks from here are to create a "Page Links" collection and a "Authentication Links" collection. With those two created, request them into the page and pass the data into `` and `
