An Open-Source DoorDash Clone? Lucine Pt. 4

Hi, again! In the last article, we had started to modify the pre-built Salient Next.js template from Tailwind UI for Lucine. We had just starting looking at how to modify this template to be relevant for our product, and in this article we will continue to modify this template until it is how we want it to be.

To get started, let’s make sure that our development environment is up and running by opening the lucine repository folder in a terminal and running yarn dev (or npm run dev if you use npm). If you were following along with the last article, you’ll remember that all we did last time was change the hero text to say “Delivery made open-source for all.”

I’m a big fan of the color scheme for the template, so I won’t make any changes here. Most of the changes we need to make for this template are in the textual content and the images, so I will do that and showcase where in the code these changes should be made. Right underneath the <h1 /> hero text, we want to change where it says “Most bookkeeping software is accurate, but hard to use. We make the opposite trade-off, and hope you don’t get audited” to say “Delivery should be easy and on your own terms. We make that happen.”

To make this change, we need to go back to the <Hero /> component located in src/components/Hero.tsx. You should see the <p /> tag that needs to change. After doing so, we should see the site update as such:

Now, we don’t have any companies that trust us so we want to remove this section. If you keep looking inside of the <Hero /> component, you will eventually see where this section is defined in the React code. Here it is:

We may or may not want to add this section back in the future, so we don’t want to delete it. Instead, let’s extract this into its own component for readability and then comment the invocation out. I’m going to extract this HTML into a <TrustedBySection /> component at the top of this Hero.tsx like so:

We extracted the array of objects that used to just be defined in-line with the HTML into it’s own companyGroups variable. We also defined an interface and type that this variable must conform to just for the sake of developer experience. Now, we can simply replace where this HTML used to be in the <Hero /> component and comment it out, as such:

Now, if you are following along then you should be able to see that the section is in fact removed. Next, we will want to modify the section that says “Everything you need to run your books.” Before we make any changes, we should think about how this section is actually working. When you click any of the “buttons” on the side, the image on the right-hand side of the screen changes. This means we will need to have images of the product to showcase for this section to work properly.

We don’t have any images nor do we have a way to get any since the application itself isn’t finished. That’s okay, though--we’ll just change the text content so it’s how we want it and remember to come back and update the images later. To find the source code for this section we should follow a similar tactic that we did for the <Hero /> component, and check the root-level src/app/page.tsx. Inside of this file, we find a <PrimaryFeatures /> component underneath the <Hero /> component. I’m willing to bet this is what we’re after.

After going to the source code for the <PrimaryFeatures /> component, which is in the src/components/PrimaryFeatures.tsx file, we can see that this is indeed what we’re looking for. At the top of the file you will notice the following variable definition:

This features array matches up with what each of the buttons we saw on the site. Let’s start off by changing these and see if the site itself updates the way we think it will. Here is the modifications I made:

Now, if we check the site we see that the following has changed:

Finally, let’s change the text at the top of this section as well. Further down in the src/components/PrimaryFeatures.tsx file we can find where the text is defined:

We’re just going to change this to the following:

Wow! That’s a lot of code in one article! From here on out, the amount of code content is going to increase as we delve deeper into the details and implementation of the project. I will try to ensure I do my best to explain the code, when it is present, with as much exposition as possible.

Before we wrap things up, I want to go ahead and show the finished requirements document here. You may skip this part! I will not describe the reasoning behind these requirements, but know that I followed the same procedure I described (in almost three articles lol) in previous articles for dealing with abstraction. This is a very complicated application, and a full requirements document is far beyond the scope of any blog series. I did not fill it out as completely as I would if this were a genuine, for-profit project. Also, there are some new "central pillars" that we didn't discuss earlier. Here are the requirements:

See you next time!