Non-Obvious Quirks / Tips & Tricks (purely from my own experience)

Call them features, quirks, bugs, or oversights… :stuck_out_tongue_closed_eyes: Regardless, having finally finished my app (!!!), I’ve compiled a list of the least obvious/intuitive stumbling blocks I’ve encountered with AppGyver. It is not meant to be a list of complaints (all of these have been discussed and are or will be reported as bugs and admin has been super responsive), but rather a helpful cheat-sheet to save other members of my team (and now you!) a lot of time troubleshooting.

Appgyver Quirks / Tips & Tricks

I. Complex

  1. When setting a variable or variable field from a single field of a data variable, use the “Function” binding type (e.g. manually type “data.shipData.fields.seat1.stringValue”) instead of the “Variable” binding type (point & click). Otherwise AppGyver inexplicably tries to fill in the entire data variable (not just the field).
  2. Repeated elements – and anything inside them, e.g. nested repeats – will only refresh if there has been a change in the data source they’re being repeated from. Which means:
    (a) If there’s something inside a repeated element that you want to refresh, you have to make an arbitrary change to something in the topmost repeated data source in order for the change to show up, and
    (b) In your logic flow, you will want to refresh the data source of the interior/lower-level repeated elements before you refresh the data source of the top-level repeated element.
  3. Images without a set height will only shrink when the window size changes, but won’t get larger when the window is expanded again. To get around this, you need to set a height, e.g. as a % or as a function of the window height. (If as a %, this may also mean you need to set the heights of their containers, and so on… CSS sizing is super confusing so good luuuuuuck!)

II. Simple

  1. “Alerts” terminate the logic flow, despite having an output. (The output doesn’t do anything.) If you want to continue the logic flow, do so from the prior node and make the alert a separate offshoot.
  2. The “viewport size” variable is only set once, on page load; if you resize the window it will not change.
2 Likes

Thanks for posting these!

We should be getting rid of the I.2 “feature” with the runtime upgrade soon :slight_smile:
As for I.1, I’m not entirely sure if you’re referring on how to set a variable property instead of the variable value? The intended design for this is indeed that you will either bind to variable properties or set an entirely new value. Do you think it would be helpful to have a small video demonstrating this and explaining why this is? :slight_smile:

II.1 is a bug that is on the backlog to be eventually fixed.

I.1: sure! I’ve attached screenshots showing what works vs what fails. I don’t think this is a question of binding vs setting a value; instead it’s a question of specificity. (Like, if the rule is, “You can’t bind a property of a page variable to a property of a data variable,” then that should be explicit and it shouldn’t even appear as an option.) But if I’m wrong then I guess I do need an explainer!

A) Fails:

B) Works:

I.2 just saved me! Thank you

1 Like

Oh, that seems like a bug. However I wasn’t able to replicate the issue.
Can you provide here an example of the json data in me_countryData?
Also is it a collection or a single type variable?

Sure thing – it is a single document:

{
    "name": "projects/[FirebaseID]/databases/(default)/documents/instances/beta2/country-data/canada",
    "fields": {
        "equipment": {
            "mapValue": {
                "fields": {
                    "propellors": {
                        "integerValue": "0"
                    },
                    "hull": {
                        "integerValue": "0"
                    },
                    "sonar": {
                        "integerValue": "0"
                    },
                    "jammer": {
                        "integerValue": "0"
                    },
                    "tank": {
                        "integerValue": "0"
                    },
                    "shield": {
                        "integerValue": "0"
                    },
                    "radar": {
                        "integerValue": "0"
                    },
                    "autopilot": {
                        "integerValue": "1"
                    }
                }
            }
        },
        "ship": {
            "stringValue": "suncast"
        },
        "money": {
            "integerValue": "2001"
        },
        "course": {
            "stringValue": "bear"
        }
    },
    "createTime": "2020-11-02T23:25:02.975808Z",
    "updateTime": "2020-11-02T23:25:02.975808Z"
}

I’ve run into I.1 as well - and it took a while to figure out. It’s a known bug: https://tracker.appgyver.com/bug-reports/p/accessing-nested-data-variablecurrent-properties-only-works-via-formula-not-the

1 Like

Ooh good find! Very glad to see it’s being addressed in the new runtime.