looking for a way to let user define a custom field for a rule

[megantaylor]

i want to allow a user to create a rule for a custom field.

so the user experience would be something like:

click add rule

select something like "Custom" from the field select dropdown

this would generate a text input (for the custom field name), an operator dropdown, and a second text input (for the custom field value).

so the user could do something like "custom_field" = "some value".

desired output to jsonLogic would look something like {"==":[{"var":"custom.custom_field"},"some value"]}

i have played with the !group and !struct types but they don't quite do what i'm looking for.

is there a way to do this?

[Angelus1383]

I think this issue could be similar o related to #303

[megantaylor]

maybe, except i wanted to let the user define the key in a text input. i wound up not needing to do this, but it could be a useful feature for others.

[erickvieira]

I am facing the same use case. Would be awesome if I could set a flag to enable this behavior.

[thidasapankaja]

@erickvieira , @megantaylor if anyone any of you were able to get through this / figure this out?

[erickvieira]

@thidasapankaja imagine if you could create a member of Fields object without keys, just changing the type and a bunch of expected operators. Something like this:

const arbitraryFields: Fields = {
  foo: { /* Regular configuration according to docs */ },
  bar: {
    label: "Bar",
    type: "!map", // just an example,
    mapAllowedOperators: ["equity", "difference", "between"]
  }
}

Now, if user click on select menu's option "Bar", it will render a line with the following components in this order:

1. A text input that will accept everything that could sounds good for a property/variable name (alphanumerical characteres, no spaces and some especial chars as wel, like $, #, _, - etc...)
2. A select menu with 3 options: ==, != and Between
3. Another text input that can accept literaly anything and outputs it's value as a regular string

It makes sense for you guys? There are so many use cases where I could use something like this in past 2 years. It would be really awesome to finally see this implemented here. This is my main choice everytime.

Ps.: I've tried to implement this once, but it's specially hard to me deal with the mutability of maps 😜

[ukrbublik]

I assume that !map fields should have type of subfields in definition, right?
Eg. map with string values, or with number values.

[erickvieira]

... Eg. map with string values, or with number values.

Are you talking about the raw value of the property or about the key type?

• If that is the first option (assuming a Map<string, number | string> in typescript definition) so yeah, that makes sense too. But is it possible to ignore this or just set it's value as "any"? Assuming "Between" as an example: the output string (bar["name"] > "0"&& bar["name"] < "200") could be perfectly recognized as a valid command in vanilla JS. So why not assuming "any" as a possibility and simply output things as string?

• If that is the last one, so are you talking about arrays (assuming that a Map<number, any> is equivalent to Array<any>)? It could be nice too, but I don't really see the benefit on that.

[ukrbublik]

I'm talking about first option (Map<string, number | string>)
Using "any" is possible. Not really user-friendly, because different types have different corresponding operators and widget types. Eg. for map of dates it would be right to let user use date picker. And using between with strings can be OK for JS programmers, but confusing for end user. But if type is unknown, "any" is ok

[erickvieira]

That is why I've suggested include the property mapAllowedOperators it would specify wich opperators and consequently wich widgets can be used for that specific map super field. It could includes incongruent operators for certain properties? Maybe, but now the dev has the power to workaround it if possible. But it's important to keep in mind that if "!map" become a thing devs would probably want to create heterogeneous ones sometimes.

[kadinwu]

I am facing the same use case too, any plan to support it?

[kadinwu]

@ukrbublik i know you are busy on other features and bugs, but still want to confirm with you. We have strong requirement for this feature, are you going to support it? and what is plan? Thanks!

[ukrbublik]

I will prioritize this issue.
My plan is to extend support for type: "!group" to allow adding dynamic fields, not only ones described in subfields

[kadinwu]

I will prioritize this issue. My plan is to extend support for type: "!group" to allow adding dynamic fields, not only ones described in subfields

Thanks, great news for me. 👍
One more question, Not pushing you, what is timeline to implement it?