Hi everyone! I’m a beginner exploring Reactive Web Apps. I'm building a simple product list and need to format data (like currency strings).
Is it better to handle this logic in a Client Action after fetching data, or keep it within a Data Action on the server? I want to ensure my app stays fast and follows OutSystems best practices. Any advice for a learner?
Hi @harshita lalwani ,
if u want to format data, i prefer u handle this on client to reduce the complexity of the server request and avoid timeouts.
Note that the server is very fast, faster than the client, so although I agree with you on doing the formatting client-side, formatting server-side will very likely not lead to any time-outs.
as formatting is part of presentation, it naturally feels like a task for client, not server.
On the other hand, having extra pieces of logic, like an OnAfterFetch, is making code more complex, so I would draw the line at everything that can be done through a function. That way, you can handle the formatting in the expression that you place on your screen, by calling that function.
If it can't be a function, I would probably prefer to do in the DataAction or Aggregate, and only if that's not possible, add the extra OnAfterFetch logic.
Dorine
Hello,
I’d say it depends on the case itself. In OutSystems, you have some actions related to formatting, and as you can see in the screenshot, they are available on both sides: client-side and server-side. So both can be used depending on the business requirement.
A simple scenario: imagine a school management system showing students’ grades. On a teacher’s screen, the average grade for a class can be displayed and formatted instantly for review. For this quick display, rounding or formatting can be done on the client-side to make the numbers look clean. However, when calculating the official final grades that will be stored in the student records and used for transcripts, the averages must be calculated on the server-side for accuracy.
Another one: imagine you are building an e-commerce application that supports multiple currencies.
When the user switches from one currency to another , the prices are converted and formatted instantly on the screen. This is mainly for display purposes, so using the client-side action makes sense here because it provides a smooth and fast user experience without requiring a server call.
However, when the user proceeds to checkout and clicks “Place Order,” the application must recalculate the total amount using the official exchange rate stored in the system, apply taxes and discounts, handle proper rounding, and then save the final amount in the database. In this case, the logic should run on the server-side because it involves financial accuracy, business rules and security.
If we rely only on the client-side conversion (formatting), we may benefit from speed, but we risk security issues. The currency value calculated in the browser can be manipulated before being sent to the server, which may result in a different amount being stored in the database than the correct one.
Hi @Sherif El-Habibi ,
the question was only about formatting (i.e. making a string representation of a value).
Your examples about making correct calculations would/should be done with mathematics on server side, agreed, but that has very little to do with formatting. For example, the FormatCurrency function should not be part of that at all, not even the server side version.
Client Side
Faster user experience (no extra request to the server)
Reduces server load
Allows dynamic updates without reloading the page
Firstly, we need to understand why the format functions are built-in on both client and server side. Its due to the use purpose. There are some cases that server should handle the format such as:
Besides that, I recommend to do the presentation part on the presentation layer, which means client side
Hi,
Client side very help you to run you app and load screen faster.
Regards
Shradha Rawlani
That has nothing to do with the original question, please read the question before answering!
OutSystems follows a simple principle:
Use this for UI-only transformations, such as:
Formatting currency
Formatting dates
Display label adjustments
Converting enums to UI strings
Showing/hiding UI elements
Lightweight calculations that affect UI only
Why? Because client logic runs on the browser — no server call → fast & responsive UI.
Use this for business logic, such as:
Price calculations
Tax rules
Discounts Validations
Data transformations that will also be used elsewhere
Anything related to security or business consistency
Why? The server ensures consistency, reusability, and security.
For your product list:
Keep the Data Action simple
Just fetch database rows.
Do the currency formatting on the client
Use:
FormatCurrency()
or a small Client Action if combining multiple UI transformations.
Don’t put formatting in Server Actions
It causes:
unnecessary server load
duplicated logic
slower UI responsiveness
Hello @harshita lalwani
The best practice is to keep formatting on the UI (client side), not in the Data Action.
Data Actions should only fetch the data from the database. Things like currency formatting are only for display, so they should be done where the data is shown, using expressions like FormatCurrency().
Simple rule:-
Data Action = get data
UI = format and show data
That has been answered by many people days ago. Please read all the responses before replying, thanks.