[Check for null values (empty vs (double quote) ]:

0
 After adopting version 11.4.0, we noticed breaking changes regarding the handling of empty values when passing an object as a parameter from a nanoflow to a microflow (and vice versa). Basically, the '' (empty string) value is now translated to an empty value (or vice versa). Do you have documentation for this new behavior? Is there any way to identify all occurrences where this regression might happen, especially in cases where we check object/property != ''?
asked
6 answers
0

Hi Luca Muraca

 

I seen this normalization behaviour.In Mendix 11.4.0, the runtime changed how empty string values ('') are handled when passing objects between nanoflows and microflows they are now normalized to empty (null) values.

I heared this from few others also, but it is safer to use always the empty check instead of ''.

answered
0

Jut to share that Mendix added a flag to avoif this kind of regression in 11.6.3


  • We added a configurable option Use new string behavior in the Runtime tab that controls how null and undefined values are handled for string attributes in the client. The new behavior (default for new projects) keeps these values as null to maintain consistency between nanoflows and microflows, while the old behavior converts them to empty strings. This option provides backward compatibility and gives developers time to migrate to the new more consistent behavior.


answered
0

Hi,

After updating to Mendix 11.4.0, the platform changed how empty string ('') and empty/null values are handled when passing objects between nanoflows and microflows. In this version, '' values are now normalized to empty (null) when objects are passed back and forth.

This means expressions like:


$Object/Attr != ''

may no longer behave the same, because the value may now be empty instead of ''.

What you should do

Don’t compare only to '' anymore

Use empty instead:


$Object/Attr != empty

or combine both if needed:


$Object/Attr != empty and trim($Object/Attr) <> ''

How to find all affected places

  1. Search your project for = '', <> '', != ''
  2. Update those expressions to use empty or trim() checks instead

This change was introduced to normalize string handling between client and server.

answered
0

All the points mentioned above are valid, but you didn’t take into account the effort required to find all the occurrences and the time needed to fix them without any automatic tool to search and replace the findings or assist the developer in fixing them. If you multiply this by multiple solutions with thousands of lines of code, I think it's too much just to “normalize” the behavior without any additional benefit (such as performance improvements).


answered
0

Hi Luca,

Yes, this topic has been a
long-standing and well-known topic. Developers who were aware of this issue have usually preferred to use $object/attribute != empty, because when $object/attribute != '' is used, the attribute can be null, which may lead to unexpected behavior. This became especially problematic with the conversions between nanoflows and microflows.


What Mendix has been doing in recent versions is trying to standardize this behavior. As you mentioned, they later introduced a setting to control it. In that sense, what you’re saying and what the others have said are not conflicting; they all point to the same underlying issue.


The real challenge is that there is no practical or automated way to apply this fix across a project. Because Mendix is low-code, the logic is encapsulated, and we don’t have a classic IDE-style global find-and-replace like in VS Code. On top of that, these comparisons are not only used in decisions. They can appear in many places such as page visibility settings, conditional logic inside Change Object activities, and other conditional configurations throughout the app.


Because of this, the most realistic approach is to use Studio Pro’s Edit → Find feature to manually search for patterns like != '', = '', or != empty. Since this can result in a lot of findings, the best way to handle it is to split the work across the team by assigning different modules to different developers so the effort is shared.


answered
0

A follow up question; I see different answers regarding the usage of trim(). Will it still work properly if you use trim($Object/Attr) != '' ? Or will you need to add the empty check there as well?

answered