Late last year a new OutSystems version was released, and with it came a new way of developing applications: it's called "Reactive Web Apps"! Because of this new so wanted feature, there was a change in the Runtime of OutSystems Applications and this brought an issue. The components developed and shared by the OutSystems Community on the Forge are now incompatible with this new feature. One of the components that are now missing is the FullCalendar2, which is used in many of our projects, so we took the leap and built it to share with the community!
(Screenshot from fullcalendar.io)
Before we started with the creation of this component, we had to acknowledge the big difference between two different ways of development. “Traditional Web Apps” build and render on the server-side before it is presented on the browser, while “ReactiveWeb Apps” render the page on the client/browser side.
On the “Traditional”, to execute one simple action of opening a popup when the user selects a date interval, we need it to dispute a request to the server so we can open it, while on “Reactive” everything is processed on the client-side without the need to wait for the answer of the server. This brings giant improvements and avoids several requests to the server.
In a nutshell, and accounting for the differences, with “Reactive” we can take advantage of interaction performance and execution of several actions because we don’t depend on the server to do it all.
There’s another point to consider which is the new ways and methods that this new version offers us (LifeCycle events and Client-actions) to develop and implement this component.
We based on the already existing FullCalendar2 component and reused some of the implementation methods of it. The first step is to update the framework from version 4.0.1 to 4.3.1. It is important to always have the most recent and stable versions because they can contain a lot of corrections and new functionalities.
After this, we step up to the construction of the component on “Reactive”. As referred before, this version introduced LifeCycle events in WebBlock (OnInitialize, OnReady, OnParametresChange, OnRender, and OnDestroy) as well as Client Actions. This allows us to have a better-structured code and subdivided, as the LifeCycle events, and also a higher performance regarding interactions with the framework from the Client-actions.
This component only uses two LifeCycle Events, OnInitialize and OnReady, where we make the conversion of the data structures to feed the calendar and to initialize the configured calendar, respectively.
Here is a simple and summarized structure of the steps taken so we can achieve our final result.
(FullCalendarReactive OnInitialize Action)
(FullCalendarReactive OnReady Action)
Another matter of this component is how we’ll be able to communicate and interact with it easily. We’ll need to have a set of events that will be triggered when the user interacts with the Calendar and some Client-actions to execute specific methods of the Calendar. Here’s the list:
We tried to go through all the main functionalities and necessities that help any developer develop, build, and customize a complete Calendar. After this, the component is complete and ready to be shared and used.
As with any other OutSystems component, the first step is to install the component from the Forge and reference it where it will be used. When it is referenced, we just need to search for it on the Widget Tool Search Bar for “FullCalendar” and drag it to the screen.
After these steps, it is easy to associate information to the Calendar. As an example, we’ll show a list of events developed by a Data Action. On the Input Parameter “Event Source” we just need to use the function NewEventSourceData() as a list of the type Event returned by the Data Action. One important note, on the Reactive Web Apps, since the information is loaded asynchronously, we shall have a condition that only loads the Calendar when the data is loaded.
As an alternative to this process, is to use NewEventSourceUrl() method. This method consists of associating one URL to the Calendar where it will retrieve information from the events. This process gives autonomy to the Calendar for it to fetch the information alone.
Lastly, we have AdvanceOptions where we can customize more advanced things based on the official documentation of the plugin.
Migrations/Conversions between Traditional and Reactive, a lot of times, can bring a lot of problems and make the transition difficult due to the paradigm change, Server-side to Client-side.
On this specific component, there were two, in my opinion, key-factors to the success of the conversion. The first one is the marvelous work and development of the component available in Forge for Traditional Apps, which is the one on the base of this component. The second one was the runtime of Reactive Web Apps (Client-side) because it allowed us to take more from the advantages of the platform.
In general, I think this component can offer mostly all the possibilities that the framework offers, while there’s always space to get better.