Business Logic in React

In the context of software development, “business logic” refers to the code that represents the real-world rules that determine how data can be created, stored, and changed. But it’s not just about database management, it also includes the rules and processes which are specific to the business’s needs.

When it comes to a React application, or indeed any application, the business logic includes the code that manipulates the data and maintains the rules of the application. This can include:

Validations: For example, if you have a form on your React app, the business logic will include the checks to ensure that the email entered is in a valid format or that the password is of the required strength.
Data Transformations: If data is being retrieved from an external API and needs to be displayed in a specific way, the rules for transforming that data would be part of the business logic.
State Management: In a React application, how data flows through the components can be considered part of the business logic. This is because it involves managing the state of the application, deciding what triggers state changes and how components should react to those changes.

So, when I referred to “business logic” in the context of React, it doesn’t necessarily mean the logic tied to traditional businesses like logistics or accounting, but rather, the set of rules and data manipulations that govern how the application behaves, which can vary widely based on the unique requirements of your application or project.

It denotes the UI logic?

Not exactly. While UI logic could be a part of business logic, it’s not the entirety of it.

Business logic refers to the underlying processes that handle data exchange between a user interface (front-end) and a database (back-end). This includes data validation, computations, and the application’s general decision-making processes. It’s about ensuring data is correct, safe, and meaningful.

UI logic, on the other hand, is more about how the interface responds to user inputs: what happens when a user clicks a button, types into a form, or interacts with a dropdown menu? It’s concerned with presenting data from the business logic layer to the user and sending user inputs back to the business logic layer.

In a React application, for instance, UI logic could handle rendering components based on state changes, showing/hiding elements, changing styles dynamically, etc. So while UI logic is important, it’s only a part of the overall business logic of an application.

So in summary, business logic involves both UI logic and the processes that occur behind the scenes, including interactions with a server, database, or other back-end processes.

Interactions with the server or database is just a data source. There are no business objects in React. I am confused.

I apologize if my previous explanation caused any confusion. In the context of web applications, “business logic” usually refers to the rules and procedures that determine how data is transformed or manipulated.

In the case of React, a front-end library, the “business logic” typically involves processing data and user inputs, controlling application state, and determining how components should render and interact based on that state.

React itself does not interact directly with databases or servers – that’s usually handled by back-end services. However, in a typical React application, you may have functions that handle API calls to a server. The responses from these API calls could then be processed using business logic before being displayed by your components.

So in this context, when I refer to “business logic”, I’m referring to the code in a React application that dictates how the application behaves - how it processes data, handles user input, manages state, and controls rendering.

I hope that helps clarify things. If you have more questions, feel free to ask.

It is meant to be the “application logic” ?

Yes, that’s a good way to put it. The term “business logic” can sometimes cause confusion because it implies something specific to a particular business or industry. But in the context of software development, and particularly in the context of libraries like React, “business logic” often just refers to the core logic of the application – the rules and procedures that determine how the application behaves, processes data, and interacts with the user.

This is also referred to as “application logic”, as you’ve suggested. It’s the part of the code that’s usually unique to your specific application, as opposed to the more generic, reusable code provided by libraries or frameworks.

So in a React application, the “application logic” or “business logic” could include things like how the state is updated in response to user interactions, how data from an API is processed and stored in the state, and how that state data is used to determine what gets rendered on the screen.

Is logic defined by the business called business logic?

Yes, that’s correct. In a broader software development context, business logic (or domain logic) refers to the rules, algorithms, and procedures that capture the behavior, policies, and procedures specific to the business or industry that the software is designed to serve.

For example, if you’re building a banking software, the rules for calculating interest, the procedures for transferring funds between accounts, or the policies for verifying customer identity would all be part of the business logic. These are rules and procedures that are unique to the banking industry, and they’re usually defined or heavily influenced by the business stakeholders.

This business logic is implemented in the code, often in a way that separates it from the more generic, infrastructure-related code (like database access or UI rendering) so that it can be tested, modified, and understood independently.

So when you hear the term “business logic”, you can think of it as “the part of the code that implements the business’s unique rules and procedures”.

How does presentation layer library like React know about the business specific logic? It is used only in the view layer of the web application.

That’s a great point. React is a library primarily concerned with the view layer in a web application, but it doesn’t inherently know about business-specific logic. However, it provides a way to structure your UI and manage the state of your application’s UI, which often needs to be shaped and informed by the underlying business logic.

The way React becomes aware of business logic is through the developers using it. Developers can integrate business logic into their React components through a variety of techniques:

Props: Developers can pass data or functions (which might encapsulate some business logic) into React components via props.
State: Components can have internal state which may be managed in a way that respects the business rules.
Context: React’s Context API can be used to share values (like business data or logic) across a tree of React components without having to explicitly pass props down through every level.
Hooks: Custom React Hooks can be created to abstract business logic. These hooks can then be used inside multiple components, promoting reusability and separation of concerns.
External state management libraries: Libraries like Redux, MobX, Zustand, etc. can be used to manage complex state logic outside of React components, but still used inside components when needed.

In short, while React itself doesn’t understand or care about your business logic, it provides tools and conventions that allow developers to weave that logic into their components and state management strategies as needed. It’s up to the developers to write and structure their code in such a way that the business logic is correctly implemented and integrated with the UI.

The business logic can change and it must be separated from the UI logic. This makes maintenance easier. How is that accomplished in React?

You’re absolutely correct. It’s a common and beneficial practice to separate business logic from UI logic. This allows for code reusability and easier maintenance. Here’s how you can do it in React:

Custom Hooks: Custom Hooks provide a great way to encapsulate business logic and separate it from the UI components. This makes it possible to reuse logic across different components and test it separately.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
function useBusinessLogic() {
  const [data, setData] = useState(null);
  
  useEffect(() => {
    async function fetchData() {
      const response = await fetch('/api/data');
      const data = await response.json();
      setData(data);
    }
    
    fetchData();
  }, []);
  
  return data;
}

function MyComponent() {
  const data = useBusinessLogic();

  return (
    <div>
      {/* ... */}
    </div>
  );
}

Higher-Order Components (HOCs): These are functions that take a component and return a new component with additional props or behavior. They can be used to encapsulate business logic.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
function withBusinessLogic(Component) {
  return function EnhancedComponent(props) {
    // business logic here
    const newData = // ...
  
    return <Component {...props} data={newData} />;
  };
}

const MyComponentWithBusinessLogic = withBusinessLogic(MyComponent);

Context API: React’s Context API allows for sharing data (which might include business logic) without having to pass props down manually at every level. This can be combined with the useReducer hook for more complex state management that involves business rules.
Redux/MobX/Other state management libraries: These libraries can help you manage complex state logic outside of React components, and are often used to handle business logic that affects multiple components throughout an application.

No matter which method you choose, the goal is to separate concerns, promote code reusability, and make the code easier to maintain and understand.

Backend Business Logic

The backend has a domain model that captures the business logic. Does react map directly to the domain model in the backend?

The relationship between a React application (front-end) and a domain model in the back-end isn’t a direct one-to-one mapping, but rather a layered approach. The front-end UI and the back-end business logic are separated by design in most modern web architectures.

Here’s a simplified overview of how the relationship works:

Backend Domain Model: This model represents the business logic of your application. It includes the rules, constraints, and processes that your business requires. This could involve user authentication, data validation, database operations, calculations, etc.
APIs: APIs provide the link between the front-end and the back-end. They allow your React application to interact with your backend services. RESTful APIs are the most common, but there are also other types such as GraphQL.
React Components: React components are the building blocks of your user interface. They do not map directly to your backend domain models, but they interact with them through APIs.

In other words, React components are used to present information and provide interactive functionality in the user interface. These components make requests to the backend through APIs and use the responses to update the UI.

But it’s important to note that a React component doesn’t necessarily have a direct counterpart in the backend domain model. The structure of a React application is often based more on user interface and experience needs rather than backend domain models. For example, you may have a React component just to handle a navigation menu, which doesn’t correlate to a specific part of your domain model.

The state management in React (whether using local state, Context, Redux, etc.) can be thought of as a sort of “client-side domain model” as it models the state needed on the client side, but it’s not necessarily a mirror of the backend domain model. Its main purpose is to handle UI state for the user’s current session.

In conclusion, while React components interact with the backend domain model, the relationship is more of communication through APIs, not a direct mapping.

When the business logic is stored in the backend what is the need to express business logic in the frontend?

The primary business logic of an application should indeed be stored in the backend for reasons related to security, integrity, and centralization of business rules. However, there are valid reasons to have a certain level of business logic in the frontend as well. Here’s why:

User Experience: Implementing some level of business logic on the frontend can drastically improve the user experience. For instance, form validations are a type of business logic that can be executed on the frontend. By providing immediate feedback to the user (e.g., “password is too short”), we can prevent unnecessary network requests and create a smoother user experience.
Performance: Running some logic on the frontend can reduce the load on your server and decrease network traffic, which can lead to performance improvements. For example, we might have logic in the frontend to filter or sort a list of items without needing to make additional requests to the backend.
State Management: Frontend applications need to manage state, which often involves implementing business rules. For example, a shopping cart in an e-commerce app may need to enforce a rule that only one instance of a particular item can be added, or that certain discounts apply when specific conditions are met.
Decoupling: While the backend might hold the master business logic, having some mirrored in the frontend can help keep the UI responsive and less tightly coupled to the backend. For example, in a single page application, the frontend may use its own logic to decide which components to show or hide based on user interactions, without needing to communicate with the backend for each decision.

So while the “core” business logic usually resides in the backend, a degree of business logic is often necessary in the frontend to improve user experience, performance, and maintainability. This also helps in building applications that are resilient and can handle situations where the backend services might be slow or unavailable.

Password is short is not a business specific rule. They are applicable to any business and any domains.

You’re correct in stating that a rule such as “password is too short” isn’t necessarily business-specific and can be applicable to many domains. It’s more accurately described as a security measure or a part of user input validation, rather than business logic.

The point I wanted to illustrate, however, is that frontend logic isn’t strictly limited to displaying data received from the backend. It can, and often does, include rules and validations that enhance user experience and maintain the integrity of the application on the client side.

As for an example of business-specific rules on the frontend, consider an e-commerce platform. One of its business rules might be that customers are allowed to apply only one discount code per order. Even though the final validation of this rule will happen on the server (when the order is placed), it’s beneficial to enforce this rule on the frontend as well, preventing the user from entering multiple discount codes and expecting a cumulative discount.

To conclude, the frontend doesn’t generally deal with core business logic (which should be secured and centralized on the server), but it can have a level of domain or business-specific logic to provide immediate feedback, enhance user experience, and improve performance.

Do you think all the business logic executed in a stored procedure in a database will be expressed in the frontend code?

No, typically, all business logic that resides in a stored procedure in a database would not be directly expressed in frontend code.

There are several reasons for this:

Security: Many business rules rely on sensitive data that should not be exposed to the frontend. For example, pricing rules might take into account confidential discount rates, or access rules might consider a user’s security clearance level.
Performance: Executing business logic on the server side (in stored procedures, for example) can be much more performant, especially when dealing with large amounts of data. The server can execute logic and then send a much smaller, final result to the client.
Data integrity: By keeping the business logic on the server side, you can ensure that all clients (not just web, but also mobile apps, third-party integrations, etc.) follow the same rules. This helps maintain data integrity.

However, a simplified or partial version of some business logic may be implemented on the frontend to improve user experience. For example, if a business rule dictates that a customer can’t order more than 10 of the same item, a frontend check could prevent the user from adding more than 10 to their cart, giving them immediate feedback and saving a round trip to the server.

In summary, while the frontend can reflect some aspects of the business rules for a better user experience, it doesn’t replicate the complete set of business logic from the backend. It’s important to maintain a clear boundary and understand that ultimate authority rests with the server-side logic.