Hi Paulo, 

Thank you for you idea. I was wondering, could the JavaScript Navigation APIs help with this use case?

Regarding the solution mentioned in your article, we strongly advise against using internal APIs. Since they are considered internal, they are subject to change at any time, which could cause your applications to break.

Thank you

Hi Rita,

Your feedback is exactly why this idea has been shared—we’re eager to see this feature officially supported by the platform.

The article begins with the following observation:

"Warning: This article uses OutSystems undocumented API’s that can be changed at any time by OutSystems! Proceed with your implementation at your own risk! "

When building B2C solutions for web and mobile in OutSystems, developers often find themselves needing to go beyond what the platform officially supports. In this article, Paulo highlights a critical gap, offering a workaround solution to address the issue. However, it comes with a disclaimer: this approach is not officially supported and should be used cautiously.

More importantly, this article serves as a call to action for OutSystems. By implementing a supported solution, the platform could empower developers to create robust, mission-critical B2C solutions without compromising on reliability or maintainability.

Regards,

Daniel

Hi @Rita Tinoco,

Thank you for your feedback and for considering this Idea.

I’d also like to thank @Daniël Kuhlmann for his reply, which perfectly captures the intent behind both the article and this Idea submission.

To address your question regarding the JavaScript Navigation APIs, the use of this API was considered, but after a quick thinking we could identify some issues:

• Although the JavaScript Navigation APIs can be used to navigate back to a certain screen (and because it uses the ScreenStateCache API  it restores the screen state), the stack of saved components cache in this API is only of 20 keys. This means that after 20 different navigations, older states are removed, and the screen state is no longer restored. This can lead to inconsistent behavior for users who navigate extensively within the app. 
• To use this navigation API, we would need to save the specific position of the screen in the history stack, creating a major bottleneck and messy logic, not to mention that this would completely mess up the native back navigation for the user, creating an usability problem and therefore, the intended application usability would not be the same as a native app.

That said, I completely agree with your point about the risks of using internal APIs. This is why, as Daniel said in the previous reply, I included a strong disclaimer in the article, and why this Idea has been submitted: to advocate for a supported, official solution that eliminates the need for such workarounds.

Best regards,

Paulo Solipa