Migration to @forestadmin/agent - smart field badge is lost with the new agent

[Matteo]

Hello guys!
As you know we’re migrating from forest-express-sequelize to @forestadmin/agent.

We spot an unexpected behaviour of the forest UI with the new agent.
If it’s just a visualization UX issue, it’s not blocking, obviously. But we’re not sure if this may have other impacts, thus I’m asking to be sure we’re doing things correctly and to doublecheck with your help that everything is all right on our side.

So, thank you for your support. Let’s start…

We have a number of collections, and some collections have smart fields.

With the old agent we used to see in the forest UI a badge which identifies which fields are “real” and which are “smart”.
In the following screenshot you can see the form (inside “Edit Layout” mode) where the settings for the fields of a collection can be managed.

As you can see, whenever a field is a “smart” field, in the forest UI there is a “smart” badge aside the field name, to tell that it’s a “smart” field. Both in the fields section and in the relationship section.

In the new agent this is lost. The “smart” badge is not shown any more.

But as far as we can tell, everything works correctly.

At the beginning we had a deep check on our code, because we thought we were defining the fields in a wrong way. But we’re compliant to your documentation about computed fields.

Then we noticed that in the .forestadmin_schema.json, something changes, from old to new agent.

If in the OLD agent if we had a smart field in a collection, the .forestadmin_schema.json file would have the following content:

    {
      "field": "startLocationCoordinatesMap",
      "type": "String",
      "defaultValue": null,
      "enums": null,
      "integration": null,
      "isFilterable": false,
      "isPrimaryKey": false,
      "isReadOnly": true,
      "isRequired": false,
      "isSortable": false,
      "isVirtual": true,  <<<<<<<<<<<<<<
      "reference": null,
      "inverseOf": null,
      "validations": []
    }

Now, with the NEW agent… this is the very same code fragment from the .forestadmin_schema.json file:

      {
        "defaultValue": null,
        "enums": [],
        "field": "startLocationCoordinatesMap",
        "integration": null,
        "inverseOf": null,
        "isFilterable": false,
        "isPrimaryKey": false,
        "isReadOnly": true,
        "isRequired": false,
        "isSortable": false,
        "isVirtual": false,  <<<<<<<<<<<<<<
        "reference": null,
        "type": "String",
        "validations": []
      },

Then we tried to understand if this field is actually related the the smart fields. And we discovered that if we manually change the .forestadmin_schema.json file and we set isVirtual to true with the new agent, the “smart badge” is correctly shown in the field settings (in the forest UI).

We also observed that in the new agent source code (in this file) it looks like you always set isVirtual to false, regardless of the settings coming from our code base, both for the DB fields and for the “calculated” fields.
But we’re not sure about this… maybe we’re making a blunder

In any case, we’re just wondering if that’s the expected behaviour on your side. Did you deliberately remove the “smart” badge in the forest agent-nodejs, or that’s some kind of problem on our side, that we need to manage?

Actually, I still see the “smart” badges in forest admin user guide screenshots (see his page for an example) so we’re not sure about what we should keep in mind as the expected behaviour.

Thank you for a feedback,
Matteo

[Nicolas.M]

Hello @Matteo,

Indeed, as you spotted the notion of smart field has been removed from the new version of the agent.
The reasoning behind is that from frontend perspective a field is a field no matter if it is native or computed.
This way, all fields features (sorting, filtering, etc…) should be available to computed “smart” fields:
If you still require limiting or changing the behavior of those (because a computed field might not be sortable for instance), you will find how to do so in the documentation.

The isVirtual property is still there for backward compatibility purposes, but its value is no longer relevant.

Regarding the documentation link that you found, it is probably a screenshot taken with a legacy agent which hasn’t been updated.

I hope this clarifies.

@Nicolas.M

[Matteo]

Ok, thank you @Nicolas.M
I understand that this is due to the generalization introduced with the new agent. So you don’t see any more if a field is “smart” or not. Because all the fields are… fields
So I understood that in our perspective this is not due to something we’re missing.
And we’re fine with this doublecheck.

…even if the “smart” badge was a cool feature

Solution

Bye,
Matteo