General

Quality of Life With Static Site Generator

Published Mar 25, 2021

Updated Jan 31, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Intro

We're building a new marketing site here at Fancy Pants Inc. A totally new greenfield project within an existing organization is fun and exciting, but offers a unique set of challenges. Let's outline some of the most common scenarios and see how to tackle them head on.

For this, we're going to start with the idea of sort of a team meeting, a kind of round table discussion. We have a new site that has static content and maybe some forms.

Some of the requirements from our collective bosses: everyone needs to be able contribute, but only the director or those bestowed with the power can publish content. The other big need is to be able to see changes, updates, new material on the site and pass around an internal url to gather feedback before it ever goes live. There are a few more catches that will come up as we scaffold out this exciting new project.

Like all good sized projects, we've made some choices up front and want to tease out if they will meet our needs before writing up the work and getting started. Based on a few of the requirements outlined earlier, we'll be using Sanity content platform. Everything will hopefully go there from importing existing content, rich media, and even copy for the landing page. For our development choice and deployment, we've chosen Eleventy paired with Netlify for deploy. The idea is to make the developer experience vastly superior to our current system: to make deployment and preview of the project as seamless and transparent as possible. Let's get started.

Where do we start

When we talk about everyone in the company being able to 'contribute', what exactly do we mean? Everyone should be able to make a blog post about the latest and greatest? That sounds fine. What about changing the copy on the homepage or updating the Terms and Service fine print buried in the footer? That's a little less clear now, right? These questions raise important technical decisions about were to apply friction. We often talk about 'reducing friction' as a positive thing. We want to reduce the friction of custom checkout so that more people will buy our product or goods. There are cases, however, were we want to increase friction. We want to ensure that updating legal copy or replacing the hero image on the home page is not just a one click away. There needs to be some amount of process or intentional friction to be a sort of checks and balance.

With that in mind we'll create some simple roles within Sanity 'creator' and 'moderator'. Sanity has a great sample project and the CMS studio itself is React components all the way down, so we can customize it to great extent. We're not entirely sure what the fine grain controls will look like, so let's start broad and then we can narrow down those controls overtime.

For now, creators can create any new content that includes page updates and posts, but only moderators can actually publish that content from its draft version to production. With the content up and running, the actual site will be built leveraging Eleventy Static Site Generator, and the main reason is for its simplicity and flexibility.

In Eleventy, data is merged from multiple different sources before the template is rendered. The data is merged in what Eleventy calls the Data Cascade.

While we are only getting data from Sanity to start with, we have multiple other data sources that will need to be added. Even if that list were zero, a growing business and product will need to evolve and take on new responsibilities in the future. You'll thank your past self when you need to add Shopify or some other datasource in addition to the CMS.

We don't needs gates

Just when we are starting to get some momentum in the project, a hiccup. As we onboard different departments into adding content, there are several requests for a more fine grain approach to content permissions. Our "anyone can create" approach isn't going to fly. After some research, it's decided that Contentful has the sort of finer permissions built in that teams are looking for. Great, but what do we do with our implementation now?

A suggestion is to run git init a new project and just start over. We've spend a nontrivial mount of time working on templates and layouts in Eleventy, is it salvagable? The short answer is, yeah absolutely. Remember: our site doesn't care where the data comes from or how many places it comes from. We can wire-up Contentful as a data source, adjust the templates to any changes in the structure of the content (post.body may now be something like post.content) and then run a new build. Having this deployed on Netlify, a couple of us can work on a feature branch, deploy, and share it without slowing down the group working on the page layout, footers, or contact page!

Cache is still hard

Cache continues to be awful. Humans are not built for the level complexity Goldberg machines that deploy software. We want to keep things simple, and more importantly deterministic. We don't want deployment should not be a constant consideration when creating, improving, or trying new and inventive things within the company.

Our goal is whatever is merged into the main branch will be deployed to the production url. So let's follow those steps. A pull request is merged into main. This kicks off a build of the app on Netlify. It runs npx @11ty/eleventy, gathers up all the data sources from across a pleura of sources, and starts to build, on success Netlify points, all the incoming http requests from Fancy Pants dot com to the newly built site that our build step outputted to _site.

What if it fails? That might happen. Sooner or later it's going to happen. Will the customers of our fine establishment be forever disappointed with the HTTP 500 ERROR they witnessed? Nope. They won't even know. When a build fails, not if, the site continues to run the last successful build it has been. We can setup a web hook to send us a slack message, 'ops, looks like the build failed'. This is a very different message then: 'the software team broke production and we're losing money every minute it's down, everything is on fire!!!'.

Those messages invoke very different feelings, don't they? When you've broken a build, gone back and fixed it, then deployed again, you likely forget about it the next day. If you've ever broken production and spent endless hours trying to put it back together again, you'll never forget it.

Quality of Life

This is very much a quality of life that a system like the JamStack provides us: it's secret sauce. Things are going to go wrong, and when they do, you have the time, space, and mental where-with-all to fix it. When it fails, and it will at some point fail, it doesn't affect the product in production. Other teams internally may not even notice. This gives everyone explicit permission to ship. If that's publishing content with some cool new media, or the latest and greatest GraphQL data collection: if it fails, it's fine. The risk is so low as to be trivial to ship and to try new things. If this all sounds too good to be true, it's not, I promise. Come join us on the moon.

'What a waste of time. It's physically draining to do release engineering. There are other things we want to be doing. And it's not FE release engineering. ' ~ Jason Lengstorf

'It's not something we worry about on our team' ~ Zach Leatherman

I want to thank my guests on Build In Better, Jason Lengstorf with Netlify and Zach Leatherman, Open Source Author of Eleventy, for an amazing conversation and sharing their knowledge with me. This article would not be possible without their time and insight. Thank you. 👋

Special Thanks to the fine folks at Fancy Pants wearables and underoos 😉

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jesse Tomchak
I work at as a Senior Engineer building dev tools to help everyone be super productive. Teaching JavaScript fundamentals from beginning to excited is a personal passion. Always up for a conversation about types and the paradigm of functional programming. I have dad jokes for days.
@jtomchak @jtomchak

Demystifying React Server Components

React Server Components (RSCs) are the latest addition to the React ecosystem, and they've caused a bit of a disruption to how we think about React. Dan Abramov recently wrote an article titled "The Two Reacts" that explores the paradigms of client component and server component mental models and leaves us with the thought on how we can cohesively combine these concepts in a meaningful way. It took me a while to finally give RSCs the proper exploration to truly understand the "new" model and grasp where React is heading. First off, the new model isn't really new so much as it introduces a few new concepts for us to consider when architecting our applications. Once I understood the pattern, I found an appreciation for the model and what it's trying to help us accomplish. In this post, I hope I can show you the progression of the React architecture in applications as I've experienced them and how I think RSCs help us improve this model and our apps. A "Brief" History of React Rendering and Data-Fetching Patterns One of the biggest challenges in React since its early days is "how do we server render pages?" Server-side rendering (SSR) is one of the techniques we can use to ensure users see data on initial load and helps with our site's SEO. Without SSR, users would see blank screens or loading spinners, and then a bunch of content would appear shortly after. An excellent graphic on Remix's website demonstrates this behavior from the end user's perspective and it's a problem we generally try to avoid as developers. This problem is so vast and difficult that we've been trying to solve it since 2015. Rick Hanlon from the React Core Team reminded us just how complicated this problem was recently. If you think react is complicated now, go back to 2015 when you had to configure babel and webpack yourself, you had to do SSR and routing yourself, you had to decide between flow and typescript, you had to learn flux and immutable.js, and you had to choose 1 of 100 boilerplates— Ricky (@rickhanlonii) January 28, 2024 But SSR has its issues too. Sometimes SSR is slow because we need to do a lot of data fetching for our page. Because of these large payloads, we'll defer their rendering using lazy loading patterns. All of a sudden we have spinners again! How we've managed these components has changed too. Over the years, we've seen a variety of patterns emerge for managing these problems. We had server-side pre-fetching where we had to hydrate our frontends application state. Then we tried controller-view patterned components for our lazily loaded client-side components. With the evolution of React, we were able to simplify the controller-view patterns to leverage hooks. Now, we're in a new era of multi-server entry points on a page with RSCs. The Benefits of React Server Components RSCs give us this new paradigm that allows us to have multiple entries into our server on a single page. Leveraging features like Next.js' streaming mode and caching, we can limit what our pages block on for SSR and optimize their performance. To illustrate this, let's look at this small block of PHP for something we might have done in the 2000s: index.php ` For simplicity, the blocks indicate server boundaries where we can execute PHP functionality. Once we exit that block, we can no longer leverage or communicate with the server. In this example, we're displaying a welcome message to a user and a list of posts. If we look at Next.js' page router leveraging getServerSideProps, we would maybe write this same page as follows: pages/posts.jsx ` In this case, we're having our server do a lot to fetch the data we need to render this page and all its components. This also makes the line between server and client much clearer as getServerSideProps runs before our client renders, and we're unable to go back to that function without an API route and client-side fetch. Now, let's look at Next.js' app router with server components. This same component could be rendered as follows: app/posts/page.tsx ` This moves us a bit closer back to our PHP version as we don't have to split our server and client functionality as explicitly. This example is relatively simple and only renders a few components that could be easily rendered as static content. This page also probably requires all the content to be rendered upfront. But, from this, we can see that we're able to simplify how server data fetching is done. If nothing else, we could use this pattern to make our SSR patterns better and client render the rest of our apps, but then we'd lose out on some of the additional benefits that we can get when we combine this with streaming. Let's look at a post page that probably has the content and a comments section. We don't need to render the comments immediately on page load or block on it because it's a secondary feature on the page. This is where we can pull in Suspense and make our page shine. Our code might look as follows: app/posts/[slug]/page.jsx ` Our PostComments are a server component that renders static content again, but we don't want its render to block our page from being served to the client. What we've done here is moved the fetch operation into the comments component and wrapped it in a Suspense boundary in our page to defer its render until its content has been fetched and then stream it onto the page into its render location. We could also add a fallback to our suspense boundary if we wanted to put a skeleton loader or other indication UI. With these changes, we're writing components similarly to how we've written them on the client historically but simplified our data fetch. What happens when we start to progressively enhance our features with client-side JavaScript? Client Components with RSCs All our examples focused on staying in the server context which is great for simple applications, but what happens when we want to add interactivity? If you were to put a useState, useEffect, onClick, or other client-side React feature into a server component, you'd find some error messages because you can't run client code from a server context. If we think back to our PHP example, that makes a lot of sense why this is the case, but how do we work around this? For me, this is where my first really mental challenge with RSCs started. Let's use our PostComments as an example to enhance by in-place sorting the section from the server. ` In this example, we're using a server component the same way as our previous example to do the initial data fetch and stream when ready. However, we're immediately passing the results to a client component that renders the elements and enhances our code with a list of sort options. When we select the sort we want, our code makes a request to the server at a predefined route and gets the new data that we re-render in the new order on screen. This is how we might have done things without RSCs before but without a useEffect for our initial rendering. If you're familiar with the old controller-view pattern, this is relatively similar to that pattern, but we have to relegate client re-fetching to the view (client) component, where we might have had all fetch and re-fetch patterns in the controller (server) component Another way to solve this same problem is leveraging server actions, but that would cause the page to re-render. Given the caching mechanisms in Next.js, this is probably fine, but it's not the user experience people are expecting. Server actions are a topic of their own, so I won't cover them in this post, but they're important for the holistic ecosystem experience in the new mindset. Interleaving Nested Server & Client Components These examples have shown a clean approach where we keep our server components at the top of our rendering tree and have a clear line where we move from server mode to client mode. But one of the advantages of RSCs is that we can interleave where our server component entry points may exist. Let's think about a product carousel on a storefront page for example. We may have built this as follows before: ` Here we're rendering carousels that render their cards and our tree goes server -> client -> server. This is not allowed in the new paradigm because the React compiler cannot detect that we moved back into a server component when we called ProductCards from a client component. Instead, we would need to refactor this to be: ` Here, we've changed ProductCarousel to accept children that are our ProductCards server component. This allows the compiler to detect the boundary and render it appropriately. I'd also recommend adding Suspense boundaries to these carousels but I omitted it for the sake of brevity in this example. Some Suggested Best Practices Our team has been using these new patterns for some time and have developed some patterns we've identified as best practices for us to help keep some of these boundaries clear that I thought worth sharing. 1. Be explicit with component types We've found that being explicit with component types is essential to expressing intent. Some components are strictly server, some are strictly client, and others can be used in both contexts. Our team likes using the server-only package to express this intent but we found we needed more. We've opted for the following naming conventions: Server only components: component-name.server.(jsx|tsx) Client only components: component-name.client.(jsx|tsx) Universal components: component-name.(jsx|tsx) This does not apply to special framework file names but we've found this helps us delineate where we are and to help with interleaving. 2. Defer Fetch when Cache is Available If we're trying to render a component that is a collection of other components, we've found deferring the fetch to the child allows our cache to do more for us in rendering in cases where the same element may exist in different locations. This is similar to how GraphQL's data loaders works and can ideally boost the performance of cached server components. So, in our product example above, we may only fetch the IDs of the products we need for the ProductCards and then fetch all the data per card. Yes, this is an extra fetch and causes an N+1, but if our cache is in play, end users will feel a performance gain. 3. Colocate loaders and queries If you're using GraphQL or need loading states for components for Suspense fallback, we recommend colocating those elements in the same file or directory. This makes it easier to modify and manage related elements for your components in a more meaningful way. 4. Use Suspense to defer non-essential content This will depend on your website and needs. Still, we recommend deferring as many non-essential elements to Suspense as possible. We define non-essential to be anything you could consider secondary to the page. On a blog post, this could be recommended posts or comments. On a product page, this could be reviews and related products. So long as the primary focus of your page is outside a Suspense boundary, your usage is probably acceptable. Conclusion RSCs represent a significant evolution in the React ecosystem, offering new paradigms and opportunities for improving the architecture of web applications. They enable multiple server entry points on a single page, optimizing server-side rendering, and simplifying data fetching. RSCs allow for a clearer separation between server and client functionality, enhancing both performance and maintainability. To make the most of RSCs, developers should consider best practices such as being explicit with component types, deferring fetch when caching is available, colocating loaders and queries, and using Suspense to defer non-essential content. Embracing these practices can help harness the potential of React Server Components and pave the way for more efficient and interactive web applications. We're excited about this development in the React ecosystem and the developments happening across teams and frameworks that are opting into using them. While Next.js offers a great solution, we're excited to see similar enhancements to Remix and RedwoodJS....

Feb 2, 2024

9 mins

ReactNextJSArchitecture

What is a Monorepo and What Are the Advantages for Using It in Your Project?

Monorepos are very popular in the tech industry, and many large companies like Microsoft and Google use them. But what exactly is a monorepo, and would it work for your project? In this article, we are going to explore what the monorepo architecture is, and learn about some of the commonly used tools for monorepos. Table of contents - What is a monorepo? - Unified build process and CI/CD process - Increased cross team communication - Steeper learning curve and issues of inclusivity for newer developers - A look into the starter.dev monorepo - What is starter.dev? - Why did the team choose a monorepo structure? - What are Yarn Workspaces? - Unified CI/CD pipeline with Amplify - How does the team manage issues? - Conclusion What is a monorepo? A monorepo is a single version controlled repository that contains multiple independent projects. Some monorepos might contain just 2 or 3 projects while others will contain hundreds of projects using different technologies. This differs from the polyrepo structure where the projects are spread out amongst multiple repositories. It is also important to note that a monorepo is not the same as a monolith. A monolith has multiple sub-projects inside one giant project while monorepos have multiple independent projects inside one repository. Unified build process and CI/CD process In a monorepo structure, all of CI/CD(Continuous integration/Continuous delivery) lives in the same repository. This provides teams with more flexibility, and allows you to deploy your services together. You can also choose to deploy your projects separately. Increased cross team communication In a polyrepo structure, you will have multiple teams working on different projects spread across many repositories. Often times these teams will not be aware of the status of other repositories outside of their main one. With a monorepo structure, teams are more aware of the changes being made to the projects used in the repo and might spot issues in another projects. When all of your projects are under a single repository, it makes it easier to establish a consistent code style and set of guidelines across all projects. Some of the guidelines can include naming conventions, best practices for code reviews, branching policies, etc. In situations where there are breaking changes in the main branch, a monorepo can help identify where the breaking change came from and that team would be responsible for fixing it. A monorepo can also help teams discuss different versioning strategies for the projects. Steeper learning curve and issues of inclusivity for newer developers Inclusivity of all developers on a team is really important for the success and outcome of a software project. When you have many diverse perspectives and levels it will lead to a stronger finished product. But a monorepo structure could be seen as intimidating to novice developers. It might be their first time seeing a list of independent projects within the same repository and they might not know how to best contribute in a meaningful way especially if it is an open source situation. It can also be difficult for newer developers to understand the git history under a monorepo structure. If you are using a tool like git blame,it will have to sift through a lot of unrelated commits just to generate that information for you. For these reasons, it is important for the team to help newer developers through the monorepo structure and create issues where all levels can meaningfully contribute. A look into the starter.dev monorepo Let's take a look at a couple of This Dot Labs open source monorepos and understand why the decision was made to use a monorepo. Please note: We will not be exploring all of the possible tools used for monorepos. If you are interested in exploring more monorepo tools, then please checkout this curated list. What is starter.dev? starter.dev makes it easy to setup a new project with zero configuration involved. Once you install the starter.dev package(npm i @this-dot/create-starter), you can run the npx @this-dot/create-starter command and it will provide you with a list of starter kits to choose from. Each starter kit includes testing, linting, code examples and a basic configuration setup. starter.dev is an open source project that consists of a documentation website repository and a GitHub showcases repository dedicated to all of the different starter kits. Why did the team choose a monorepo structure? When it came time to plan out the project, the team had to decide if they wanted to maintain each kit in isolation or create different folders for each kit under the same repository. The reason for using a monorepo structure is to provide the team the ability to build the CLI(command-line interface) with greater ease and allow the team to still build the kits in isolation. What are Yarn Workspaces? The documentation website repository uses Yarn Workspaces which allows you to setup multiple packages and use the yarn install command to install them all at once. In the root directory, we have starters and packages directories. If we look at the starters directory, we will see all of the starter kits. Each starter kit will have its own package.json, basic configuration, README and code examples setup. Inside the root package.json file, you will notice this "workspaces": [ "packages/*"] key. ` That will tell Yarn to import all of the packages that are listed inside of the packages folder. Unified CI/CD pipeline with Amplify The starter.dev GitHub showcases repository has a unified CI/CD and uses Amplify. Inside the root directory, there is an Amplify yaml file where each application has their own set of build commands. Each project listed in the monorepo has its own deployment process setup. ` How does the team manage issues? If you look at the issues tab, you will notice that all of the developers are following this same naming convention for issues: [starter kit] title for issue. This works well for a variety of reasons: 1. Any developer interested in contributing to the project, can see at a quick glance which issues fit their skill and interest level. 2. It will be easier to track the status of the issues on a project board and see which areas need more attention. Conclusion We have explored the monorepo structure and talked about a few features. We have also compared it to other architectures like monoliths and polyrepos to see how if differs. Then we took an in depth look into starter.dev and how it uses Yarn Workspaces to help organize the project. I hope your enjoyed this article and best of luck on your programming journey....

Sep 23, 2022

6 mins

Architecture

Build It Better Headless CMS With Prismic & Storyblok

The Headless CMS architecture is red hot in the JamStack community right now. I feel like new products and services are popping up daily. I had the pleasure of sitting down with Lucie Haberer, DevRel at Prismic, and Samuel Snopko, DevRel at Storyblok to get the details on this emerging product category, its origin story, features, tradeoffs, user experience, futures, and more. Below is a summary of the information that I learned from our conversation. The Pain of Getting Data out of the CMS The growing use and improvement of frontend tools and frameworks puts increased pressure on existing monolithic content management systems to make the data more accessible outside of itself. Getting content in a monolith, like WordPress, was relatively quick and easy. Getting that data from there to anywhere else that wasn't a hosted webpage, within that single-engine, was far more difficult. Coupled with the skyrocketing use of mobile devices, apps, and increased web access around the world, the monolith became a point of frustration for developers, and a bottleneck for businesses needing to update and adapt quickly. Who's Leading Who? Is the JAMStack empowering Headless CMS, or is it the other way around? From static site generators like Jekyll, to full-blown web applications backed with content available via APIs from Headless CMS, this relationship isn't one-sided, but rather reciprocal. As UIs needed more options and flexibility over the content, the APIs that Headless companies like Prismic and Storyblok offer were built-out to meet these needs. As the ecosystem of content APIs expanded, so did the features offered by visual studios, as well as their use in web apps, mobile, video, and smart devices. It is this mutual benefit that has led to explosive growth in both Headless CMS and JAMStack use across the industry. Not just creating content, but changing content shape I think the real superpower of Headless CMS lies in its ability to let anyone not just create content, but modify the shape of the content itself. Imagine the scenario where a company wants a quick landing page for an upcoming event. Now, most of us would roll our eyes at the use of "quick', but bear with me. It's a "simple" page with a hero image, some event details, an image, and a video. It's a specific use case, and they don't want to add it as a blog post along with the other content. Maybe they want it at '/coming-soon' on the domain. Well, that URL route doesn't even exist currently. Could this be done without ever contacting the development team? Since the content is decoupled, and just pulled via APIs when the site is built, surely you'd need some tweaking in the code for the HTTP fetch calls? With Headless CMS, nobody from the development, ops, or admin teams needs to be involved. The setup would be something like this: There is a defined set of routes within the content. A route has a slug property and Page property. Page is another data type. A page is an array of basic types like image, text, date, and yes even video. So in our scenario, the team- without you, the developer- can go in add their route, name whatever they'd like, and start building out their custom page. Arranging the image on top, with the right copy, and the video above the fold is a matter of simply ordering the item in the content interface. Once it's all set, they can retrieve a preview link, send it to the director to view and approve, and then hit publish. Whenever content is added or updated, our site fetches the data, executes npm run build, and then pushes that build-out across a network of CDNs. In this case, our fetch routes function has been happily iterating over a list of type routes on every build- this time it just so happens to have a '/coming-soon' element to it. So it creates the actual route, and then fetches the Page data from the CMS. It is then formatted, and styled as just as data from a Page type would be. Then it is bundled, and deployed with the rest of the site. Voilà. Now, it goes without saying that a lot of time and consideration goes into setting this all up, testing it, and getting it to work together. But, it illustrates the level to which we can empower others to create and build on this model of decoupling content, provided by Headless CMS. Just The Beginning It is clear that the paradigm has shifted to Headless content, and that consumption is an aggregate of many sources into multiple formats. From mobile apps, web, to voice assistants, and curbside pickup, people everywhere are adapting and changing their habits. As developers, we have the tools to build an awesome and empowering experience for others to create their vision on top of this. I am excited to see the next idea, product, or format that is published without direct help from the developers....

Sep 27, 2021

4 mins

JavaScript

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Quality of Life With Static Site Generator

Intro

Where do we start

We don't needs gates

Cache is still hard

Quality of Life

Jesse Tomchak

You might also like

Demystifying React Server Components

What is a Monorepo and What Are the Advantages for Using It in Your Project?

Build It Better Headless CMS With Prismic & Storyblok

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

Demystifying React Server Components

What is a Monorepo and What Are the Advantages for Using It in Your Project?

Build It Better Headless CMS With Prismic & Storyblok

Building a Stripe App: A Step-by-Step Guide to QR Code Generation