How to create node properties dynamically?

I am trying to create a node whose properties need to be dynamically displayed based on the results of an API call.

Currently the properties of a node are defined in a node statically like this

       properties: [
		{
			displayName: 'Operation',
			name: 'operation',
			type: 'options',
			options: [
				{
					name: 'Find',
					value: 'find',
					description: 'Find documents.',
				},
				{
					name: 'Insert',
					value: 'insert',
					description: 'Insert documents.',
				},
				{
					name: 'Update',
					value: 'update',
					description: 'Updates documents.',
				},
			],
			default: 'find',
			description: 'The operation to perform.',
		},
		{
			displayName: 'Database',
			name: 'database',
			type: 'string',
			required: true,
			default: '',
			description: 'MongoDB Database to connect to'
		},
		{
			displayName: 'Collection',
			name: 'collection',
			type: 'string',
			required: true,
			default: '',
			description: 'MongoDB Collection'
		},
]

Each of these properties is defined in advance and are static. Is there any way to load the properties dynamically? All of them? or some new ones after a previous property has been selected?

I know how to use the loadOptionsMethod param within a property to get a list of possible values like this

typeOptions: {
				loadOptionsMethod: 'getDatasources',
			},

But in my use-case, I want to create the properties themselves.

Is there any existing way to do this? If not, what could be a simple approach to make this work. I am open to taking direction and then making changes in the core.

1 Like

No, that is currently sadly not possible.

Honestly not sure right now what a simple approach would be. Never thought about it. But out of the top of my head I see the chance that it could cause some problems esp. when the node gets executed. At that point n8n has to know which parameters the node has. If that is not “hardcoded” like now, it would have to either:

  • load them also then again dynamically (would be slow, could cause problems if it would return different parameters than before to the UI, …)
  • would have to save them with the node in the workflow after they have been loaded (which would blow up the workflow a lot and would probably also cause some other issues but still better than the other alternative)

In general would it probably be a nightmare to debug and to create such nodes and workflows and the chance that they fail would be much higher than with “regular fixed nodes”. So not sure it it would be really worth the trouble right now.

For the sake of argument:

Option 1 seems to be relatively simpler to implement but the issue is of different parameters being returned at node execute time. Lets say if that possibility of different parameter responses went away by other means, what would be your take then?

PS: I am not asking for a feature request that you would have to implement.

Not sure if 1 would be much simpler than 2. Both are probably not incredible huge amounts of work and that complicated. But are for sure a bigger fan right now making sure that the parameters and defaults the user did see and set are the one being processed later.
Esp. thinking about security. If a parameter gets used to send for example data to. The user leaves it at the default value (lets say official Jira-API) but the function would then suddenly return a different default value (external Fake API) all the data would get send there.

Do not think the “different parameter responses” can be avoided. Is after all something totally out of our control. How it would work is that it probably would call some kind of function which returns the parameters to add. This function could then do an HTTP Request, dynamically create them depending on the time of the day, … or whatever.

I am also developing a node that requires dynamic properties, which I was able to do when making a Zapier integration for our API. I believe this should work, but I have not tried it yet. @Talha_Khan is this what you were referring too?

By Dynamic properties, I meant that the input fields of the node to be displayed can also be controlled via an API call. Not just the values. Based on the answers from Jan, we decided to take a little bit of a different direction and used fixedCollection type intead of options
fixedCollection can be hooked up to an API and display options dynamically. They are a bit different though. You go and click on a button called something like Add Option and then the keys/values can be shown.

2 Likes

Just came across the need for this regarding DB2 iseries (AS400 DB)

To call IBM i Programs (PGM) which for integration purposes is preferred than direct database access for obvious reasons you will not know before design time what the RPG program interface would be.

BUT get delivering n8n along the lines you are doing…good job.

Just wanted to say yes there are cases you would want to do this.

2 Likes

to add the cases: database manipulation node, that pre-fills databases, tables, fields, etc to make database manipulation easier

1 Like

@jan quote=“Talha_Khan, post:6, topic:1202”]
fixedCollection
[/quote]

Hello, I’m new here and I’m now facing pretty much the same issue as Talha,
I’m building a node with partial dynamic properties, some properties are fixed but some are dynamic based on the return value of an API call. is there a way to do it now as in 2022? If not, is there a work around?

Cheers

1 Like

Hello I am developing a node that also requires dynamic properties, If anyone has a solution please share.

A few developments in the last few years. Maybe you can try the resource mapper

And off the top of my head it’s worth looking at the Postgres node as that allows you to dynamically choose columns to set values for.

Thank you @pemontto