Reactivity is a core concept in modern web development, especially in the context of Single-Page Applications (SPAs). SPAs, such as those built with React, Vue.js, and Angular, aim to provide a seamless and responsive user experience by dynamically updating the UI in response to user interactions and data changes. In this article, we will explore reactivity in SPAs and how it relates to integrating third-party services like PayFields.
Reactivity in SPAs
Key Concepts of Reactivity in SPAs
Virtual DOM: React, for example, uses a Virtual DOM to represent the UI. When data changes, React compares the new Virtual DOM with the previous one to calculate the minimum number of changes needed to update the actual DOM.
Components: In React and Vue.js, UI elements are structured as components. Each component can have its own state and props (properties) and is responsible for rendering a part of the UI. When a component's state or props change, it re-renders itself.
Data Binding: Angular, on the other hand, uses two-way data binding. When data in the model changes, the view updates automatically, and vice versa.
Asynchronous Operations: SPAs often involve asynchronous operations, such as making API requests. These operations can trigger changes in the UI when responses are received.
Now, let's dive into how reactivity works with PayFields and why a
PayFields is a payment processing embedded solution that allows you to securely handle sensitive payment information, such as credit card numbers, within a web application. When integrating PayFields into an SPA, you want to ensure a smooth and secure user experience. However, PayFields operates independently and asynchronously, which can create challenges when it comes to reactivity.
PayFields loads its scripts and resources dynamically to enhance security. This means that the PayFields library might not be available immediately when an SPA loads.
PayFields uses iFrames to isolate and secure payment-related data. These iFrames need to be added to the DOM when the PayFields library is ready.
SPAs often expect immediate reactivity, but PayFields might not be ready instantly. This is why you see a
setTimeout in the PayFields Integration
Here's why it's necessary:
Script Loading: PayFields is loaded asynchronously from an external source (
<script src="<https://test-api.payrix.com/payFieldsScript>"></script>). The browser fetches this script, and it may take some time to download and execute.
iFrame Generation: PayFields generates the iFrames for payment fields within its library. These iFrames are inserted into the DOM. However, this process takes time, and the iFrames might not be available immediately after the script is loaded.
setTimeout function provides a delay of 1 second before you call
PayFields.addFields(). This delay allows the PayFields library to complete any internal initialization, including the generation and insertion of iFrames.
setTimeout function acts as a synchronization mechanism between an SPA and the PayFields library, allowing you to ensure that the payment field iFrames are ready for interaction. While this delay might seem like a workaround, it's a practical solution to handle the asynchronous nature of external services like PayFields within the context of SPAs, where immediate reactivity is expected.
setTimeout function is used to coordinate the timing of these operations to ensure proper reactivity and synchronization with PayFields.
Reactivity: By waiting for a short period, you ensure that when you call
PayFields.addFields(), the iFrames are present in the DOM and can be manipulated reactively by an SPA.
PayFields Reactivity Example
This line initializes the PayFields configuration by setting an empty string as the API key.
Like the API key, this sets an empty string as the Merchant ID. Replace it with the Merchant ID.
This sets the operating mode to
This sets the transaction amount to
Defining Payment Fields (
Several objects are defined within the PayFields.fields array. These objects specify the types of payment fields and the corresponding DOM elements where they should be rendered.
Card Expiration Date
Customizing Styles (
Styles for the payment fields are customized using the
PayFields.customizations.style object. The styles are defined for elements with the class
.input and elements with the class
.form-error. These styles control the appearance of the payment fields and error messages.
PayFields.customizations.style object stylization section formatting will function identically to CSS under the
Event Listener Script
An event listener is added to the
Another event listener is added to the
This sets a callback function to handle failure scenarios when interacting with PayFields. It logs the error to the console.
This sets a callback function to handle successful interactions with PayFields. It logs the response to the console.
setTimeout Example Function Explained
The script tag handles the configuration of PayFields, event handling, and callback functions, including customization of payment field styles and managing iFrames to ensure a smooth payment processing experience, while the
setTimeout function ensures proper reactivity of these operations and timing synchronization with PayFields.
In the example above, the
setTimeout function is used within the 'blur' event listener for a specific purpose:
After removing iFrames associated with payment fields, a timeout of 1000 milliseconds (1 second) is introduced using
This delay allows time for any asynchronous processes, like the creation and mounting of new iFrames by PayFields, to complete.
After the timeout, new payment fields are defined and
PayFields.addFields()is called to re-mount the iFrames.
This delay ensures that PayFields is given enough time to update and re-render the payment fields based on the modified data. Without this delay, there might be a rare condition where PayFields doesn't have enough time to update before the
addFields() function is called.