Mendix and The Curious Case of Read-only List Values

It’s been a while. I got to work on some cool client (Mendix and front-end) projects. And yet… something was brewing. Maybe it was another caffeine overdose, but it started to frustrate me. The best way to cope with that frustration is to either touch grass, or write about it. I’ll start with the latter and maybe get to the grass in the end.

It’s time for a new rant.

Nope, it doesn’t involve pictures of kittens this time.

Let’s sketch a scenario:

As a front-end developer you have been tasked with building some kind of list widget for your client. They’d like to build a new data grid where they can edit values in some kind of excel fashion. Obviously you tell them that there already is a platform supported datagrid available and it would be unwise to build something custom. Nope, the client isn’t having it. They want yours, because you can make it more sexy (or something along the lines, clients have their reasons). Great! You gather the requirements, sketch out an idea and happily start building.

That is, until you come across this message in the documentation:

Due to a technical limitation it is not yet possible to edit attributes obtained via ListAttributeValue. EditableValues returned by ListAttributeValue are always readonly.

Huh? What? Why? Since when?

We can manipulate single attributes in a Mendix widget (being an AttributeValue), yet these manipulations in a list are not supported. (It's funny, because they still dare to call it EditableValue, but I digress.)

You bow your head in shame, go back to the client and tell them “well we can build something, but it might require a bit more time”. In the meantime you’re thinking “yep, another shitty workaround that needs to be built.”

Deja vu, anyone?

Obviously, you’re not the first one to have encountered this issue, so what’s the first thing you do? Fire up the Mendix Forum and start searching for it.

Here we come across a question about this: “How do I make a ListAttributeValue editable?“. Valid question. Unsatisfactory answer.

Remember my previous post where I rambled about Mendix making promises but not keeping them? Would it surprise you if I told you they made similar promises?

And this was… 3 years ago. Note that people keep asking for updates on this a year and two years later… Radio silence.

I tracked down the commit in the Mendix Documentation to exactly 3 years ago: you can find it here.

Now I could ramble again about working on AI bots being much sexier, but at this point that would be repetitive. Instead, let’s just call it lazy. Buried somewhere deep in a backlog that hasn’t been overlooked in the past 3 years.

A peek under the hood of the car.

Mendix states that you can’t actually access the underlying object when working with lists. Here’s the declaration of an ObjectItem:

/**
 * An object item returned by a data source. This object does not provide direct access to any data attributes, but it
 * can be passed to various API functions (like a widgets template).
 *
 * @property id The {@link GUID} of the object.
 */
export declare interface ObjectItem {
    id: GUID_2;
}

So, let’s fire up a Mendix project, open the console in your browser and console.log what you actually get:

What’s that underneath?

So we see the ID indeed, which is just a string. But wait…. What’s underneath? Is that? Yes… A Mendix object.

Now if we want to be very technical, it is a Symbol property. Here’s a link that explains such a property, but the gist of it is that it’s hidden. You can’t access it. Only by doing a bit of dirty coding (Object.getOwnPropertySymbols), you might:

There is access, but it’s painful

So what’s the big deal here? It’s the fact that the Pluggable Widget API uses plain Mendix Objects under the hood.

This object is described in the Mendix Client API. The Client API that has remained the same since Mendix 4, plus and minus some minor tweaks. In the client API it is perfectly described how to update an attribute value. This API, as far as I know, is still working right now (and by now I mean +8 years later at Mendix Studio Pro 10.10).

Here’s a link to the client API: https://apidocs.rnd.mendix.com/10/client-react/MxObject.html

Technically I can still make a Pluggable Widget that purely uses the Client API and be fully functional.

Note: This is some quickly whipped up code as a React hook that may not always work, but it indicates that we can still use the Mendix API

Are there some caveats? Yes. Keeping your local object storage in sync. Mendix loads its objects in a client side state and updates components whenever an object is updated.

Yet, there’s a client API for this as well. mx.data.subscribe still works after all these years (check the forum, there are questions about this +9 years ago). This function takes in a Mendix object (and optional attribute name) and fires a callback whenever an update occurs. You listen for changes and get a new value. Voilá, in sync.

This is me saying with so many words that Mendix already solved this. A very… long… time… ago. You use plain Mendix Objects under the hood, but somehow you can’t get List values to be updated?

If we have these functionalities in the Mendix Client API, how come they are still not in the Pluggable Widget API? A few years ago you could have said “it’s still relatively new, give it some time”. Yet, after this much time….

Can anyone at Mendix explain to me the “technical limitation” they haven’t solved in the past 3 years? Front-end development is technical, but it’s also not rocket-science.

On the roadmap

To conclude this rant I am going back to the above comment.

As a front-end developer I know development can be tedious sometimes. Even gray-hair-growing frustrating from time to time. Yet, it can’t be that hard to implement another basic functionality in your platform. I wouldn’t call it a quality-of-life functionality, but more of a “let’s make extensibility better” thing. Mendix prides itself on being flexible enough to extend the platform, yet they keep getting caught up in “over-promise and under-deliver”.

Building some new functionality can be hard, but this shit isn’t that hard. Not three years hard. I know, I’m being harsh, so I would like to make a very clear distinction…

I can’t harp on developers (being one myself), because they only serve at the whims of management and corporate roadmaps. I have always thought Mendix R&D was a bit devoid from having solid connections with the community, but I can’t blame the devs for that. That’s part of being in a corporate environment. You get siloed off from the Community that tells you what they really need.

That being said, I can definitely harp on product managers that make promises to a community and don’t keep them.

At some point, the phrase “it’s on the roadmap” means more or less “here’s a carrot, now shut up and we hope you forget about it”…

Clients might not be aware. They just get presented with workable, albeit shitty, workarounds. The developers on the other hand… They are the ones that make your platform a success.

My advise? Stop making promises you can’t keep. Also, retroactively look for the promises that were made and go deliver on them.

Back to touching grass

That’s the end of today’s Mendix related rant. If you’re looking for me (you can hire me building front-end related stuff like widgets), you can digitally find me on LinkedIn or my website. Physically I might be over-caffeinated, writing another rant (something about a duct-taped Mac Studio Pro), but most likely I’m just outside touching grass.

Photo by Ochir-Erdene Oyunmedeg on Unsplash