Today I want to dive deeper in the internals of the Outsystems frontend interface. We will learn about React and how its mental models are affecting the way you develop.
Switch to client side
Under the hood
Since Reactive is built on React, it shares most of its concepts. I will name of few:
Page life cycle
Reactive follows the same life cycle stages when loading and interacting with a page. These life cycles are excellently explained here. You are able to define actions that are run after a lifecycle occurred. However, if you define an action for the wrong life cycle event, you may exactly slow down the loading of your page. Misunderstanding life cycles is one of the major mistakes I see with fellow developers. So stick with the purposes as defined in the Outsystems documentation.
Concurrent data retrieval
Immediate page updates
React uses a mechanism called VirtualDOM, where it compares what’s changed when a page is updated. Only the parts that have been changed are rendered. This avoids costly re-renders of your whole page. As a Outsystems developer moving from Traditional Web to Reactive, you will notice the absence of the Refresh node in actions. Due to Reacts client side rendering this is simple not needed anymore.
Events in web blocks
Outsystems follows the one-way data binding concept, like React. Simply put, it means that data in your interface flows from top to bottom. I won’t fully explain this topic, but the need for events in web blocks springs from this concept.
Becoming a better developer
Since Outsystems relies so much on React, understanding its concepts will help you become a better developer. It will help you understand why your code slows down loading of your page. Or why a hacker was able to retrieve a secret code that was stored in the code client side. And why you should use Aggregates instead of Data Actions. Understanding the bits and pieces under the hood will prevent you from developing bad habits.