This document is a work in progress and we invite you to send us your feedback.
This document is intended for experienced developers and leads as guidance in migrating Traditional Web Apps to Reactive Web Apps. The migration requires good knowledge of the new front-end features and knowledge of the application architecture. Check our training Becoming a Reactive Web Developer for an introduction.
Here are some of the 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.
Elements from Traditional not available in Reactive
Check the document Traditional to Reactive migration reference for a more detailed technical overview.
These are the elements commonly used in the Traditional Web that are not available in Reactive Web App. We also provide some general ideas on how you can get similar functionality in the new app.
Ajax Refresh in Traditional App refreshes parts of the interface. The UI elements in Reactive App refresh automatically on data change, so the Ajax Refresh is not needed.
The Entry node in Traditional Web defines the default page that loads in the UI Flow. It points to the index screen of the flow.
In Reactive App, right-click a Screen in the Elements Tree and select Mark as Default Screen to set the Screen as an "entry" point to a Module.
Notify and NotifyGetMessage enable Widgets in the Traditional Web to exchange data, and they are not available in Reactive Web.
In Reactive App you should use Events and corresponding handler Actions. You can 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. You can read more about is the migration reference document.
Preparation, a dedicated server-side Action that loads initial data for Screens, does not exist in the client-side Reactive interface. The absence of this Action points to one of the most significant differences you need to take care of: optimize which data is fetched by the front-end. We provide some guidelines in the section on how to migrate Preparation.
Session Variables are a server-side feature of the Traditional Web to store session information that can be accessed across the app. In Reactive Web App you should store information in Client Variables, which can initialize the On Application Ready System Event.
For details on how to migrate this element to Reactive, check the notes on migrating Session Variable.
Date Time in Reactive
Date and time in Reactive App are treated like in Mobile App. The Date Time values are always UTC, even when requested from the server. When you use them in the app UI, the values are converted to the local time of the device. You can read more about this in the Date Time documentation.
Improved practices in Reactive
These are general notes about the changes in how you approach development in the Reactive Apps when compared to Traditional Apps.
Optimize data fetching by the front end
Design how Aggregates of Reactive 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. You can 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 this type of module fits your use case.
Use client-side validation for quick feedback about values
Reactive App 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 are submitting. However, you are expected to implement your server-side validation to ensure the correct data is committed to the database.