Unnecessary Smart Field Injection?

Help me!
1

We have a Smart Field that performs a relatively expensive, asynchronous operation inside its getter.

When accessing a Collection that is related to the Collection that contains the Smart Field, even though the Smart Field is not present in any Summary or Detail views, the getter for the Smart Field is accessed. It looks like forest-express's smart-field-values-injector is the reason for the call to the getter.

Is there a way to prevent Smart Field injection when it’s not accessed by any of the current views in the FA UI?

Thanks!

2

Hi @yeti182,

Could you please provide those informations so I can help you :slightly_smiling_face: :

  • What package are you using forest-express-mongoose or forest-express-sequelize ?
  • What is the version of this package ?
  • What is your project name ?
  • What’s the name of your smart field ?
3

Hi @vince - we’re using forest-express-sequelize @ 7.0.0. I’ll message you with other details. Thanks!

4

Okey weird, this is something we fixed not a long time ago :thinking:.

  • It’s happening only in record details ?
  • Could you please share the query parameters sent to the request replying with those smart fields :thinking: ?
5

Yes, it only happens when we access a related Collection’s record details, as far as I can tell.

In our case, it happens immediately after (and before subsequent calls to the admin API):

OPTIONS /forest/User/{UserID}

6

I need the GET /forest/User/{UserID}, at least the query parameters

7

No problem. Just messaged you the details! Thanks, @vince.

8

Hello @yeti182

Thank you for attracting our attention to the issue.

Unfortunately, we are currently not providing any configuration for retrieved fields.

I pushed your insight to our product team via our ProductBoard. They will look into it. I can’t give you an ETA for this feature to be implemented but be assured that we all work hard to deliver new features as fast as possible.

Have a nice day, and please let me know if I can help you in any other way :slight_smile:

9

Hi @anon90145840 - thanks for looking at this. Hmmm, I’m not looking for any configuration. Is it possible there’s a bug that’s causing the field to be retrieved even though it’s not currently being accessed in the FA UI?

10

It’s not a bug. Currently, when accessing the details of the records all the fields are systematically calculated.

I pushed the request to change this implementation to only request from the backend the fields that are currently used in the UI.

11

Ah - that’s not quite what’s going on, here. Let’s say I’m accessing a “User.” The FA UI is causing the getter of a “Books” SmartField (a Collection related to Users but not shown anywhere in the UI) to be called.

12

Okay, I see.

@vince shared with me the info you sent him.

I do not see any GET on /relationship route for users with the collection (let’s call it collection X) you mentioned to contain the smart field you are talking about. Does the collection X containing the smart field has a relationship with Users collection?

13

Collection X does not have a relationship with the Users collection. Thanks so much for looking at this.

14

Are you sure the smart action getter is called when you access the User records details?

Is it some specific User or all of them?

Does some of the related to User collections have a reference to collection X?

I am sorry to bother you wil all those questions, I am just trying to understand what is going on

15

No problem - happy to answer.

Yes, I am confident it’s called when accessing User record details. It occurs for all Users.

Yes, the User collection is related to Collection Y, which is related to Collection X.

16

Could you give me the name of the Y collection?

And also please copy the GET request on the /relationships/ route for collection Y when you access the User one?

17

Sure thing - I’ll message you the names and fresh logs for the GET requests.

Upon examination, Users is actually related to Collection Y, which is related to Collection Z, which is related to Collection X. Onion skins!

18

Hi @yeti182,

Just to check I got everything right, let me sum this up:

  • You defined a smart field, performing expensive and async operation on a collection (Z)
  • This collection is related to User via X/Y/Z collections
  • Rendering a user trigger the smart field computation on collection Z, causing the issue.

I looked into this, but I’m not able to reproduce the behavior you are having. I did 2 tests this morning:

  • A table User related to Project via an association table (UserProject). Project has a smart field named logger
  • A table User related to Project via an association table (UserProject) related to Organizations via an association table (ProjectOrganization). Organizations has a smart field named logger

In both of those cases, rendering the User table view/summary view/details view did not trigger any smart field computation.

If possible, would you mind sharing (In private if not possible here) some more in-depth structure/table relation/definitions for all these relations between X/Y/Z? Being able to reproduce the issue on my end would help :pray:

19

Hi @jeffladiray - I’m happy to provide in-depth structure and definitions. I’ll message you now.

20

To sum up what have been discussed:

The 2 collections causing issues here are related with a smart belongsTo relationship. On FA, belongsTo relationships are retrieved at the same time the main datas are.
Eg. User belongs to Project via smart relationship.
GET forest/user/someId will include the associated Project definition.

In this case, Project has some expensive & asynchronous smart field computation (Let call it expensiveSmartFieldComputation), causing the UI to feel laggy when displaying a User even if the expensiveSmartFieldComputation field is not displayed nor used in the page.

Sadly, it is not currently possible to choose if this smart field (from a smart relationship), needs to be computed or not, so I’m pushing this to our productboard.

On the other side, here are a few possibilities to handle such cases:

  • Replace the smart relationship by a SQL one - Normally the smart field should not be computed if not required in such a case.
  • Compute the value when needed, via a smart action for example.
1 Like