We’re proud to announce a whole new way of building highly performant and scalable applications. 

Using client-side development and a single codebase, you can create rich and engaging interfaces with a new type of web application that consolidates the development experience across mobile and web.


A revolutionary way of creating web applications

Reactive web apps give you the best of mobile apps with improvements that make creating web and mobile apps a lot easier. We’ll go into these them further ahead, but first here’s what we’ve brought from mobile to web.


Performance improvements

All UI elements in reactive web apps update immediately when the data they are bound to changes, instantly changing the interface. No more need to use Ajax Refresh; the apps are smart enough to understand what needs to be changed.


Client-side logic

In reactive web apps, all client-side logic can be visually modeled. Hard-to-maintain JavaScript will be a thing of the past. You can use the same logic construct across client and server actions. You have the full flexibility to create any kind of business logic. For client actions in the browser, calling server-side logic is just a drag-and-drop away. OutSystems generates and secures REST APIs behind the scenes to support communication between browser and server, using only the minimum network bandwidth required for the actual data transfer.


Responsiveness

Asynchronism in server communication keeps your apps always responsive. For example, while an app is executing a server-side action, it continues to run and respond to user input in the browser.


Scalability

OutSystems warns you whenever you accidentally create some scalability anti-pattern. For example, when you call a server action inside a loop, do something that might delay screen rendering, or sequentially call server actions, OutSystems suggests alternatives for the best performance of your apps.


A state-of-the-art runtime architecture

Reactive web apps use a modern runtime architecture built on industry standards and best practices taken to the limit. Most code and resources are cached in the browser, eliminating the communication overhead for the majority of user interactions. The UI is rendered in the client-side. All screens, blocks, and widgets are generated as reusable React components. Secure and fast REST APIs to handle communication are automatically generated from the actions defined in the IDE.


Data fetching

Instead of using Preparation, you’ll find screen data directly below the screen. Screen data is composed of aggregates, data actions, and variables. Aggregates provide easy access to entities’ data, while data actions can be used for more advanced cases, like fetching data from external services. All these are executed asynchronously and in parallel. This will improve your app’s UX, since there is no need to wait for all data to arrive before starting to display the page.


New capabilities introduced with Reactive Web

A Unified OutSystems UI framework

OutSystems UI Mobile is now called OutSystems UI. This is a big update to support the development of reactive web and mobile applications, a single UI framework for all your apps!

See more about the new framework in the OutSystems UI website.


Screen Aggregates and Data Actions scope improvements

We made data fetching straightforward to use in mobile and reactive web apps. Screen Aggregates and Data Actions are now available in the scope of other Screen Aggregates and Data Actions. For example, dropdowns that depend on other dropdowns’ selected values? No problem! Now you will be able to filter any aggregate using the results of another one. The platform will automatically understand the order in which these requests need to be done.


Fetch on Demand

We also added the Fetch property with On Start and On Demand options to Screen Aggregates and Data Actions. Now you can implement patterns such as master/detail with an excellent performance and user experience.


Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.


Default Buttons

Button widgets in mobile and reactive web apps now have the Is Form Default property, which you can set to Yes and have the App submit the data from the related form when the end-user presses the Enter key.


Table widget with simple Sorting

A new Table Widget comes with an accelerator: drag an Entity to it to create a table with sorting and pagination. Use tables to show data in cells distributed in rows and columns.


Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.


Native Dropdown widget

The Dropdown Widget has a new property Options Content, which you can set to Text Only or Custom. Text Only gives a native look and feel of the dropdown lists in your reactive we and mobile apps. Set Options Content property to Custom to build a dropdown with a list of images or other widgets.


Download files

You can drag a Download Tool logic node to your Flow and create a node which, when executed, sends a file for download to the end-user.


New Library module type

Start building great applications with a solid architecture, right from the very start. Take advantage of the new Library module, that guides you through the process of laying down the building blocks of your application. Libraries can be used in both reactive and mobile apps.


Reactive in the Forge

In the Forge, you’ll have a new filter for the type of component “Reactive”. These share most of the same underlying technology as the mobile ones so, if you find a mobile component (not requiring native capabilities) that you would like to use in your apps, it is possible to convert it to a reactive component. With the help of the community, we expect the list of available reactive components to grow pretty fast.


Optimized Network Payloads

We improved the efficiency of the data exchange between the server and client-side for reactive web apps, by ensuring the client-side receives only the data it really needs. This is another step in making reactive web apps that focus on client-side development paradigm, even faster and snappier.


Reuse Logic and Data

If you have existing traditional web applications you’ll be able to reuse their entities and server actions. All your backend logic, data, and services can be leveraged across all channels.


Create awesome experiences for your users

It all boils down to what can you do for your users. You have to experience these new apps to understand how users delight in smooth transitions and fast response times. And all of this without JavaScript, only with easy-to-change visual low-code.

This is quite a revolution, and there is a lot more we intend to do with Reactive Web, but your help is crucial.

Please share your feedback by replying to this post. The good and the bad alike. We’re here to learn and evolve with you.

Great news, let's dig in and start learning how to do it.

I've been waiting for this one! Can't wait to build my first reactive web app!

I also cannot wait.  I hope there will be a guided path for it or replaced the current guided paths 

Roelof Wobben wrote:

I also cannot wait.  I hope there will be a guided path for it or replaced the current guided paths 

Here it is https://www.outsystems.com/learn/paths/18/becoming-a-reactive-web-developer/

Thanks,  I have to wait till my personal enviroment is upgraded so I opened a support case for it. 

Roelof Wobben wrote:

Thanks,  I have to wait till my personal enviroment is upgraded so I opened a support case for it. 

No need to wait!

Goto the platform page and press the button to upgrade your platform.

And then of course install the latest studio version. You need to update also the OutSystems UI related components in your environment.

Did it al yesterday and made my first reactive web app.


Which page do you mean with the platform page ? 


Been waiting this for so long! Awesome job guys! 

Finally!! :D 

An important step towards bringing mobile and web app development closer together! Congrats guys!

Congrats! Exciting times!

This is incredible, exciting news!

Awesome! Great news!

I am really impressed with Outsystems's evolution. This will really make things a lot easier for us developers, and help us provide a better experience for our clients.

Congrats for the Outsystems Developers Team, this is quite an advance. Keep up with the good work.

Great news! Congrats! 

Congrats. Doing the guided paths right now and found no wierd things.

Great, can't wait to play with these new tools

I just finished the upgrade... 

I can't wait to do the course.


Anyone already trying stuff ?

I'd love to hear.

It is like OutSystems Mobile, without local storage, without offfline support and a new concept called client parameters which is the client side equivelant of session parameters.

Daniël Kuhlmann wrote:

It is like OutSystems Mobile, without local storage, without offfline support and a new concept called client parameters which is the client side equivelant of session parameters.

Hi Daniël,

That is a good summary. There are several other improvements, but 2 small things I think will make a big change is the "Screen Aggregates scope improvements" and "Fetch on Demand". Together with client variables, we expect screen and block lifecycle events (OnInitialize, etc...) to be much less needed and development to be a lot more straightforward.

Cheers,
Tiago Simões


This was the expected roadmap. Great News.

Can we also create/add our own custom ReactJS component or existing npm ReactJS components?

Jovvy B wrote:

Can we also create/add our own custom ReactJS component or existing npm ReactJS components?

Hi Jovvy,

Yes. But personally I would always try to find an existing forge component (it’s easy to convert the mobile ones) or use client actions. Client actions are compiled to JavaScript and they are easier to change. If neither is an option I would try to use plain JavaScript in a library. Only if none of those make sense I would use ReactJS. In that case you will need to include a script with React and ReactDom. I’ll try to upload a sample in the future.

Cheers,

Tiago Simões
 


Hi Tiago,

By the way, what relation these Reactive Web Apps (RWAs) have with the hype around Progressive Web Apps (PWAs)?

https://www.outsystems.com/blog/posts/progressive-web-apps-pwa/

Is this a starting point for OutSysytems to support full PWAs in the future?

Cheers,

João

João Costa wrote:

Hi Tiago,

By the way, what relation these Reactive Web Apps (RWAs) have with the hype around Progressive Web Apps (PWAs)?

https://www.outsystems.com/blog/posts/progressive-web-apps-pwa/

Is this a starting point for OutSysytems to support full PWAs in the future?

Cheers,

João


Hi João,

Seems like a starting point. Quote from "Announcing New Capabilities to Fuel Your Digital Customer Experience Transformation" article - "We’re making PWAs generally available in January 2020, which means all OutSystems customers will be able to deploy any Reactive Web Application as a PWA with just a few clicks."

Cheers,

Prakash Periakaruppan

Wow... "Fetch on Demand". A very nice feature.

Cool features... This is clearly evident that how Outsystems is transforming to next gen development....

Great news.

Congrats.

Prakash Periakaruppan wrote:

João Costa wrote:

Hi Tiago,

By the way, what relation these Reactive Web Apps (RWAs) have with the hype around Progressive Web Apps (PWAs)?

https://www.outsystems.com/blog/posts/progressive-web-apps-pwa/

Is this a starting point for OutSysytems to support full PWAs in the future?

Cheers,

João


Hi João,

Seems like a starting point. Quote from "Announcing New Capabilities to Fuel Your Digital Customer Experience Transformation" article - "We’re making PWAs generally available in January 2020, which means all OutSystems customers will be able to deploy any Reactive Web Application as a PWA with just a few clicks."

Cheers,

Prakash Periakaruppan

Thanks for sharing!


It's a great improvement!! I can't wait to "reactive" my apps :D

So far I have made a short test in my personal enviroment, and, althougth it's a great advance, I see some little disadvantages regarding classic web apps:

- Locale is not persisted between calls to server actions (there is an idea submited for this: LINK), so, we should set locale in each call to server actions in which we retried some translated text (literals, static tables, etc)
- There is no multilingual resources like classic web apps. So I suppose we should translate apps like classic mobile apps (translating literales one by one, creating a json resources, and using multilingual component), which is much more complicated
- There is no server session properties. There is a new client side properties (what is great!) but in some scenarios are useful to have server side properties. And, with the new reactive apps, values are not preserved between calls (like locale set)
- The patterns are the same that mobile patterns. This is great, and has sense to have common components (the new "libraries"), but there are some "classic web" patterns missing, like editable tables, radio buttons, etc...
- I have no make several test, but seems there is no easy way to migrate classic web apps to reactive apps. I have test to copy things from classic web apps to reactive web apps, and nothing can by copied, not even one container. So I believe that we should recode full apps, shouldn't we?

In any case I think it is a great step to improve the classic web applications, which were already a bit outdated. Thanks for work guys!

Hi Carlos,

Instead of session variables you have client variables  which you could also use to store the locale. You could do this in the OnApplicationReady Client system event.

Regards,

Daniel

Daniël Kuhlmann wrote:

Hi Carlos,

Instead of session variables you have client variables  which you could also use to store the locale. You could do this in the OnApplicationReady Client system event.

Regards,

Daniel

Right. BTW, in the next server version, that should be out in a few weeks, you'll also be able to read client variables in screen aggregates and screen data actions.


Carlos Olías wrote:

It's a great improvement!! I can't wait to "reactive" my apps :D

So far I have made a short test in my personal enviroment, and, althougth it's a great advance, I see some little disadvantages regarding classic web apps:

- Locale is not persisted between calls to server actions (there is an idea submited for this: LINK), so, we should set locale in each call to server actions in which we retried some translated text (literals, static tables, etc)
- There is no multilingual resources like classic web apps. So I suppose we should translate apps like classic mobile apps (translating literales one by one, creating a json resources, and using multilingual component), which is much more complicated
- There is no server session properties. There is a new client side properties (what is great!) but in some scenarios are useful to have server side properties. And, with the new reactive apps, values are not preserved between calls (like locale set)
- The patterns are the same that mobile patterns. This is great, and has sense to have common components (the new "libraries"), but there are some "classic web" patterns missing, like editable tables, radio buttons, etc...
- I have no make several test, but seems there is no easy way to migrate classic web apps to reactive apps. I have test to copy things from classic web apps to reactive web apps, and nothing can by copied, not even one container. So I believe that we should recode full apps, shouldn't we?

In any case I think it is a great step to improve the classic web applications, which were already a bit outdated. Thanks for work guys!

I've answered regarding locale and session variables in the post above (good news: client variables will be able to be read on screen aggregates and data actions soon).

Regarding multilingual, you are right, this is similar to mobile. We might improve this in the future.

As for patterns, we tend to continue evolving based on feedback.

As for migrating traditional web apps, there is no magic conversion available, the models are just too different for any conversion to be any good. This being said, you can reuse server logic and data. We plan to share some guidelines for migration in the future, but again there will always be effort involved.

Thanks for all your feedback and keep it coming.


Hi Taigo and Danië, thanks for answers, really!! :D

 About persist locale, It does not work just by reading the client side properties on the server side (which would be helpful!). If you take a look the IDEA posted in outsystems forums (LINK), the problem is locale is not persisted (as they do other things like tenantId or UserId) between servers calls when you call from mobile side or reactive app. 

This is a big problem when you have a Core Module, that returns literals or have static tables and both have translations resources. Image a multilingual app, and a French user (for example): as the "locale" does not persist, you need to pass a parameter with the locale that you want (fr-Fr, or, in the future, read client side variable in server side, as you told) and make a "SetCurrentLocale" each time you need to call a server action (and this server action returns translatable things). 

And this is also a problem with an aggregate in client side window that join an static table that are in a core module and have translations, because you are not able to "set server side locale" before executed and always is return the "labels" in the default platform language; the only workarround I have found is tranform in fetch data and set locale first. 

All this it is better explained in the idea, even with a demo project... The usual case would be that when a user chose the language or logged in, if he set the language, you call to an server action to make a SetCurrentLocale and this persisted during the session between all calls to server side... I really hope that in the near future the locale that is set in a server action persists, as it does when perform a switch tenant, for example.


Anyway, as I said, this evolution in web applications with Reactive Apps is excinting, so thank you very much for that :-)

Got it, you are right. I’ve changed the status of your idea to “on our radar”, so we can keep an eye on it. Thanks. 

Regarding the new client side variables

I remember that it was a bad practice use a lot session variables (or populate with bigger content) because this was stored in datebase and loaded in each page load, will you use them or not.

Now, with the new client side variables, we should try not to abuse them like old session variables? or its use is much more optimal because are client side variables?

And, a question regarding the functionality you mentioned that will arrive shortly, that we would use the client variables on the server side: this means that are going to be send it in each call to server side? and this means that we should use them with caution because could impact in performance if we assign big data in them? Or may be they will have some kind of optimizations to avoid bad performance send in each call?


Regards,
Carlos

Carlos Olías wrote:

Regarding the new client side variables

I remember that it was a bad practice use a lot session variables (or populate with bigger content) because this was stored in datebase and loaded in each page load, will you use them or not.

Now, with the new client side variables, we should try not to abuse them like old session variables? or its use is much more optimal because are client side variables?

And, a question regarding the functionality you mentioned that will arrive shortly, that we would use the client variables on the server side: this means that are going to be send it in each call to server side? and this means that we should use them with caution because could impact in performance if we assign big data in them? Or may be they will have some kind of optimizations to avoid bad performance send in each call?


Regards,
Carlos

Hi Carlos,

Because they are stored on the browser they are a lot leaner than session variables. The data transfer between client and server was dramatically optimized, so you do not need to worry about using them. 

Cheers,

Tiago Simöes



WoW!!

Very exciting! I am particularly interested in the removal of Ajax refresh. Can't wait to get my hands dirty...

Great news, can't wait to try out!

Really cool!

Another two questions about the Reactive apps:

- There is any reason to not have local storage in new libraries modules?Are they expected to be in the future?

- I have observed that there are no entry points in Reactive Apps. When I need to call from one end user module to page of another end-user module I use entry points with GetEntryURL to avoid coupling between modules (4 layers canvas rules, avoid calls between end-users modules)... What should be the mechanism now to do this without entry modules?


Again, thank you so much ;-)

Carlos Olías wrote:

Really cool!

Another two questions about the Reactive apps:

- There is any reason to not have local storage in new libraries modules?Are they expected to be in the future?

- I have observed that there are no entry points in Reactive Apps. When I need to call from one end user module to page of another end-user module I use entry points with GetEntryURL to avoid coupling between modules (4 layers canvas rules, avoid calls between end-users modules)... What should be the mechanism now to do this without entry modules?


Again, thank you so much ;-)

- Making localstorage work in all browsers is a challenge. We'll see what we can do. In any case, for web apps I would stay away from offline storage and the complexities of syncing data. As for libraries check if using client variables is an option.

- Public screens are now weak references since 11. This means that you can (and should) use public screens instead of external site redirections, as publishing a producer does not imply you need to republish the consumer, if weak references is all you got.


This deserves a standing ovation! A very welcome innovation. Well done !

Is there a possibility to upgrade classic web to react?


Martin Den Braven wrote:

Is there a possibility to upgrade classic web to react?


Hi Martin,

You can reuse server logic and data. As for the interface, we've explored several options, but bottom line there is no magic conversion available, the models are just too different for any conversion to be any good. We plan to share some guidelines for migration in the future, but there will always be effort involved. If your apps were already using OutSystems UI Web and their screen templates (released in 11) the effort will be smaller.

Cheers,
Tiago Simões


Being a Beginner, I'd like to know if this Reactive Web Application capable of producing both Web and Mobile App at the same time, So that it reduces the time we spend to create for web and mobile individually..

Aswin Parthiban wrote:

Being a Beginner, I'd like to know if this Reactive Web Application capable of producing both Web and Mobile App at the same time, So that it reduces the time we spend to create for web and mobile individually..

Hi Aswin,

You still need to choose your type of application, so i don't think you can create mobile app and web application at once. 

This would be strange since you need to create different screens/widgets due to screen space differences.

However: The logic of both type of application can be shared.


It could however be less work now both applications are based on React.



Aswin Parthiban wrote:

Being a Beginner, I'd like to know if this Reactive Web Application capable of producing both Web and Mobile App at the same time, So that it reduces the time we spend to create for web and mobile individually..

Hi Aswin,

Reactive web app blocks can be reused in mobile apps. The only features that you can't use in reactive from mobile are the ones related with offline data storage and native capabilities. It's also possible to convert from mobile to reactive and libraries (that can be reused from both models). The reactive web app template also uses responsive techniques to make sure it renders well in smartphones and tablets.

What you are asking was really one of the goals with this, to make reusing interfaces between web and mobile a lot easier.

So, as a beginner I would strongly encourage you to create reactive web apps instead of the traditional ones.

Cheers,
Tiago Simões


Stefano Valente wrote:

Aswin Parthiban wrote:

Being a Beginner, I'd like to know if this Reactive Web Application capable of producing both Web and Mobile App at the same time, So that it reduces the time we spend to create for web and mobile individually..

Hi Aswin,

You still need to choose your type of application, so i don't think you can create mobile app and web application at once. 

This would be strange since you need to create different screens/widgets due to screen space differences.

However: The logic of both type of application can be shared.


It could however be less work now both applications are based on React.



As the components and patters now are the same, I suppose you can create pages in  new "libraries" modules inside a webblock, and use them in both applications... Has some considerations, such as that reactive applications do not have local storage, and mobile app do, so libraries don't have local storage and you should pass througth parameters al the data handle by page, but, in essence, you can save a lot of time making common parts...


Carlos,

Just tried that: Get a public webblock from a reactive web app and use it in a phone app. This actually works!


Thank you for pointing that out to us.

Tiago Simões wrote:

Carlos Olías wrote:

....

...

- Public screens are now weak references since 11. This means that you can (and should) use public screens instead of external site redirections, as publishing a producer does not imply you need to republish the consumer, if weak references is all you got.


Two questions about the old entry points and the new reactive apps (the last ones, I promise!! hehe):


  • I have read carefully the article of what is consider weak reference, and maybe I'm mixing concept of "couple" referece, and strong/weak reference. I'm explain my self:

    I have read that now screens references are weak, but imagine the following scene: you have aplication A (AppA), and application B (AppB). Both are in production, and you want to have different life cicles. AppA calls to a AppB page. Now, you need to add a mandatory input parameter in the AppB page, so AppA is inconsistent until you fix it and add a value in the new parameter. If I want deploy to Produccion only AppB, LifeTime is going to tell you "ey! you should also upload AppA, if not AppA is going to be inconsistent in Production", it's not like that?

    So, references between pages in different modules or applications are creating me a "couple" between modules that I could avoid with entry points and "GetEntryURL" function... I don't know if this is an strong o weak refference, but... how we should procced now, without entry points in reactive apps to call others pages and not have a dependence in this situations?

  • The other thing for which I use entry points is for avoid ciclic references creating a shared menu webblock used in several end-users modules of same application. Look this diagram:

    In some application, I have 3 end-users modules, that use the same menu webblock in theme (so have a reference with theme module). And menu webblock in theme module need to point to the pages accesed from menu... so we create ciclic references. With old entry points and GetEntryURL function we could avoid ciclic references, but now, without entry points, how we should proceed?


Sorry for the amount of questions, I'm trying to see all the migration aspects of the old classic web apps to the new hot-reactive-apps  :-D


Carlos.

Carlos Olías wrote:

Tiago Simões wrote:

Carlos Olías wrote:

....

...

- Public screens are now weak references since 11. This means that you can (and should) use public screens instead of external site redirections, as publishing a producer does not imply you need to republish the consumer, if weak references is all you got.


Two questions about the old entry points and the new reactive apps (the last ones, I promise!! hehe):


  • I have read carefully the article of what is consider weak reference, and maybe I'm mixing concept of "couple" referece, and strong/weak reference. I'm explain my self:

    I have read that now screens references are weak, but imagine the following scene: you have aplication A (AppA), and application B (AppB). Both are in production, and you want to have different life cicles. AppA calls to a AppB page. Now, you need to add a mandatory input parameter in the AppB page, so AppA is inconsistent until you fix it and add a value in the new parameter. If I want deploy to Produccion only AppB, LifeTime is going to tell you "ey! you should also upload AppA, if not AppA is going to be inconsistent in Production", it's not like that?

    So, references between pages in different modules or applications are creating me a "couple" between modules that I could avoid with entry points and "GetEntryURL" function... I don't know if this is an strong o weak refference, but... how we should procced now, without entry points in reactive apps to call others pages and not have a dependence in this situations?

  • The other thing for which I use entry points is for avoid ciclic references creating a shared menu webblock used in several end-users modules of same application. Look this diagram:

    In some application, I have 3 end-users modules, that use the same menu webblock in theme (so have a reference with theme module). And menu webblock in theme module need to point to the pages accesed from menu... so we create ciclic references. With old entry points and GetEntryURL function we could avoid ciclic references, but now, without entry points, how we should proceed?


Sorry for the amount of questions, I'm trying to see all the migration aspects of the old classic web apps to the new hot-reactive-apps  :-D


Carlos.

Weak references mean that only if you change the API (e.g. mandatory parameters) you have to republish the consumer.

In the example you gave, if you change only the implementation of "end-user 1" module you will not need to republish any other modules (unless, of course, you add mandatory parameters). 

But if you had mandatory parameters you would need to change the external site parameter also.

Does this makes sense to you?


Tiago Simões wrote:

We’re proud to announce a whole new way of building highly performant and scalable applications. 

Using client-side development and a single codebase, you can create rich and engaging interfaces with a new type of web application that consolidates the development experience across mobile and web.


A revolutionary way of creating web applications

Reactive web apps give you the best of mobile apps with improvements that make creating web and mobile apps a lot easier. We’ll go into these them further ahead, but first here’s what we’ve brought from mobile to web.


Performance improvements

All UI elements in reactive web apps update immediately when the data they are bound to changes, instantly changing the interface. No more need to use Ajax Refresh; the apps are smart enough to understand what needs to be changed.


Client-side logic

In reactive web apps, all client-side logic can be visually modeled. Hard-to-maintain JavaScript will be a thing of the past. You can use the same logic construct across client and server actions. You have the full flexibility to create any kind of business logic. For client actions in the browser, calling server-side logic is just a drag-and-drop away. OutSystems generates and secures REST APIs behind the scenes to support communication between browser and server, using only the minimum network bandwidth required for the actual data transfer.


Responsiveness

Asynchronism in server communication keeps your apps always responsive. For example, while an app is executing a server-side action, it continues to run and respond to user input in the browser.


Scalability

OutSystems warns you whenever you accidentally create some scalability anti-pattern. For example, when you call a server action inside a loop, do something that might delay screen rendering, or sequentially call server actions, OutSystems suggests alternatives for the best performance of your apps.


A state-of-the-art runtime architecture

Reactive web apps use a modern runtime architecture built on industry standards and best practices taken to the limit. Most code and resources are cached in the browser, eliminating the communication overhead for the majority of user interactions. The UI is rendered in the client-side. All screens, blocks, and widgets are generated as reusable React components. Secure and fast REST APIs to handle communication are automatically generated from the actions defined in the IDE.


Data fetching

Instead of using Preparation, you’ll find screen data directly below the screen. Screen data is composed of aggregates, data actions, and variables. Aggregates provide easy access to entities’ data, while data actions can be used for more advanced cases, like fetching data from external services. All these are executed asynchronously and in parallel. This will improve your app’s UX, since there is no need to wait for all data to arrive before starting to display the page.


New capabilities introduced with Reactive Web

A Unified OutSystems UI framework

OutSystems UI Mobile is now called OutSystems UI. This is a big update to support the development of reactive web and mobile applications, a single UI framework for all your apps!

See more about the new framework in the OutSystems UI website.


Screen Aggregates and Data Actions scope improvements

We made data fetching straightforward to use in mobile and reactive web apps. Screen Aggregates and Data Actions are now available in the scope of other Screen Aggregates and Data Actions. For example, dropdowns that depend on other dropdowns’ selected values? No problem! Now you will be able to filter any aggregate using the results of another one. The platform will automatically understand the order in which these requests need to be done.


Fetch on Demand

We also added the Fetch property with On Start and On Demand options to Screen Aggregates and Data Actions. Now you can implement patterns such as master/detail with an excellent performance and user experience.


Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.


Default Buttons

Button widgets in mobile and reactive web apps now have the Is Form Default property, which you can set to Yes and have the App submit the data from the related form when the end-user presses the Enter key.


Table widget with simple Sorting

A new Table Widget comes with an accelerator: drag an Entity to it to create a table with sorting and pagination. Use tables to show data in cells distributed in rows and columns.


Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.


Native Dropdown widget

The Dropdown Widget has a new property Options Content, which you can set to Text Only or Custom. Text Only gives a native look and feel of the dropdown lists in your reactive we and mobile apps. Set Options Content property to Custom to build a dropdown with a list of images or other widgets.


Download files

You can drag a Download Tool logic node to your Flow and create a node which, when executed, sends a file for download to the end-user.


New Library module type

Start building great applications with a solid architecture, right from the very start. Take advantage of the new Library module, that guides you through the process of laying down the building blocks of your application. Libraries can be used in both reactive and mobile apps.


Reactive in the Forge

In the Forge, you’ll have a new filter for the type of component “Reactive”. These share most of the same underlying technology as the mobile ones so, if you find a mobile component (not requiring native capabilities) that you would like to use in your apps, it is possible to convert it to a reactive component. With the help of the community, we expect the list of available reactive components to grow pretty fast.


Optimized Network Payloads

We improved the efficiency of the data exchange between the server and client-side for reactive web apps, by ensuring the client-side receives only the data it really needs. This is another step in making reactive web apps that focus on client-side development paradigm, even faster and snappier.


Reuse Logic and Data

If you have existing traditional web applications you’ll be able to reuse their entities and server actions. All your backend logic, data, and services can be leveraged across all channels.


Create awesome experiences for your users

It all boils down to what can you do for your users. You have to experience these new apps to understand how users delight in smooth transitions and fast response times. And all of this without JavaScript, only with easy-to-change visual low-code.

This is quite a revolution, and there is a lot more we intend to do with Reactive Web, but your help is crucial.

Please share your feedback by replying to this post. The good and the bad alike. We’re here to learn and evolve with you.

Great feature! I'm really digging it and the training as well. Looking forward to the coming with the P12!!! 


.

Carlos Olías wrote:

  • The other thing for which I use entry points is for avoid ciclic references creating a shared menu webblock used in several end-users modules of same application. Look this diagram:

    In some application, I have 3 end-users modules, that use the same menu webblock in theme (so have a reference with theme module). And menu webblock in theme module need to point to the pages accesed from menu... so we create ciclic references. With old entry points and GetEntryURL function we could avoid ciclic references, but now, without entry points, how we should proceed?


...

Yes, has sense what you tell about weak refences!

And about avoid ciclic references? As explain in this diagram, if you have an application splitted in some "end-users" modules and this modules use a common webblock (in theme module) with menu links to navigate, you will create ciclic reference: end-users use the common menu webblock, and webblock has the links to navigate to end users screens... With GetEntryURL we could break the ciclic reference (discontinuous link in diagram), but without use getEntryURL, how we should make this kinds of references without create ciclic reference?

Thanks, again!


Carlos Olías wrote:

.

Carlos Olías wrote:

  • The other thing for which I use entry points is for avoid ciclic references creating a shared menu webblock used in several end-users modules of same application. Look this diagram:

    In some application, I have 3 end-users modules, that use the same menu webblock in theme (so have a reference with theme module). And menu webblock in theme module need to point to the pages accesed from menu... so we create ciclic references. With old entry points and GetEntryURL function we could avoid ciclic references, but now, without entry points, how we should proceed?


...

Yes, has sense what you tell about weak refences!

And about avoid ciclic references? As explain in this diagram, if you have an application splitted in some "end-users" modules and this modules use a common webblock (in theme module) with menu links to navigate, you will create ciclic reference: end-users use the common menu webblock, and webblock has the links to navigate to end users screens... With GetEntryURL we could break the ciclic reference (discontinuous link in diagram), but without use getEntryURL, how we should make this kinds of references without create ciclic reference?

Thanks, again!


Weak references break the cyclic references, i.e. if module1 links to module2 with a weak reference (e.g. a public screen) and module2 uses a strong reference (e.g. block) from module 1 that is not considered a cyclic reference, so you won't need to publish both modules on every change. 


Tiago Simões wrote:

...

Weak references break the cyclic references, i.e. if module1 links to module2 with a weak reference (e.g. a public screen) and module2 uses a strong reference (e.g. block) from module 1 that is not considered a cyclic reference, so you won't need to publish both modules on every change. 


Oh I see!! Perfect, many thanks!


Oh, I love this Reactive Web update from Outsystems. I have updated my platform server version and tried Reactive Web.

It's just awesome to work. As a mobile developer, I am facing more differences from mobile to web.

But now they totally revamped this and the advantage is it works like a mobile with react frontend.

Thank You So much Outsystems. You people always surprising with your releases. 

Tiago Simões wrote:

- Making localstorage work in all browsers is a challenge. We'll see what we can do. In any case, for web apps I would stay away from offline storage and the complexities of syncing data. As for libraries check if using client variables is an option.

Since you guys also announced PWA support in January 2020 I'm sure that this "problem" is already solved, just not implemented yet. And since this release is all about ReactJS I can totally understand why.

PWA for me is a much bigger deal then ReactJS in Web development. I can probably solve all my mobile app use cases with this and never ever have to encounter the hideous Apple store policies and awful Apple support anymore. Kudos for that!


For the people that have missed the PWA announcement:

React Web and soon PWA... great features!! Thanks OutSystems!

Really great improvement!!

Is this available in Version 11 or do I have to wait for Version 12?

romel2k wrote:

Really great improvement!!

Is this available in Version 11 or do I have to wait for Version 12?

You can go to your account page (where you can wake it up) and request the upgrade on your current 11 version.


romel2k wrote:

Really great improvement!!

Is this available in Version 11 or do I have to wait for Version 12?

It is out there now just do the platform upgrade and your service studio updated. I had the same question about the version change to OS 12. The OS guys (forgot the name) told me that it isn't really about the version upgrade since they can really make huge changes but it won't mean anything if it will not run on the current technologies like our browsers. They kept it as 11, do improvements on in but will still run on our browsers (and with other current integrations).

Coming from OS 8/9 and no experience with Native Mobile, just found it surprising that I can't drag and drop entities to a UI Flow and automatically create my list and edit pages. Not really and issue just a change in how to do things.

And I agree that it is very good and fast. Great job OutSystems!

Juan Carlos Elorde wrote:

Coming from OS 8/9 and no experience with Native Mobile, just found it surprising that I can't drag and drop entities to a UI Flow and automatically create my list and edit pages. Not really and issue just a change in how to do things.

And I agree that it is very good and fast. Great job OutSystems!

Dragging entities to flows to create screens is something we are currently working on and it should be available soon.


Tiago Simões wrote:

Juan Carlos Elorde wrote:

Coming from OS 8/9 and no experience with Native Mobile, just found it surprising that I can't drag and drop entities to a UI Flow and automatically create my list and edit pages. Not really and issue just a change in how to do things.

And I agree that it is very good and fast. Great job OutSystems!

Dragging entities to flows to create screens is something we are currently working on and it should be available soon.


Thanks for the information Tiago. I thought at first that this is how we do things now or there is like a design reason why OS need it that way.


Tiago Simões wrote:

Juan Carlos Elorde wrote:

Coming from OS 8/9 and no experience with Native Mobile, just found it surprising that I can't drag and drop entities to a UI Flow and automatically create my list and edit pages. Not really and issue just a change in how to do things.

And I agree that it is very good and fast. Great job OutSystems!

Dragging entities to flows to create screens is something we are currently working on and it should be available soon.


Good to hear. I was also missing this functionality :) 

An other strange bug I found was with debugging. When I debug a Reactive Web application the debugger opens in a mobile form factor. If needed I can open a ticket for this but surely this is already on some backlog somewhere?

Vincent Koning wrote:

An other strange bug I found was with debugging. When I debug a Reactive Web application the debugger opens in a mobile form factor. If needed I can open a ticket for this but surely this is already on some backlog somewhere?

Hi Vincent,

Indeed that’s an issue that is already in our backlog to be fixed soon. 

Thanks,

Tiago Simões


Tiago Simões wrote:

Carlos Olías wrote:

It's a great improvement!! I can't wait to "reactive" my apps :D

So far I have made a short test in my personal enviroment, and, althougth it's a great advance, I see some little disadvantages regarding classic web apps:

- Locale is not persisted between calls to server actions (there is an idea submited for this: LINK), so, we should set locale in each call to server actions in which we retried some translated text (literals, static tables, etc)
- There is no multilingual resources like classic web apps. So I suppose we should translate apps like classic mobile apps (translating literales one by one, creating a json resources, and using multilingual component), which is much more complicated
- There is no server session properties. There is a new client side properties (what is great!) but in some scenarios are useful to have server side properties. And, with the new reactive apps, values are not preserved between calls (like locale set)
- The patterns are the same that mobile patterns. This is great, and has sense to have common components (the new "libraries"), but there are some "classic web" patterns missing, like editable tables, radio buttons, etc...
- I have no make several test, but seems there is no easy way to migrate classic web apps to reactive apps. I have test to copy things from classic web apps to reactive web apps, and nothing can by copied, not even one container. So I believe that we should recode full apps, shouldn't we?

In any case I think it is a great step to improve the classic web applications, which were already a bit outdated. Thanks for work guys!

I've answered regarding locale and session variables in the post above (good news: client variables will be able to be read on screen aggregates and data actions soon).

Regarding multilingual, you are right, this is similar to mobile. We might improve this in the future.

As for patterns, we tend to continue evolving based on feedback.

As for migrating traditional web apps, there is no magic conversion available, the models are just too different for any conversion to be any good. This being said, you can reuse server logic and data. We plan to share some guidelines for migration in the future, but again there will always be effort involved.

Thanks for all your feedback and keep it coming.


Tiago - Thanks for this clarification.  

All  - in terms of converting some of the popular forge components into reactive apps.  I'm look at the Microsoft Login connector.  Has anyone any thoughts on how to label these on the forge?  As you will likely have to support a traditional web version and a reactive version for the forseeable future.


Paul Davies wrote:

Tiago - Thanks for this clarification.  

All  - in terms of converting some of the popular forge components into reactive apps.  I'm look at the Microsoft Login connector.  Has anyone any thoughts on how to label these on the forge?  As you will likely have to support a traditional web version and a reactive version for the forseeable future.


Paul,

I simple append "- Reactive" to my modules that I've published so far.


Regarding the forge, and since reactive components and libraries can also be used in mobile, I would not add extra components on the forge, I would simply convert the mobile ones and remove the "mobile" from the component name. We did that already on a few (e.g. OutSystems UI Mobile is now OutSystems UI). This will make them easier to maintain. 

If you need to differentiate them from traditional web components consider converting them to libraries and appending a "library" in the name (e.g. Google Maps Library, previously known as Google Maps Mobile).

The type of component will always be visible in the overlay icon and you can filter them using the filters on the left. This being said, this is pretty new, so I'm sure the community will continue to figure this out and adapt as this is used further and further. It's pretty cool that not a week as passed and there are already several components available for reactive.


Ah. This is nice to know. So it's better to use Libraries to create components instead of using a Reactive Web App. This means I need to recreate my component. No a biggie, it's not used that much yet. 

At least for now, libraries are only module types: they need to be inside a mobile or reactive app. Use libraries if your component does not need to store data or provide screens. This will make the architecture of the apps using it better, as libraries can't reference services or apps.

Tiago Simões wrote:

Regarding the forge, and since reactive components and libraries can also be used in mobile, I would not add extra components on the forge, I would simply convert the mobile ones and remove the "mobile" from the component name. We did that already on a few (e.g. OutSystems UI Mobile is now OutSystems UI). This will make them easier to maintain. 

If you need to differentiate them from traditional web components consider converting them to libraries and appending a "library" in the name (e.g. Google Maps Library, previously known as Google Maps Mobile).

The type of component will always be visible in the overlay icon and you can filter them using the filters on the left. This being said, this is pretty new, so I'm sure the community will continue to figure this out and adapt as this is used further and further. It's pretty cool that not a week as passed and there are already 21 components available for reactive.


The image you have in  the screen shot where is this from?  

When you say convert to library I presume you mean rebuild in reactive as a library?

Thanks

Paul



Paul Davies wrote:

Tiago Simões wrote:

Regarding the forge, and since reactive components and libraries can also be used in mobile, I would not add extra components on the forge, I would simply convert the mobile ones and remove the "mobile" from the component name. We did that already on a few (e.g. OutSystems UI Mobile is now OutSystems UI). This will make them easier to maintain. 

If you need to differentiate them from traditional web components consider converting them to libraries and appending a "library" in the name (e.g. Google Maps Library, previously known as Google Maps Mobile).

The type of component will always be visible in the overlay icon and you can filter them using the filters on the left. This being said, this is pretty new, so I'm sure the community will continue to figure this out and adapt as this is used further and further. It's pretty cool that not a week as passed and there are already 21 components available for reactive.


The image you have in  the screen shot where is this from?  

When you say convert to library I presume you mean rebuild in reactive as a library?

Thanks

Paul



Hi Paul,

The image above is from the left sidebar of forge, when you click advanced search.

You can actually convert a mobile module to a reactive or library module using the menu in Service Studio (Module>Convert>Convert to...)

Cheers,
Tiago Simões

Hi Tiago,

Any plans for OutSystems to move the RichWidgets as well so we need not to rewrite them into React Web Pages?

Thanks,

JC

Juan Carlos Elorde wrote:

Hi Tiago,

Any plans for OutSystems to move the RichWidgets as well so we need not to rewrite them into React Web Pages?

Thanks,

JC

Hi Juan,

Some of Richwidgets functionalities are now in built-in widgets and actions (e.g. icon, table's sort, modal, message...). Others are in OutSystems UI (Pagination, Dropdown Search, Submenu, Tooltip, Date Picker...). And the best part is that most of them provide better developer and user experiences.

Cheers,
Tiago Simões


Can you upgrade a cloud platform to be able to create react web apps and still have old web apps running on that server?  Will it break the old web apps?

Hi Michael,

Support for Reactive Web Apps seems to be built using a similar technology stack to Mobile Apps, and is completely independent of Classic Web Apps support, as far as I can tell. Your Web components are also only use for Classic Web Apps, so this release shouldn't impact any of the current Web Apps you have.

Tiago Simões wrote:

Juan Carlos Elorde wrote:

Hi Tiago,

Any plans for OutSystems to move the RichWidgets as well so we need not to rewrite them into React Web Pages?

Thanks,

JC

Hi Juan,

Some of Richwidgets functionalities are now in built-in widgets and actions (e.g. icon, table's sort, modal, message...). Others are in OutSystems UI (Pagination, Dropdown Search, Submenu, Tooltip, Date Picker...). And the best part is that most of them provide better developer and user experiences.

Cheers,
Tiago Simões


Interesting point!

We are currently using RichWidgets for a lot of things... In a quickly review: List_Counter, List_Navigation, Popup_Editor, List_SortColumn, DropDownMenu, Icon, RemovePopUps, FakeNotifyWidget...  And some server actions like "GetServername", "FeedbackMessage", "PopUpEditorNotify", "PopUpEditorClose"... Some, like calendar, I now has an alternative (although it has less options), but others like pagination that you mentioned, but I don't find in Outsystems UI (when use an scafolding in traditional apps, Outsystems use richwidgets pagination), popups, feedbacks messages (LiveStyleGuide from Outsystems UI is using RichWidgets feedback messages , or icons, has an alternative? and will they have it now in the new reactive apps?


Thanks for clarifications,
Carlos.


Hi Carlos,

If you explore the screen templates in reactive apps you'll find these and a lot more patterns in use. I would say you won't miss richwidgets.

Cheers,
Tiago Simões

Tiago Simões wrote:

Juan Carlos Elorde wrote:

Hi Tiago,

Any plans for OutSystems to move the RichWidgets as well so we need not to rewrite them into React Web Pages?

Thanks,

JC

Hi Juan,

Some of Richwidgets functionalities are now in built-in widgets and actions (e.g. icon, table's sort, modal, message...). Others are in OutSystems UI (Pagination, Dropdown Search, Submenu, Tooltip, Date Picker...). And the best part is that most of them provide better developer and user experiences.

Cheers,
Tiago Simões


Hi Tiago,

I definitely agree that the new ones are better. However, my clients are picky lol.

To be more specific, I am looking at the Input_AutoComplete component in the RichWidgets. I know we can use the Dropdown_Search but the CX guys doesn't want the idea that you click one textbox and then type in the new textbox the shows up. Right now, I just did workaround. But the client pushes that we might have to redo the Input_AutoComplete if needed.

Regards,

JC

When I think about all the hours wasted and added frustrations around some stuff that now will be available with just a few clicks - goof job OutSystems, way to go!

Juan Carlos Elorde wrote:

Tiago Simões wrote:

Juan Carlos Elorde wrote:

Hi Tiago,

Any plans for OutSystems to move the RichWidgets as well so we need not to rewrite them into React Web Pages?

Thanks,

JC

Hi Juan,

Some of Richwidgets functionalities are now in built-in widgets and actions (e.g. icon, table's sort, modal, message...). Others are in OutSystems UI (Pagination, Dropdown Search, Submenu, Tooltip, Date Picker...). And the best part is that most of them provide better developer and user experiences.

Cheers,
Tiago Simões


Hi Tiago,

I definitely agree that the new ones are better. However, my clients are picky lol.

To be more specific, I am looking at the Input_AutoComplete component in the RichWidgets. I know we can use the Dropdown_Search but the CX guys doesn't want the idea that you click one textbox and then type in the new textbox the shows up. Right now, I just did workaround. But the client pushes that we might have to redo the Input_AutoComplete if needed.

Regards,

JC

Hi Juan,

Wouldn't the new pattern DropdownTag help you with that? Even if you had to change the css a bit, to remove the 'tag' style. You can quickly check what I'm talking about on the OS UI Website:


DropdownTag: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=35

DropdownSearch: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=34


If not, can you share the workaround you did? Maybe it can help us understand a common request during development.


Best regards,

Bernardo Cardoso

Bernardo Cardoso wrote:

Hi Juan,

Wouldn't the new pattern DropdownTag help you with that? Even if you had to change the css a bit, to remove the 'tag' style. You can quickly check what I'm talking about on the OS UI Website:


DropdownTag: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=35

DropdownSearch: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=34


If not, can you share the workaround you did? Maybe it can help us understand a common request during development.


Best regards,

Bernardo Cardoso

Hi Bernardo,

Here's a simple approach that I did. I used a textbox with a variable used as a parameter of a query. I call the onchange to refresh the query. The query is used on the list that I put inside a floating content.

Still haven't found the right styling though to make the floating content the same size with the textbox.

Regards,

JC


Quick Question: We have been waiting for some time now to get our hands on this new capability. As an OS partner we didn't have access to it from the EAP and even now that Reactive is GA we are still excluded as we are stuck on some old version of LifeTime. 

Is this the same for all OS Partners?

Hi John,

Can't you update your version of LifeTime? As far as I know it's backwards compatible, so even if you just update your Dev environment it should still be able to work with all environments on the infrastructure. Personal Environments can already be updated to a version that supports RWA, I'd assume it would be possible to do the same for Enterprise Environments?

Juan Carlos Elorde wrote:

Bernardo Cardoso wrote:

Hi Juan,

Wouldn't the new pattern DropdownTag help you with that? Even if you had to change the css a bit, to remove the 'tag' style. You can quickly check what I'm talking about on the OS UI Website:


DropdownTag: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=35

DropdownSearch: https://outsystemsui.outsystems.com/OutSystemsUIWebsite/PatternDetail?PatternId=34


If not, can you share the workaround you did? Maybe it can help us understand a common request during development.


Best regards,

Bernardo Cardoso

Hi Bernardo,

Here's a simple approach that I did. I used a textbox with a variable used as a parameter of a query. I call the onchange to refresh the query. The query is used on the list that I put inside a floating content.

Still haven't found the right styling though to make the floating content the same size with the textbox.

Regards,

JC


Hi Juan,

I see, thank you! We will analyze in our team if there's something we can do to accelerate those use cases.

On that solution, you probably have to define a fixed width in 'px' for both elements.


Best regards,

Bernardo Cardoso




Jorge Martins wrote:

Hi John,

Can't you update your version of LifeTime? As far as I know it's backwards compatible, so even if you just update your Dev environment it should still be able to work with all environments on the infrastructure. Personal Environments can already be updated to a version that supports RWA, I'd assume it would be possible to do the same for Enterprise Environments?

Partner environments, seem to be held on some early, June version, of LifeTime.  I have tried raising a support ticket, they can't do it. Local OS folk have no idea.


Bernardo Cardoso wrote:

Hi Juan,

I see, thank you! We will analyze in our team if there's something we can do to accelerate those use cases.

On that solution, you probably have to define a fixed width in 'px' for both elements.


Best regards,

Bernardo Cardoso

Hi Bernardo, Thanks. I don't know if it will mean something to the general users but will definitely help those who are used to the old approach. If I do fixed px, I am just afraid it won't work since we are catering multiple form factors. Regards, JC

Finally some great news hahaha


Some ideas i have talking with MVP in ODC 2018 is finally made !

John Ackery wrote:

Jorge Martins wrote:

Hi John,

Can't you update your version of LifeTime? As far as I know it's backwards compatible, so even if you just update your Dev environment it should still be able to work with all environments on the infrastructure. Personal Environments can already be updated to a version that supports RWA, I'd assume it would be possible to do the same for Enterprise Environments?

Partner environments, seem to be held on some early, June version, of LifeTime.  I have tried raising a support ticket, they can't do it. Local OS folk have no idea.


Ok, you're talking about Enterprise Cloud Environments... I'll ask around and get back to you if/when I have news.


Jorge Martins wrote:

John Ackery wrote:

Jorge Martins wrote:

Hi John,

Can't you update your version of LifeTime? As far as I know it's backwards compatible, so even if you just update your Dev environment it should still be able to work with all environments on the infrastructure. Personal Environments can already be updated to a version that supports RWA, I'd assume it would be possible to do the same for Enterprise Environments?

Partner environments, seem to be held on some early, June version, of LifeTime.  I have tried raising a support ticket, they can't do it. Local OS folk have no idea.


Ok, you're talking about Enterprise Cloud Environments... I'll ask around and get back to you if/when I have news.


Hi John,

The Cloud demo environments for partners have some differences to both Personals and Enterprise Cloud environments and require a separate effort for upgrading. This time, we had to prioritize Personals to have them ready to create reactive apps by NextStep. 

We are now taking care of the Cloud demo environments for partners. In the next few days, you should have a click-to-upgrade button in our home.

You will soon be building great reactive apps! ;-)


We are running version: 11.0.539.0

Also, we were in the Early Access Program for Reactive Web. 

Question: What is the minimum server version for Reactive Web - and - how do I get "out of" the EAP so we get the full version?

Hi Bruce,

I believe Platform Server Release Oct.2019 (Service Center 11.0.606.0) is the first to have GA support for RWA... Release Oct.2019 CP1 version is the latest version and addresses a severe issue found meanwhile.

You will need to update Service Studio to at least 11.6.1 as well to take advantage of the new features.

Tiago Simões wrote:

We’re proud to announce a whole new way of building highly performant and scalable applications. 

Using client-side development and a single codebase, you can create rich and engaging interfaces with a new type of web application that consolidates the development experience across mobile and web.


A revolutionary way of creating web applications

Reactive web apps give you the best of mobile apps with improvements that make creating web and mobile apps a lot easier. We’ll go into these them further ahead, but first here’s what we’ve brought from mobile to web.


Performance improvements

All UI elements in reactive web apps update immediately when the data they are bound to changes, instantly changing the interface. No more need to use Ajax Refresh; the apps are smart enough to understand what needs to be changed.


Client-side logic

In reactive web apps, all client-side logic can be visually modeled. Hard-to-maintain JavaScript will be a thing of the past. You can use the same logic construct across client and server actions. You have the full flexibility to create any kind of business logic. For client actions in the browser, calling server-side logic is just a drag-and-drop away. OutSystems generates and secures REST APIs behind the scenes to support communication between browser and server, using only the minimum network bandwidth required for the actual data transfer.


Responsiveness

Asynchronism in server communication keeps your apps always responsive. For example, while an app is executing a server-side action, it continues to run and respond to user input in the browser.


Scalability

OutSystems warns you whenever you accidentally create some scalability anti-pattern. For example, when you call a server action inside a loop, do something that might delay screen rendering, or sequentially call server actions, OutSystems suggests alternatives for the best performance of your apps.


A state-of-the-art runtime architecture

Reactive web apps use a modern runtime architecture built on industry standards and best practices taken to the limit. Most code and resources are cached in the browser, eliminating the communication overhead for the majority of user interactions. The UI is rendered in the client-side. All screens, blocks, and widgets are generated as reusable React components. Secure and fast REST APIs to handle communication are automatically generated from the actions defined in the IDE.


Data fetching

Instead of using Preparation, you’ll find screen data directly below the screen. Screen data is composed of aggregates, data actions, and variables. Aggregates provide easy access to entities’ data, while data actions can be used for more advanced cases, like fetching data from external services. All these are executed asynchronously and in parallel. This will improve your app’s UX, since there is no need to wait for all data to arrive before starting to display the page.


New capabilities introduced with Reactive Web

A Unified OutSystems UI framework

OutSystems UI Mobile is now called OutSystems UI. This is a big update to support the development of reactive web and mobile applications, a single UI framework for all your apps!

See more about the new framework in the OutSystems UI website.


Screen Aggregates and Data Actions scope improvements

We made data fetching straightforward to use in mobile and reactive web apps. Screen Aggregates and Data Actions are now available in the scope of other Screen Aggregates and Data Actions. For example, dropdowns that depend on other dropdowns’ selected values? No problem! Now you will be able to filter any aggregate using the results of another one. The platform will automatically understand the order in which these requests need to be done.


Fetch on Demand

We also added the Fetch property with On Start and On Demand options to Screen Aggregates and Data Actions. Now you can implement patterns such as master/detail with an excellent performance and user experience.


Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.


Default Buttons

Button widgets in mobile and reactive web apps now have the Is Form Default property, which you can set to Yes and have the App submit the data from the related form when the end-user presses the Enter key.


Table widget with simple Sorting

A new Table Widget comes with an accelerator: drag an Entity to it to create a table with sorting and pagination. Use tables to show data in cells distributed in rows and columns.


Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.


Native Dropdown widget

The Dropdown Widget has a new property Options Content, which you can set to Text Only or Custom. Text Only gives a native look and feel of the dropdown lists in your reactive we and mobile apps. Set Options Content property to Custom to build a dropdown with a list of images or other widgets.


Download files

You can drag a Download Tool logic node to your Flow and create a node which, when executed, sends a file for download to the end-user.


New Library module type

Start building great applications with a solid architecture, right from the very start. Take advantage of the new Library module, that guides you through the process of laying down the building blocks of your application. Libraries can be used in both reactive and mobile apps.


Reactive in the Forge

In the Forge, you’ll have a new filter for the type of component “Reactive”. These share most of the same underlying technology as the mobile ones so, if you find a mobile component (not requiring native capabilities) that you would like to use in your apps, it is possible to convert it to a reactive component. With the help of the community, we expect the list of available reactive components to grow pretty fast.


Optimized Network Payloads

We improved the efficiency of the data exchange between the server and client-side for reactive web apps, by ensuring the client-side receives only the data it really needs. This is another step in making reactive web apps that focus on client-side development paradigm, even faster and snappier.


Reuse Logic and Data

If you have existing traditional web applications you’ll be able to reuse their entities and server actions. All your backend logic, data, and services can be leveraged across all channels.


Create awesome experiences for your users

It all boils down to what can you do for your users. You have to experience these new apps to understand how users delight in smooth transitions and fast response times. And all of this without JavaScript, only with easy-to-change visual low-code.

This is quite a revolution, and there is a lot more we intend to do with Reactive Web, but your help is crucial.

Please share your feedback by replying to this post. The good and the bad alike. We’re here to learn and evolve with you.

Great, already exploring it



Does upgrading OS11 with this new feature affect our license and technical support ?

In other words: is this still Beta or a fully supported upgrade?

Stefano Valente wrote:

Does upgrading OS11 with this new feature affect our license and technical support ?

In other words: is this still Beta or a fully supported upgrade?

Hi Stefano,

This is a fully supported upgrade.

Cheers,
Tiago Simões


This is wonderful news. This is what keeps us moving forward to always meet our customers' needs. I don't see the opportunity to start my first project with Reactive Web.


Is there an OutSystems CAMERA library for Reactive Web?

Bruce Buttles wrote:

Is there an OutSystems CAMERA library for Reactive Web?

Bruce are you looking for something like this?


https://www.outsystems.com/forge/component-overview/6891/camera-reactive



Paul Davies wrote:

Bruce Buttles wrote:

Is there an OutSystems CAMERA library for Reactive Web?

Bruce are you looking for something like this?


https://www.outsystems.com/forge/component-overview/6891/camera-reactive



Yes - I tried it and it is pretty good but does not give me the flexibility and control I need. It starts with the camera in selfie mode, can't figure out how to switch to the back camera, and the capture is not working.

So, was wondering if OS will have a camera control soon for Reactive Web.


Bruce Buttles wrote:

Paul Davies wrote:

Bruce Buttles wrote:

Is there an OutSystems CAMERA library for Reactive Web?

Bruce are you looking for something like this?


https://www.outsystems.com/forge/component-overview/6891/camera-reactive



Yes - I tried it and it is pretty good but does not give me the flexibility and control I need. It starts with the camera in selfie mode, can't figure out how to switch to the back camera, and the capture is not working.

So, was wondering if OS will have a camera control soon for Reactive Web.


Hi Bruce,

As you might know, we are currently working on PWAs (Q1 2020), and converting some mobile plugins which can be used with standard web APIs is on our plans, but we don't have anything yet on that. That being said, a bit of JavaScript research and tweaking on that topic might help you advance further on that. Maybe also follow this up on that forge component discussion thread, so that other interested community users can also  eventually help. 

Cheers,
Tiago Simões


Bruce Buttles wrote:

Paul Davies wrote:

Bruce Buttles wrote:

Is there an OutSystems CAMERA library for Reactive Web?

Bruce are you looking for something like this?


https://www.outsystems.com/forge/component-overview/6891/camera-reactive



Yes - I tried it and it is pretty good but does not give me the flexibility and control I need. It starts with the camera in selfie mode, can't figure out how to switch to the back camera, and the capture is not working.

So, was wondering if OS will have a camera control soon for Reactive Web.


Latest release today include camera switching according to release notes.

Great news... :D

Yes, Its Great News. Cheers Guys (Y)

Tiago Simões wrote:

We’re proud to announce a whole new way of building highly performant and scalable applications. 

Using client-side development and a single codebase, you can create rich and engaging interfaces with a new type of web application that consolidates the development experience across mobile and web.


A revolutionary way of creating web applications

Reactive web apps give you the best of mobile apps with improvements that make creating web and mobile apps a lot easier. We’ll go into these them further ahead, but first here’s what we’ve brought from mobile to web.


Performance improvements

All UI elements in reactive web apps update immediately when the data they are bound to changes, instantly changing the interface. No more need to use Ajax Refresh; the apps are smart enough to understand what needs to be changed.


Client-side logic

In reactive web apps, all client-side logic can be visually modeled. Hard-to-maintain JavaScript will be a thing of the past. You can use the same logic construct across client and server actions. You have the full flexibility to create any kind of business logic. For client actions in the browser, calling server-side logic is just a drag-and-drop away. OutSystems generates and secures REST APIs behind the scenes to support communication between browser and server, using only the minimum network bandwidth required for the actual data transfer.


Responsiveness

Asynchronism in server communication keeps your apps always responsive. For example, while an app is executing a server-side action, it continues to run and respond to user input in the browser.


Scalability

OutSystems warns you whenever you accidentally create some scalability anti-pattern. For example, when you call a server action inside a loop, do something that might delay screen rendering, or sequentially call server actions, OutSystems suggests alternatives for the best performance of your apps.


A state-of-the-art runtime architecture

Reactive web apps use a modern runtime architecture built on industry standards and best practices taken to the limit. Most code and resources are cached in the browser, eliminating the communication overhead for the majority of user interactions. The UI is rendered in the client-side. All screens, blocks, and widgets are generated as reusable React components. Secure and fast REST APIs to handle communication are automatically generated from the actions defined in the IDE.


Data fetching

Instead of using Preparation, you’ll find screen data directly below the screen. Screen data is composed of aggregates, data actions, and variables. Aggregates provide easy access to entities’ data, while data actions can be used for more advanced cases, like fetching data from external services. All these are executed asynchronously and in parallel. This will improve your app’s UX, since there is no need to wait for all data to arrive before starting to display the page.


New capabilities introduced with Reactive Web

A Unified OutSystems UI framework

OutSystems UI Mobile is now called OutSystems UI. This is a big update to support the development of reactive web and mobile applications, a single UI framework for all your apps!

See more about the new framework in the OutSystems UI website.


Screen Aggregates and Data Actions scope improvements

We made data fetching straightforward to use in mobile and reactive web apps. Screen Aggregates and Data Actions are now available in the scope of other Screen Aggregates and Data Actions. For example, dropdowns that depend on other dropdowns’ selected values? No problem! Now you will be able to filter any aggregate using the results of another one. The platform will automatically understand the order in which these requests need to be done.


Fetch on Demand

We also added the Fetch property with On Start and On Demand options to Screen Aggregates and Data Actions. Now you can implement patterns such as master/detail with an excellent performance and user experience.


Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.


Default Buttons

Button widgets in mobile and reactive web apps now have the Is Form Default property, which you can set to Yes and have the App submit the data from the related form when the end-user presses the Enter key.


Table widget with simple Sorting

A new Table Widget comes with an accelerator: drag an Entity to it to create a table with sorting and pagination. Use tables to show data in cells distributed in rows and columns.


Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.


Native Dropdown widget

The Dropdown Widget has a new property Options Content, which you can set to Text Only or Custom. Text Only gives a native look and feel of the dropdown lists in your reactive we and mobile apps. Set Options Content property to Custom to build a dropdown with a list of images or other widgets.


Download files

You can drag a Download Tool logic node to your Flow and create a node which, when executed, sends a file for download to the end-user.


New Library module type

Start building great applications with a solid architecture, right from the very start. Take advantage of the new Library module, that guides you through the process of laying down the building blocks of your application. Libraries can be used in both reactive and mobile apps.


Reactive in the Forge

In the Forge, you’ll have a new filter for the type of component “Reactive”. These share most of the same underlying technology as the mobile ones so, if you find a mobile component (not requiring native capabilities) that you would like to use in your apps, it is possible to convert it to a reactive component. With the help of the community, we expect the list of available reactive components to grow pretty fast.


Optimized Network Payloads

We improved the efficiency of the data exchange between the server and client-side for reactive web apps, by ensuring the client-side receives only the data it really needs. This is another step in making reactive web apps that focus on client-side development paradigm, even faster and snappier.


Reuse Logic and Data

If you have existing traditional web applications you’ll be able to reuse their entities and server actions. All your backend logic, data, and services can be leveraged across all channels.


Create awesome experiences for your users

It all boils down to what can you do for your users. You have to experience these new apps to understand how users delight in smooth transitions and fast response times. And all of this without JavaScript, only with easy-to-change visual low-code.

This is quite a revolution, and there is a lot more we intend to do with Reactive Web, but your help is crucial.

Please share your feedback by replying to this post. The good and the bad alike. We’re here to learn and evolve with you.

Great staff, I am loving the client Variable feature 


What I LOVE is no more "REFRESH WIDGET" !!!

It's awesome - as soon as a data element changes value - POOF!!! the dependent UI Widget refreshes automatically!!!!

I am able to show/hide widgets like crazy now very simply - "single-page apps" are ROCKIN!

Allows us to really remove all the noise and show only they key data or form elements at that moment - helps the user be effortlessly focused on the task at hand. #nohelpneeded

Tiago Simões wrote:

Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.

Hi Tiago,

I can't use a type Record on the Client Variable. Is this something you are still working on or is this how it is?

I a wizard type of form (multiple web blocks) with pieces of the fields of the record. It will eventually fill in a record and will be submitted in the end. I will use this Client Variable for this.

Regards,
JC

Juan Carlos Elorde wrote:

Tiago Simões wrote:

Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.

Hi Tiago,

I can't use a type Record on the Client Variable. Is this something you are still working on or is this how it is?

I a wizard type of form (multiple web blocks) with pieces of the fields of the record. It will eventually fill in a record and will be submitted in the end. I will use this Client Variable for this.

Regards,
JC

You can use events and their input variables for that. 


Hi JC,

As Stefano was saying, using blocks and events might be a solution. As for client variables currently they only support basic types (both for technical and product design reasons: browser local storage limitations and cache invalidation and data sync usually lead to maintenance headaches). We might review this in the future.

Cheers,

Tiago Simões 

Stefano Valente wrote:

Juan Carlos Elorde wrote:

Tiago Simões wrote:

Client Variables

Create Client Variables in Mobile and Reactive Apps. Yes, that’s right. This will be useful to store interface state like a filter or to cache user information that you don’t want to fetch from the server all the time.

Hi Tiago,

I can't use a type Record on the Client Variable. Is this something you are still working on or is this how it is?

I a wizard type of form (multiple web blocks) with pieces of the fields of the record. It will eventually fill in a record and will be submitted in the end. I will use this Client Variable for this.

Regards,
JC

You can use events and their input variables for that. 


Yes this is viable but I'd imagine having that record variable defined in each block and passed on to another.

In my case, one of the block just updates the phone number. But with that I will be passing the whole variable with just one column updated on this one.

Another block updates the email, so on and so forth.

I guess since this is the only option for now, I will work on it. Thanks.


@JC, I understand. Can I suggest you add an idea for that, so that we can track its progress. 

@Bruce, I agree with you, that’s also one of my favorite parts, less “code” to maintain. 

@All,

Thank you very much for your enthusiastic support. That’s what makes us love coming to work every day on this product. 

This could not have been done without this brilliant open community, that’s welcoming to newcomers, loves to share, and is not afraid of change. 

It’s these positive feedback loops that empower innovation.

More than 30 ideas submitted by community members, and voted and commented over by hundreds of you, have drove these changes. This is truly a product built by its users. 

Thank you all for that. 

And keep that feedback coming, so we can keep evolving together. 

Juan Carlos Elorde wrote:

Yes this is viable but I'd imagine having that record variable defined in each block and passed on to another.

In my case, one of the block just updates the phone number. But with that I will be passing the whole variable with just one column updated on this one.

Another block updates the email, so on and so forth.

I guess since this is the only option for now, I will work on it. Thanks.


Hi Juan,

Perhaps it's better to create a new thread for this question and continue there. But webblocks and their events are the way to go in this case. I also created a wizard like form and I just "evented" the inputted data to the main page so it could be inserted in the form record. 

Vincent Koning wrote:

Juan Carlos Elorde wrote:

Yes this is viable but I'd imagine having that record variable defined in each block and passed on to another.

In my case, one of the block just updates the phone number. But with that I will be passing the whole variable with just one column updated on this one.

Another block updates the email, so on and so forth.

I guess since this is the only option for now, I will work on it. Thanks.


Hi Juan,

Perhaps it's better to create a new thread for this question and continue there. But webblocks and their events are the way to go in this case. I also created a wizard like form and I just "evented" the inputted data to the main page so it could be inserted in the form record. 

Hi Vincent,

Thanks for the advise. I rest the case for now. Sorry for 'hijacking' the thread for a bit.

Cheers!

JC


João Santos wrote:

....

Ok, you're talking about Enterprise Cloud Environments... I'll ask around and get back to you if/when I have news.


Hi John,

The Cloud demo environments for partners have some differences to both Personals and Enterprise Cloud environments and require a separate effort for upgrading. This time, we had to prioritize Personals to have them ready to create reactive apps by NextStep. 

We are now taking care of the Cloud demo environments for partners. In the next few days, you should have a click-to-upgrade button in our home.

You will soon be building great reactive apps! ;-)


How can I subscribe to news about this?  I have a team just getting started and we would want to go to Reactive by default, asap!


Andy Borthwick wrote:


How can I subscribe to news about this?  I have a team just getting started and we would want to go to Reactive by default, asap!


Hi Andy,

The upgrade for cloud demo systems for partners has been available for a few days already. You can do it now! :-)

See https://success.outsystems.com/Support/Enterprise_Trial/OutSystems_Cloud_Demo_Upgrades for details.

Cheers,

Joao 


João Santos wrote:

Andy Borthwick wrote:


How can I subscribe to news about this?  I have a team just getting started and we would want to go to Reactive by default, asap!


Hi Andy,

The upgrade for cloud demo systems for partners has been available for a few days already. You can do it now! :-)

See https://success.outsystems.com/Support/Enterprise_Trial/OutSystems_Cloud_Demo_Upgrades for details.

Cheers,

Joao 



Got it, updated, done! Awesome!

Awesome! Exciting news!

Wow, the resoponse of community is so great for reactive :)

Hey everyone,

As this is such an hot topic right now with developers...

OutPower has released a new Tutorial where it goes over some of the differences between traditional web applications and reactive web applications. If this new technology is still intriguing you, why not give a look to our quick video for more clarification.

YouTube link: https://youtu.be/ZrPKWf7fnI8

Hope you find it useful.




Hi Tiago,

Pretty cool video, thanks for sharing!

Cheers,
Tiago Simões

PS: Events had already been introduced in traditional web blocks on version 11. These ones are faster though, because they do not rely on server round-trips. But it's cool you are talking about them, because web developers coming from previous versions may still not be aware of block events.

Tiago Simões wrote:

As for migrating traditional web apps, there is no magic conversion available, the models are just too different for any conversion to be any good. This being said, you can reuse server logic and data. We plan to share some guidelines for migration in the future, but again there will always be effort involved.

Do you have an ETA for when this migration advice might be available?

The new react apps do seem like they might resolve some of the issues that we've encountered in the past, but rewriting our entire front end would be a very significant investment.


MichaelR wrote:

Tiago Simões wrote:

As for migrating traditional web apps, there is no magic conversion available, the models are just too different for any conversion to be any good. This being said, you can reuse server logic and data. We plan to share some guidelines for migration in the future, but again there will always be effort involved.

Do you have an ETA for when this migration advice might be available?

The new react apps do seem like they might resolve some of the issues that we've encountered in the past, but rewriting our entire front end would be a very significant investment.


Hi MichaelR,

We expect to have some drafts to share in the next couple of weeks. These will evolve as we get more feedback from customers and partners doing these projects.

Cheers,
Tiago Simões


Hi,


I'm verry happy i can use react now, but I miss the "Internal access only" on the UIFlows.

Will this be added to react?

Kevin you are not the only one. Me too

Hi Kevin, Alberto,

Thanks for your feedback. Could I suggest you submit an idea for that? As we continue evolving reactive, we need to better understand the the several use cases and the amount of demand on them to help us prioritize, as there are other things that we also need to work on, like email. Regarding Internal Access Only, as we have more and more customers starting in (or moving to) the cloud some of these requirements could and maybe should be handled differently (e.g. through firewalls, on LifeTime or Service Center, or some other solution) but we need to discuss these a bit more in their own threads.

Thanks a lot,
Tiago Simões

Hi Tiago.


The way we consume module's server funcions of the same react App has changed? 

I tried to did that and even the function appears in the Logic tab, it not appears in the expression editor and is not recognized as valid function.

Thank you, new Toy is coming.

Hi, how come this tech more difficult to use when i check for file type compared with traditional web?

https://www.outsystems.com/forums/discussion/54515/reactive-web-check-file-type/

regards

Ismael Amaral wrote:

Hi Tiago.


The way we consume module's server funcions of the same react App has changed? 

I tried to did that and even the function appears in the Logic tab, it not appears in the expression editor and is not recognized as valid function.

Hi Ismael,

On the interface and client actions you can only use client functions.

Cheers,

Tiago Simões 


IBOX wrote:

Thank you, new Toy is coming.

Hi, how come this tech more difficult to use when i check for file type compared with traditional web?

https://www.outsystems.com/forums/discussion/54515/reactive-web-check-file-type/

regards

Hi IBOX,

Thank you for your feedback. From our analysis content-type was not well understood by less experienced users, and it’s usages could be trivially substituted by analyzing the filename extension.  

Maybe your use case is a bit special, I’ll try to answer it in that thread.

Cheers,

Tiago Simões

This is fantastic

Thank you for your sharing.