You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an Airtable base with both single-select and multi-select fields. These options can have over 100+ possible values. When creating a corresponding Airtable Create Node in n8n, n8n tries to be "smart" and store ALL 100+ possible values PER FIELD in EVERY copy of the corresponding node!
This causes huge browser UI performance issues with any sizeable n8n workflow -- to the point where clicking on certain other nodes becomes super sluggish. I believe this is because when n8n's "autocomplete" logic is loading, it dynamically POLLS every field, every option, in EVERY node -- every time you click to open ANY node! It's extremely laggy.
Example:
Instead of storing ALL the options within the node's JSON like:
{
"id": "Field With Very Many Options",
"displayName": "Field With Very Many Options",
"required": false,
"defaultMatch": false,
"canBeUsedToMatch": true,
"display": true,
"type": "array",
"options": [
{
"name": "Mandrill",
"value": "Mandrill"
},
...
We can DRASTICALLY speed up performance if we switch this portion of the JSON field to be represented as a type STRING instead of type ARRAY, like so:
{
"id": "Field With Very Many Options",
"displayName": "Field With Very Many Options",
"required": false,
"defaultMatch": false,
"canBeUsedToMatch": true,
"display": true,
"type": "string",
"readOnly": false,
"removed": true
},
I've attached two versions of a sample workflow which illustrates my point:
"Very_Slow.json" is about 2MB (!) in size and stores ALL the values locally.
"Much_Faster.json" is about 230K in size and treats all of these large arrays as just type string instead.
Try to open the Slack node and all the other Airtable nodes
Witness just how sluggish the browser UI performance is
Next, load up the "Much_Faster.json" into a new workflow
Witness how just much FASTER the browser UI performance is
Expected behavior
When polling Airtable field schemas, if the number of options exceed like 20+, then treat the field as type STRING and not type ARRAY and don't bother to store ALL the options.
Otherwise, you can't really create any sort of complex n8n automation using multiple Airtable nodes -- because the UI is way too SLOW.
By the way, this is likely NOT just an Airtable-specific ISSUE. I venture a guess that anytime n8n attempts to poll MANY options to store as an array type field across other nodes, the SAME performance issues will exist!
Therefore, this auto-type conversion from ARRAY to STRING likely needs to be applied to any node type (not just Airtable nodes).
Please let me know if this makes sense. Thanks!
Operating System
Google Cloud Run
n8n Version
1.39.1
Node.js Version
18.16
Database
PostgreSQL
Execution mode
main (default)
The text was updated successfully, but these errors were encountered:
Bug Description
We have an Airtable base with both single-select and multi-select fields. These options can have over 100+ possible values. When creating a corresponding Airtable Create Node in n8n, n8n tries to be "smart" and store ALL 100+ possible values PER FIELD in EVERY copy of the corresponding node!
This causes huge browser UI performance issues with any sizeable n8n workflow -- to the point where clicking on certain other nodes becomes super sluggish. I believe this is because when n8n's "autocomplete" logic is loading, it dynamically POLLS every field, every option, in EVERY node -- every time you click to open ANY node! It's extremely laggy.
Example:
Instead of storing ALL the options within the node's JSON like:
We can DRASTICALLY speed up performance if we switch this portion of the JSON field to be represented as a type STRING instead of type ARRAY, like so:
I've attached two versions of a sample workflow which illustrates my point:
"Very_Slow.json" is about 2MB (!) in size and stores ALL the values locally.
"Much_Faster.json" is about 230K in size and treats all of these large arrays as just type string instead.
Much_Faster.json
Very_Slow.json
To Reproduce
Expected behavior
When polling Airtable field schemas, if the number of options exceed like 20+, then treat the field as type STRING and not type ARRAY and don't bother to store ALL the options.
Otherwise, you can't really create any sort of complex n8n automation using multiple Airtable nodes -- because the UI is way too SLOW.
By the way, this is likely NOT just an Airtable-specific ISSUE. I venture a guess that anytime n8n attempts to poll MANY options to store as an array type field across other nodes, the SAME performance issues will exist!
Therefore, this auto-type conversion from ARRAY to STRING likely needs to be applied to any node type (not just Airtable nodes).
Please let me know if this makes sense. Thanks!
Operating System
Google Cloud Run
n8n Version
1.39.1
Node.js Version
18.16
Database
PostgreSQL
Execution mode
main (default)
The text was updated successfully, but these errors were encountered: