[Feature]-[72]:Add currentItem and currentItemIndex in JSON Form Arrays

[some-rando]

Is there an existing issue for this?

• [X] I have searched the existing issues

Summary

Having access to array indexes on a JSON Form widget would allow manipulating data or using Javascript functions to make decisions based on user input. Similar to the List widget currentItem or Select widget SelectWidget.selectedOptionValue, etc.

Why should this be worked on?

The JSON Form widget is super powerful and useful, but this issue is holding it back from its full potential.

In our specific case, I have a JSON Form widget displaying several items for saving URLs of public safety agencies. Fire Departments, Police Departments, other Emergency Services. A key difference for our use is that we also associate the URLs with certain areas (USA states, counties, cities, towns), and that it can be more than one area per URL. To keep things easier for my users I want to allow them to search for areas by name.

I'm using an Array Item on the JSON Form widget. Inside the Array Item are fields: State, Area Name, and Results. On the Area Name field I use an onTextChanged action to generate a Postgres query.

This currently works great, but only for the first Array Item since I can't determine which Array Item called onTextChanged, and I can't display the returned results in the Results field for the same reason. I've hard-coded index zero in JSONForm1.formData.Areas[0].State to get the results I want on the first Area. If I could get something like JSONForm1.formData.Areas[**currentItem.id**].State then I think things would work wonderfully.

In case it matters, I'm mapping the returned results from the query in the Results field, Radio Group type, within the Array Item. And I can only display the first result since I can't determine which Array Item index I'm on.

Front conversations

[Nikhil-Nandagopal]

@some-rando thanks for the great feature request! @dilippitchika @ashit-rath hopefully this should be simple to add

[dilippitchika]

Discussed with @ashit-rath, we are unsure about the complexity here and think we need a sprint dedicated fully to build this based on the current working of json form.

We will pick this when he has some bandwidth from the list project.

[lwelyk]

I would like to second this request, JSON forms are the only way to get user-managed arrays (users being able to add and subtract entries) into an appsmith form. The inability to have dependent fields within them means there are many data structures that just can't be replicated easily.

[dilippitchika]

@KyleWayneLaCroix can you please help me understand your use-case better with an example?

[oskarannas]

This would be very useful! I cant find any workaround for this as of now.

I have an array field, with a select field child. I need to use the "Server Side Filtering" for the select but that's not possible since i cant access the "filterText" property for the current active field.

[oskarannas]

Any updates on this one? :)

[dilippitchika]

Hello @oskarannas my apologies, we haven't been able to prioritise this yet

[dilippitchika]

Stats

Stat	Values
Reach	27
Effort (months)	0.75

[dilippitchika]

What is the job

Pre-requisite

• When i have an array field in the json form

Circumstance

• and i have to use server side filtering in the select widget in the array
• and i have to use the response of an input widget to filter data for my select widget

Need

• I want to be able to reference of the item and the widget accurately

So that

• I can reference it in the query for server side filtering in the select widget.
• I can reference the input widget’s data in my select query

Evidence

Requests in the issue

1. Comments in the issue
2. On mixpanel roughly 53 users have edited array fields, assuming 50% of them needed current item reference, we get approx - 27 users looking for this

Solution

Within list and table, we already have a way to refer to the item and the widget. We follow the same principles here but the approach has to be a mix of both list and table.

Devs will need access to all meta and derived properties within the widgets.

Today accessing derived properties happens via fieldState reference in the json form, while meta properties can be accessed using formData

Within the array items, we need a way to access the currentItem and the formData and fieldState in them.

Solution idea 1

For this we will enable the currentItem and currentIndex properties and currentItem will have the formData and fieldState internally, fieldState has to be expanded to contain other derived properties like select widget filter text etc. So here, the dev will have to reference using currentItem.fieldState.fieldName.filterText

Solution idea 2

currentItem will be similar to currentViewItems in the list widget and contain all derived and meta properties in one place and the developer can reference currentItem.fieldName.filterText to get the value of the filterText to be passed to the query.

Solution 1 looks much cleaner because the form data is separate from the field states making it easy to use the form data when necessary. This way is already established in the json form, making it local to it. However, this would need additional learning for people to use, because this method is different from list and table.

Open questions

Why did we divide it into formData and fieldState then? Why can’t fieldState contain the formData as well?

If it also had the references then the developer can reference formData for only the data and find all field meta and derived properties using field state. Should we think about adding the meta properties in the fieldState as well?

[ashit-rath]

@dilippitchika

Why did we divide it into formData and fieldState then? Why can’t fieldState contain the formData as well?

The initial thought process of dividing these two were:

1. formData can directly be used in queries and infusing into fieldState would make the user the filter the fieldState to get formData.
2. fieldState purpose was to give a way to alter the behaviour of the form fields based on different state of fields. This is a standard practice in general form libraries.

If combination of data and state is a very common use-case then it makes sense to put data in the state as well.

Solution

Solution 1 does look quite clean and can be relatable to the formData and fieldState in context of JSONForm., we can probably add the sourceData to it as well.

However I feel that the Solution 2 would help us align with the table and list. If tomorrow we decide to use actual widgets in JSONForm then the list widget will come into play and the learning curve would be less. But there are some nuances like a Select widget in list widget has selectedOptionValue as the value key but in the JSONForm's case we would keep it in value/data property. (Internally all form widgets have value property but it's not part of auto-complete).

[dilippitchika]

I agree, since these properties are only needed for accessing in other elements which is not always, we can go with solution 2 by default

[berzerkeer]

Looked into this , need to understand the solution around it a bit better. So will be picking this up in the next sprint.

cc: @dilippitchika

[Yacubane]

Is there any update on this issue?

[MohitDeshwal]

Not providing access to currentitem for nested array in JSON forms make them useless. Can't even show data in a select based on "filterText".

[deepthin3]

hi, Is anyone working on this issue?

[rohan-arthur]

@deepthin3 no so far, please go ahead!

[skjameela]

Could you clarify how currentItem and currentItemIndex will be exposed to the developers using JSON Form Arrays? Will they be available directly in the field's scope, or will developers need to use a specific syntax to reference them within array items? Additionally, could you provide an example of how these properties will interact with dynamic actions like onTextChanged or onOptionSelected

[skjameela]

@dilippitchika can you please clarify my question

[ashit-rath]

@skjameela This is feature is not currently in the pipeline so we cannot share you how this will exactly work as there are some nuances that needs to be explored. That being said, I wanted to understand if you are currently blocked on something because of this and we can provide you with an alternative. Also if you can share your use-case then it will help us immensely when we figure out the right experience for the feature.

Looping in @rahulbarwal and @carinanfonseca

[skjameela]

@ashit-rath no actually im trying to pick this feature to implement i got few questions that why approched you