Javascript

Problematic Try-Catches in JavaScript

Published Sep 14, 2020

Updated Feb 14, 2023

5 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.

Problematic Try-Catches in JavaScript

The try-catch syntax is a fundamental feature in most programming languages. It allows us to gracefully handle errors that are thrown in our code, and they do so in a way that is familiar to all programmers.

With that in mind, I'm going to propose that they are also highly misused and have a huge impact on the future maintainability of our codebases, not to mention, force us to sometimes implement error-prone code.

The beauty of using the standard try-catch syntax is that if we come back to a section of our code using try-catch, we immediately know that something in this block of code may throw an error, and we want to ensure that our application doesn't fall over because of it.

Reading the following block of code, we should get the general understanding of what is happening:

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

We can see that the block of code will perform some logic to get a result, then it will mutate that result. On error, it will log the error to the appropriate location.

So what's the problem? 🤔

Or rather, what are the problems? Let's look at each in turn!

1. Which method is throwing the error?

If we come back to refactor this block of code, we can't tell simply by looking at each method call in the try block which method may throw.
Is it performSomeLogic() or is it transformTheResult(result)?

To figure this out, we'll need to find where these functions are defined and read through their source to understand which one could potentially throw an error.

Is the function from a third-party library? In that case, we're going to have to go and find documentation on the function, hoping that the docs for the version we are using are still available online, to figure out which function could throw the error.

THIS IS PROBLEMATIC

It's adding additional time and complexity to understand the section of code, reducing its future maintainability. Refactoring or fixing bugs in this area is more complex already!

2. What if both methods should throw?

Here comes a new problem! When both performSomeLogic() and transformTheResult(result) are expected to throw, the catch block does not provide a convenient way to differentiate which threw:

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  // Did performSomeLogic or transformTheResult throw?
  // How can we find out?
}

So, now that both could throw, how do we find out which threw, in the case that we need to handle the errors differently? Do we inspect the error message?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
} catch (error) {
  if (error.message.includes("performSomeLogic")) {
    // Do error handling specific to performSomeLogic
  } else {
    // Do error handling specific to transformTheResult
  }
}

THIS IS PROBLEMATIC

Now we're coupling our code to an error message, which could change over time, not to mention increasing the difficulty in testing this section of code. There's now two branches here we need to test.

Any developer coming to this section of code to maintain it has to ensure that they take into account the differences in error messages to ensure the errors are handled appropriately.

3. I need to use `mutatedResult` for another action

Unsurprisingly you may have to use the result you get from a function that could throw to perform another action, similar to the code above where result was used to calculate mutatedResult.

Let's say you now need to call a new function updateModelViaApi(mutatedResult). Where do you put it?

Inside the try-catch after you calculate the mutated result?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
  const response = updateModelViaApi(mutatedResult)
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

Surely not. You're only putting it there because you need access to mutatedResult which is within the try scope. If you then had to perform more logic with the response object, would you also put that into the try block?

try {
  const result = performSomeLogic();
  const mutatedResult = transformTheResult(result);
  const response = updateModelViaApi(mutatedResult)

  if(response.status === 200) {
      letsDoSomethingElse();
  }
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

THIS IS PROBLEMATIC

Ok, our try block is continuing to grow, and going back to point 1, we are making it more and more difficult to understand what our try block is actually doing and further obscuring which function call we are expecting to throw. It also becomes much more difficult to test and more difficult to reason about in the future!

Could we not just move the variable outside the try scope? We could:

let mutatedResult;
try {
  const result = performSomeLogic();
  mutatedResult = transformTheResult(result);
} catch (error) {
  if (!production) {
    console.error(error);
  } else {
    errorMonitoringService.reportError(error);
  }
}

const response = updateModelViaApi(mutatedResult)

if (response.status === 200) {
  letsDoSomethingElse();
}

However, while this does reduce the amount of code in the try block, it still presents us with an issue of future maintainability, as well as a potential bug. We've declared a variable outside our try scope, without assigning it a value.

If an error is thrown before mutatedResult is set, execution will continue and our updateModelViaApi(mutatedResult) will be called with undefined, potentially causing another issue to debug and manage!

We see problems, but what's the solution? 🔥

To fully understand how to solve the problems presented, it's important to understand the goal of the try-catch syntax.

Try-catch allows the developer to execute throwable code in an environment where we can gracefully handle the error.

With this in mind, we have to understand that the implementation of this syntax by the language is essentially what creates these issues. If we look at the example above where we moved mutatedState outside the try scope, we solve an issue, but by doing this we break the functional programming concept of immutable state.

If we think of the try-catch block as a function, then we can see this breach of immutable state much clearer:

let mutatedResult;
tryCatch();
// expect mutatedState to now have a value
const response = updateModelViaApi(mutatedState);

However, by considering the try-catch block as a function, we can eliminate the problems we talked about earlier.

Having the try-catch logic moved into a function, we:

create a consistent pattern of running only the throwable code (Point 1)
can handle multiple throwable function calls and handle their individual errors explicitly (Point 2)
don't have to worry about block-scoped variables (Point 3)

So how do we transform the try-catch into a function?

Introducing no-try! 🚀

Luckily we don't have to. There is already a library that has done this for us.
NOTE: It should be noted this is a library I wrote

The library is called no-try and you can read more about it here. It will work in a browser environment as well as a node environment.

So what does no-try let us achieve?

Let's jump back to our first example and see if we can tackle the problem of Point 1 and refactor it to use no-try.

const { useTry } = require('no-try');
// You can also use 
// import { useTry } from 'no-try';

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
}

const mutatedResult = transformTheResult(result);

We can now see exactly which method we expect to throw an error, making it easier for any developer coming along afterwards to refactor this logic if they need to.

Admittedly, there's a slight cognitive load added to understand what useTry is, as it's not as immediately recognisable as a try-catch but from the naming and the usage, it should be pretty self-explanatory.

Can we also solve Point 2? Individually and explicitly handling errors thrown by multiple throwable function calls? Well, yes!

const { useTry } = require('no-try');

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
}

const [transformError, mutatedResult] = useTry(() => transformTheResult(result));

if (transformError) {
    notificationService.showError(transformError);
}

Now we can see that both methods may throw an error. We can handle both of these errors individually and without having to write code to figure out which error we're handling, reducing future maintenance.

Finally, tackling Point 3 should now be fairly straight forward. We don't have to worry about block-scoped variables or a try-catch block that's getting bigger and bigger as we need to execute business logic. If an error is thrown, we can exit the function before running code that might rely on a successful outcome:

const { useTry } = require('no-try');

const [error, result] = useTry(() => performSomeLogic());

if (error) {
    console.error(error);
    return;
}

const mutatedResult = transformTheResult(result);
const response = updateModelViaApi(mutatedState); 

if (response.status === 200) {
  letsDoSomethingElse();
}

This is much easier to reason about and it's straightforward to read. We can see what is expected to throw an error, where it is handled, and we aren't placing unnecessary code inside the try-catch block due to limitations presented by the language itself.

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)

Colum Ferry
JavaScript Developer and Enthusiast. Really enjoy working with Angular. Married with 2 amazing kids. Powered by Coffee.
@FerryColum @https://github.com/coly010

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

Making Seamless Page Transitions with the View Transitions API

Make Seamless Page Transitions using the View Transitions API Traditionally web applications have always had a less polished experience, both functionally and visually speaking, compared to native applications on mobile and other platforms. This has been improving over the years with the introduction of new web APIs and standards. One such new API that bridges that gap is the View Transitions API. What is the View Transitions API? The View Transitions API is a new browser feature that allows developers to more easily create animated transitions between pages and views, similar to how mobile apps have transitions when navigating between pages. Adding view transitions to your application can reduce the cognitive load on your users and make the experience feel less inconsistent. One great thing about view transitions is that they can be used by both SPAs (single-page applications) and MPAs (multi-page applications) alike! Using the View Transitions API for SPAs Let’s see how we can use view transitions ourselves. We will use examples adapted from demos created by the wonderful Jake Archibald and Bramus. There are some alterations to a few of the examples to make them work with the newest version of the View Transitions API, but otherwise, they’re mostly the same. The process of getting view transitions working for SPAs is as simple as calling document.startViewTransition right before starting navigation and replacing your page’s content immediately after that. You need to make this call in your router or in an event listener that triggers your page navigation. The following is an example of how you can hook into page navigation in a vanilla JavaScript application. This example uses the Navigation API if it’s available. As of the time of writing this article only Chromium-based browsers support the Navigation API, but there is a fallback to using a click listener on link elements so that this works with Firefox and Safari. ` If you’re using a framework, then there’s probably a better way to do this specific to that framework than by using this contrived example. For example, if you are implementing usage of this API with a Next application, you may opt for something like next-view-transitions. For this article, we’re going to focus on the way this is done in vanilla JavaScript so that the fundamentals of using the API are understood. Knowing how it’s implemented in vanilla JavaScript should give you enough understanding to implement this in the framework of your choice if there isn’t already a library that does it for you. Now we have a way to know when a navigation is being requested. Using the above utility function we can start the animation and replace our content as follows: ` getMyPageContentSomehow can be any function that returns HTML. How that is implemented will depend on your application and framework of choice. If you want to run these examples on your machine, the demo repository has instructions in its README. In essence, it’s as simple as hosting an HTTP server at the root of the project and visiting localhost. No fancy build system is required! By default, a fade is done that only lasts for a moment. The animation that happens can be configured using CSS with the ::view-transition-group pseudo-element on the element you want to animate, which in our case is the entire page, and we pass in root. ` Given that the animation properties are used, you have much control over what kind of animation to do. You can change the duration and the interpolation, add keyframes and gradients, and even add image masks. You can learn more about the animation properties in CSS on MDN. Using the View Transitions API for MPAs As mentioned, view transitions also work for MPAs with no client-side routing. Setting up view transitions for MPAs is much easier than for SPAs. All you have to do is include the CSS rule on all pages where you want the animations. ` Of course, like how it works with SPAs, you can customize the animations to your heart’s content using the view transition pseudo-elements. Conclusion I hope this article helped you understand the fundamentals of using the View Transitions API. Now that most browsers support it and it’s not too difficult to add it to existing applications, it is a great time to learn how to use it. You can view a full list of examples here (made by Jake Archibald and Bramus) if you want to see how advanced the animations can get. I like the Star Wars ones especially. The README explains how to get all the examples up and running (a total of 43!)....

Aug 2, 2024

4 mins

JavaScript

Migrating AngularJS to Angular

Introduction There is still a lot of confusion around Angular and AngularJS. It has gotten better, but searching for "Angular" still provides ambiguous results. This is a problem because AngularJS is on Long Term Support (LTS) mode. It entered LTS on July 1, 2018, for 3 years. It was granted a six-month extension due to COVID-19. Therefore, all support is expected to end on December 31, 2021, meaning Google will stop fixing bugs and providing support for AngularJS. All Angular engineering effort will be focused on the latest version of Angular making it prudent that active AngularJS codebases are migrated to Angular this year. This article will showcase different migration paths available to achieve this. Big Bang Rewrite By far, the easiest way to migrate a legacy codebase is to simply start fresh from the ground up. You won't have to worry about conflicting packages or supporting different versions of the same package. You would simply use the latest Angular CLI to scaffold out a new app and begin working on re-implementing your legacy app features with Angular. However, this is a significant engineering effort. This approach is excellent for very small AngularJS apps. However, it can also be possible for larger codebases. For larger codebases, you could set aside one or two developers to perform bug fixes and tackle production issues on the AngularJS app. You would inform customers that new features will be considered but will likely take some time to become available in the app. You would then concentrate the rest of your engineering effort on rewriting the app in Angular. This allows you to support your current app as it stands whilst reaching feature parity with the new Angular version of the app. UpgradeModule UpgradeModule is a tool provided by ngUpgrade by Angular to aid in the migration process. It allows you to run a hybrid application, mixing Angular and AngularJS apps. There is no emulation; it runs both frameworks at the same time. UpgradeModule provides us with two options on how we run our application. We can either run the AngularJS app and downgrade our Angular code into it, or we can run the Angular app and upgrade our AngularJS code into Angular. The Angular docs provide incredible documentation on setting up the hybrid application (you can read more here). We'll cover the basics here. Downgrading to run in AngularJS Generally, AngularJS apps can be bootstrapped using the ng-app directive such as: ` However, for ngUpgrade to take full effect you need to manually bootstrap AngularJS: ` The next step in running the latest Angular framework in the AngularJS context is to load the framework itself. This involves an outdated setup process where we need to use SystemJS to set up our Angular framework. The Angular framework no longer uses SystemJS by default for loading the framework; however, they have written a guide on how to do this here. We then set up Angular to provide it with a reference to the AngularJS App and more importantly, its Dependency Injector: $injector. ` Notice that this.upgrade.bootstrap has the same signature as angular.bootstrap. The final thing to do now is to bootstrap the Angular framework, which is done easily with one line: ` Now we can create new Angular components and downgrade them into AngularJS. Say we have an Angular component called HelloComponent. We use downgradeComponent provided by ngUpgrade to allow this component to be available to use in the AngularJS app: ` We can then use this in an AngularJS template: ` _Notice that the directive is registered in camelCase (helloWorld) but we use it in our HTML with kebab-case (hello-world)._ You're all set up to start migrating your components to Angular and downgrading them to be used in AngularJS. However, I like to think you'll agree that there is a lot of setting up here, and it leaves you with an Angular codebase that uses SystemJS to bootstrap and load your app. Upgrading to run in Angular We can take a different approach with ngUpgrade and UpgradeModule, however. We _could_ lazy load our AngularJS app into an Angular app that was scaffolded by the Angular CLI getting the full benefit of the build tools and leaving us with a codebase in line with the latest Angular. The Angular docs provide a great guide on setting up the Lazy Load Approach. It involves four things: 1. An Angular Service to lazy load AngularJS and bootstrap the AngularJS App 2. A file providing an entry point for AngularJS and the AngularJS App 3. An Angular Component to render the AngularJS app (a wrapper component) 4. Telling the Angular router when to route within the AngularJS app Once these are complete (the Angular docs really do explain this best), you can start creating new Angular components and downgrading them to be used in the AngularJS app similarly to how it was done in the previous section. You _also_ get the benefit of a more straightforward method to upgrade AngularJS services to be used within Angular: You create a factory provider and add it to the providers array of your Angular Module: ` This means you can focus on upgrading your AngularJS components first, then circling back to your services afterwards. This approach allows you to use all the modern Angular tools as well as providing you with an option of splitting up your AngularJS into smaller modules and only loading them as required. It also allows you to focus on upgrading smaller chunks of the AngularJS app at a time. Take a look at this folder structure for an example: You would store the relevant AngularJS code for the feature in the corresponding angularjs folder. This means your team can focus on one feature at a time without losing any functionality for your customers. Angular Elements Another approach that is gaining some popularity is to use Angular's Web Component solution, called Angular Elements. Angular Elements allows you to package up your Angular Component as a Web Component enabling it to be distributed and rendered in a plain old JavaScript context. This is awesome for migrating AngularJS codebases. It means we can create an Angular Component, bundle it as a Web Component and drop it into our AngularJS codebase with less set up than the ngUpgrade approach. This approach _does_ have some drawbacks. We need a good build pipeline that will bundle the Angular Components, make them available, and include them into the AngularJS codebase so that they can be loaded and used in this context. One approach to take that employs this would be to create two folders: one for your AngularJS codebase, one for your Angular codebase. You would keep your AngularJS codebase as is. All new work would occur in the Angular codebase. You can use the Angular CLI to scaffold out a monorepo. Each component you intend to upgrade would live in its own /projects folder (this is an Angular CLI workspace convention). To do this, you can run the command: ng generate application my-component Next, you need to add Angular Elements to your workspace: ng add @angular/elements --project=my-component This would create a folder and accompanying files at /projects/my-component. You would then create your component: ng generate component my-component --project=my-component This will scaffold out the component files you need. Once you have finished setting up your component, you need to use Angular Elements to convert it to a Web Component. Modify the app.module.ts at the root of /projects/my-component: ` When we build our app, we need to copy the output into a public folder in our AngularJS codebase. To build the elements file: ng build --prod --project=my-component This will produce output similar to: Notice that it created 4 files: 3 JavaScript files and one CSS file. They contain hashes to allow for cache-busting. However, it would also be worth bundling these together and naming them related to the component. We can do this with a simple node.js script (concat-elements-bundle.js): ` We can run this on the command line using node: node concat-elements-bundle.js This will output something similar to: my-component.bundle.1610106946217.js We then need to copy this to a scripts folder in our AngularJS and include it using a script tag in our index.html file: ` We can then use our component anywhere in our AngularJS app: ` This approach allows us to incrementally upgrade components to Angular, using Angular's modern tooling without changing our existing app's set up much. Once all components are upgraded, we have to place the components together in an Angular app, completing the migration. With a good CI Pipeline we _could _ automate the bundling and inclusion of the Angular Element in the AngularJS app, requiring even less work as the migration moves forward. Best Practice for Upgrading No matter the approach taken, one thing remains consistent between the two of them: how we tackle the migration. Consider our application to be a tree of components. The closer to the root of the tree, the more complex and usually more coupled the components are. As we move down the nodes in the tree, the components should get simpler and be coupled with fewer components. These components, the lowest hanging fruits, are ideal candidates for migrating to Angular first. We can migrate these components then use them in the AngularJS app where appropriate. Let's say we have an AngularJS TodoList Component which uses an AngularJS Todo Component. At this point, we can't really migrate the TodoList Component to Angular as we would have a dependency on the AngularJS Todo Component. We can migrate the Todo Component to Angular first and use it in the TodoList Component. This makes it easier to migrate the TodoList Component as its dependency on the Todo Component is already an Angular Component. We can use this approach when migrating legacy codebases. Start from the bottom and work our way up, and I would say this is the best approach. Conclusion With AngularJS losing support at the end of this year, it's worthwhile looking at migrating any legacy AngularJS codebases as soon as possible and figuring out a plan to do so. Hopefully, this article has illustrated the different options available for you to do this and helped provide an approach to tackling migrating the components in your codebase....

Jan 13, 2021

8 mins

AngularJavaScriptTypeScript

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.

Problematic Try-Catches in JavaScript

Problematic Try-Catches in JavaScript

So what's the problem? 🤔

1. Which method is throwing the error?

THIS IS PROBLEMATIC

2. What if both methods should throw?

THIS IS PROBLEMATIC

3. I need to use `mutatedResult` for another action

THIS IS PROBLEMATIC

We see problems, but what's the solution? 🔥

Introducing no-try! 🚀

Colum Ferry

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Making Seamless Page Transitions with the View Transitions API

Migrating AngularJS to Angular

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

Let's innovate together!

You might also like

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Making Seamless Page Transitions with the View Transitions API

Migrating AngularJS to Angular

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

Problematic Try-Catches in JavaScript

So what's the problem? 🤔

1. Which method is throwing the error?

THIS IS PROBLEMATIC

2. What if both methods should throw?

THIS IS PROBLEMATIC

3. I need to use mutatedResult for another action

THIS IS PROBLEMATIC

We see problems, but what's the solution? 🔥

Introducing no-try! 🚀

Colum Ferry

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Making Seamless Page Transitions with the View Transitions API

Migrating AngularJS to Angular

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

Let's innovate together!

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Making Seamless Page Transitions with the View Transitions API

Migrating AngularJS to Angular

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

3. I need to use `mutatedResult` for another action