For some reason oh-repeater does not calculate the rangeStop expression below which is based on the length of a json string coming from an item state. Only after a page refresh the expression is calculated.
I have seen a similiar behaviour with oh-context where item states are also only available after a page refresh.
So just asking if this behaviour is explainable or a bug.
The funny part is the expression is calculated correctly in a Label component before and after the repeater.
app.4b7e0bc….js:2 RangeError: Invalid array length
at i.source (app.4b7e0bc….js:2:1140651)
at e.get (app.4b7e0bc….js:2:1440424)
at e.evaluate (app.4b7e0bc….js:2:1441420)
at i._async_computed$source (app.4b7e0bc….js:2:1443615)
at i.<anonymous> (app.4b7e0bc….js:2:1440252)
at e.get (app.4b7e0bc….js:2:1440424)
at new e (app.4b7e0bc….js:2:1440337)
at i.$watch (app.4b7e0bc….js:2:1455887)
at ja (app.4b7e0bc….js:2:1970761)
at i.created (app.4b7e0bc….js:2:1970107)
Well, definitely a bug, but possibly also explainable. I think you are correct this is the same as, or at least related to, the oh-context error. I created an issue for that bug to make sure it doesn’t get forgotten:
But as you can see from that brief exchange, there’s not yet a clear solution.
What’s strange is that you see this effect in the range properties but no one has ever reported observing a similar issue in any of the other repeater properties. I find it hard to believe that no one has every used an item state in a repeater property before this. Although, as I think about it, I’m not sure that I ever have. It might be worth further testing to see if this restricted to rangeStop or is more widely present in other repeater properties.
Only partially. The "-" result for the state is the error but it is the expected value given that there is an error: any time you try to get the state of an item in a expression and that item doesn’t exist, you’ll get "-" as the result instead of an undefined error. What was going on in your initial code is that the "-" result produced a value that could not be parsed as a valid array range and this threw a javascript error which halted all further repeater function so you saw the error in the first place.
With your new code, you are successfully preventing the "-" result from causing a javascript error, so repeater code continues to work and produces a first widget result with the default “1” rangeStop. The first thing that still isn’t fully explained is why that item state call should fail and return "-" in the first place. The second thing that isn’t fully explained is that because the repeater javascript hasn’t been halted by an error, after calculating the repeater with the fake value, it then goes on to recalculate everything a second time. But this time it can get access to the item state and so the calculation proceeds correctly and the widget is rendered as expected. It’s just that the first failure happens so quickly, it’s hard to see and it looks like the expression succeeds on the first try.
If you replace the testString with a string item on your system and the test value with it’s actual state then this widget should result in the three buttons with the string text.
If you then 1) save that widget, 2) return to the main page, 3) refresh the browser, 4) open up that widget again, you will see the long list of numbered buttons flash briefly before being replaced by the correct buttons.
In addition to demonstrating the situation I described above, this shows that the problem is not just with the range properties, because in this case the expression is in the source property.