Can't figure out how to access a nested array

Hi!

I need to copy some data from one app variable to another. Easy enough to do, except that the data is originally in a nested array, and I can’t figure out a way to get it:

The appVar activities_of_user is an item in repeat, and I need the events from the first activity_location.

The function composer claims that this should work:

But when I try to use the app, no data ever populates to “events_of_activity_location” property.

I have confirmed that there is data there to access.

Anyone have any thoughts?

@Mevi @Harri_Sarsa

I’ve been trying the exact same thing (nested ‘list of objects’ in a list) since yesterday. And even though the data is all there, i’m unable to access the properties.

It seems that ‘current’ works only at the top level. At the lower levels, ‘current’ is not even shown, and even if i use Formula to force a value to current, it doesn’t show up!

Probably a bug, or is there a different notation to use in such cases?

EDIT: Found at least one thing that i should be doing. Renaming the ‘repeat as’ value from current to anything else while making sure that they are also unique (within one structure). Still not working though.

“Property of data item in repeat” does show up for the double-nested properties, but it only shows the properties of the top-level repeat object.

Any ideas, anyone?
Any workarounds?

@S_MittalM,

I have enough other things to work on that I’m going to wait to hear from AppGyver rather than implement a workaround, but here’s something you could try:

If you have 3 levels of nesting ([Level 1, [Level 2, [Level 3]]]), create a variable (SecondVariable) and set it to current.Level2. Then create another variable and set it to current.SecondVariable to be able to get at that third level.

So trying to un-nest by a level.

I’m not sure what terminology to use to explain the concept better, but that’s might be an approach worth trying if you need a fix today.

Hi, these all should work in app, it’s just about finding the correct Formula that match your use case.

@Erin_Wagner your initial issue seems to be that you are trying to use LOOKUP to "event_of_activity_location" which doesn’t exist in your schema. Change that to "events" like in your schema and it should work. (If not, follow the advice below)

@S_MittalM Yep, if you have two (or more) repeats it’s better to name those. But you’re right, there’s some issues with direct bindings when repeating nested lists (I’ll make a bug report for this), but you can circumvent those by using Formulas. So let’s say you have this type os schema:

level1List [{
  level2List [{
    level3List [{
      level3Property
    }]
  }]
}]

Then for the first repeat you can use direct binding to level1List (and name it e.g. level1Repeat), but after that you need to use Formulas for the inner repeats: repeated.level1Repeat.level2List (as level2Repeat) and repeated.level2Repeat.level3List (as level3Repeat). Then you can bind the component properties directly to level3Repeat.level3Property.

One option more, if you just want to have one level3Property, you can use a Formula to bind to that directly:

LOOKUP(PICK_ITEM(LOOKUP(PICK_ITEM(LOOKUP(PICK_ITEM(pageVars.level1List, 0), "level2List"),0), "level3List"), 0), "level3Property")
2 Likes

@Tomi_Laakso Thanks for your reply!

Although, what did finally work for me was binding the component property to ‘repeated.level3Repeat.level3Property’ and not just ‘level3Repeat.level3Property’.

Maybe it’s a bug?

Also, in the same app process, i’m having another similar issue, with an input field repeated with a list of objects. Here’s the bug description, if you could have a quick look at this as well:

Thanks.

Yes, it’s repeated.level3Repeat.level3Property if you use Formulas. I meant direct binding and that’s why I mentioned only level3Repeat.level3Property, sorry for not being clearer.

The new issue sounds like it’ll be fixed in the upcoming runtime upgrade, which should be available within next few weeks. Currently you’d unfortunately have to circle around the issue in some other way

The new issue sounds like it’ll be fixed in the upcoming runtime upgrade, which should be available within next few weeks. Currently you’d unfortunately have to circle around the issue in some other way

In that case, I hope the runtime upgrade comes out sooner than later as the workaround is quite complex in this use-case.