We've been working on these documents. Please let us know how useful this new version is by voting.
This document presents some differences between the Traditional Web and Reactive Web Apps, in the context of migrating to the newer Reactive runtime. Refer to your Traditional apps and check how you implemented user experience and logic related to these new features, and assess what you need to change in the new runtime.
Traditional Web App elements not available for Reactive Web Apps
Check the document Traditional to Reactive migration reference for a detailed technical overview.
These are the elements commonly used in the Traditional Web that aren't available for Reactive Web Apps. These documents also provide some helpful tips on how you can get similar functionality in the new app.
Ajax Refresh in Traditional Web Apps refreshes parts of the interface. The UI elements in Reactive App refresh automatically on data change, so you don't need to use Ajax Refresh.
The Entry node in Traditional Web Apps defines the default page that loads in the UI Flow. It points to the index Screen of the flow.
Go to Entry Point to learn more about migrating Screen entry points.
Notify and NotifyGetMessage enable Widgets in the Traditional Web to exchange data, and they're not available in Reactive Web.
In Reactive Web Apps, use Events and corresponding handler Actions. Check how to do that in Use Events to Propagate Changes From a Block to the Parent.
You can catch exceptions on both the client and server side. Read more about is the flow exception handler reference.
Preparation, a dedicated server-side Action that loads initial data for Screens, doesn't exist in the client-side Reactive interface. The absence of the Preparation Action is an important difference between Traditional Web Apps and Reactive Web Apps. You need to recreate the data fetched on the client side. Refer to the Preparation section to read about the process.
Session Variables are a server-side feature of Traditional Web Apps to store session information that you can access across the app. In Reactive Web Apps, store information in Client Variables, which you can initialize the On Application Ready System Event.
For details on how to migrate this element to Reactive, check the notes on migration Session Variables.
Date Time in Reactive
Reactive Web Apps treat date and time values like Mobile Apps. The Date and Time values are always UTC, even when requested from the server. When you use them in the app UI, there's a value conversion to the local time of the device. Read more about this in the Date Time documentation.
Improved practices in Reactive
This section provides general notes about the changes in how you approach development in the Reactive Web Apps when compared to Traditional Apps.
Optimize data fetching on the client side
Design how Aggregates of a Reactive Web App should fetch data, by setting Aggregate Fetch property to
At Start or
Only On Demand. This provides a lot of flexibility for designing UI Patterns and speeds up the responsiveness of the UI. Check Implement asynchronous data fetching using Aggregates for an example.
Use Libraries for solid architecture
You can use Libraries to optimize the number of dependencies in the environment where the apps are running. You can also convert an existing Mobile or Reactive Module to a Library. Check the Libraries documentation to verify if this type of Module fits your use case.
Use client-side validation for quick feedback about values
Reactive Web Apps provides an efficient way to validate data on the client side. There's an example in Validate Form Inputs. The client-side validation is there for a quick feedback to your users about the values they're submitting. However, you should implement your server-side validation to make sure that the correct data gets saved in the database.
Continue to the Suggested stages of Traditional to Reactive App migration.
Documents in this section:
- Introduction into migrating Traditional Web to Reactive Web Apps
- Differences to consider between Traditional and Reactive
- Suggested stages of Traditional to Reactive App migration
- Traditional to Reactive App migration reference