I developed InterPayments Frontity website the same time I developed my previously shared website but didn’t really have time to document it (I don’t have time today either but I decided to get it done anyway). As a result, I’ve forgotten some talking points but I remember a couple things:
First of all, I tried to add theme variables to the context and made the mistake of adding it to my Frontity theme’s root object instead of adding it to state. If someone can tell me why this wasn’t a great idea, I’d love to know. As far as I can tell, it’s probably considered better practice to add it to state but I didn’t really break anything so far. Perhaps a future update would be problematic but I can’t see why at this point. After this project, I’ve added theme variables to state and it works more or less the same. I imagine switching it might be a bit painful now that the site is done…
I loved using theme but since certain properties of my theme depended on others, I had to create variables before assigning them to the theme object. For example, I have theme colors that are required to style the button themes, so the colors have to be an object in a variable that is then assigned to theme.colors: colors so that I can reference those colors inside buttonStyles: { primaryButton: {...}}. Unfortunately, I can’t share the code (I have another project wrapping up soon that I’ll be able to share that features this) but it’s something to keep in mind.
What I loved about using a theme object is the ability to use Javascript color utilities as well as writing CSS using the Emotion css function. This allowed me to do some color math just like I would with SASS and directly embed CSS in styled components, regardless of classes etc. I like the styled components because sometimes you need the flexibility of not using classes or elements in CSS.
One great example of the power behind styled components is the styled boxes used on various pages (such as the Compliance page) and in pop-ups throughout the site. In creating one styled component and modifying it just how it needs to be for each use-case, I coded once something very unique and striking and implemented it throughout the site amazingly easily.
Another cool feature on this site is the Products, Compliance, Technology pages’ inter-page navigation. On those pages, a specific template allows for a menu to be used to allow pages to be navigated between. This is something that I could do before but it feels much faster on Frontity. This also highlights the pros of an SPA website, that the scroll position stays between navigation.
On all other sites I’ve made with Frontity, this is a pain because I have to manually set the scroll position back to the top of the page on navigation to emulate standard browsing experience but in this case, it works well to avoid doing that. While I had to create a separate component for that, it wasn’t that big of a deal to invoke the default behaviour.
Lastly, deployment was a bit tricky for a couple reasons. The first issue was that my client was using a Google Cloud Compute to host their WordPress installation. After using so many different web hosts, I can’t believe how much of a pain it was to use Google Cloud Compute to host the easiest to set up CMS. It took double or triple the amount of time as even a manually installation would take, not to mention all the back and forth to get permissions from the client. I had to use the Google Cloud Compute CLI to SSH into the server and it felt incredibly bloated and unnecessary. Still, it was done and now I know not to recommend Google Cloud Compute to people with WordPress website back ends.
Another thing about deployment was that you really have to follow the instructions on the Frontity site about deploying to Vercel. My client was used to just connecting the repository of a React project and having the instructions built into it when that is not the case. Just linking a Vercel project to your Frontity site’s repository will result in broken deployment instructions. We did figure it out but I had to do a little bit of hand-holding.
A small issue I uncovered about Vercel in particular is that domain management is a little bit opaque. In order to have control over a domain’s subdomains, you have to be the domain’s owner. This was a pain in that we also deployed some React projects to subdomains as well as the Frontity site. Additionally, transferring domains for a production site is a bit painful: To avoid downtime, you’ll have to set up a team, add the current owner of the domain to the team, transfer the domain to the team, link it to a working duplicate project, and then you are able to transfer domains how you like within the team members; it was convoluted to say the least.
Anyway, it was an overall success and I can see that the original red theme has been replaced now with a green one by the client’s new developer so I suppose my code was ease enough to manipulate. Let me know if you have any questions, answers to my questions, or comments on the project, thanks!
