List's loadedState should be public to know what is lazy loaded

[agrabz]

Describe the bug

It's currently impossible to determine if a List is lazy loaded or not, which can cause crashes.

Steps To Reproduce

1. Have a scheme with relationships between parent and child
2. Run codegen
3. Fetch parent object
4. Try to access child object as below:
parent.Children?.compactMap {
                    $0.childName
                }
5. Get crash with: Call `fetch` to lazy load the list before accessing `elements`.

Expected behavior

Inside List+Model.swift
In the class: public class List<ModelType: Model>: Collection, Codable, ExpressibleByArrayLiteral, ModelListMarker {
The below variable:
var loadedState: LoadedState
Is set to
public var loadedState: LoadedState

So I can determine if it's safe to use the list or not like:

parent.Children?.loadedState == .loaded ? .compactMap {
                    $0.childName
                } : nil

Or even better would be to just keep it nil instead of this loaded state, however I understand that this would be a bigger change compared to the above request.

Amplify Framework Version

latest

Amplify Categories

API

Dependency manager

Swift PM

Swift version

5.9

CLI version

12.5.0

Xcode version

15.0

Relevant log output

<details>
<summary>Log Messages</summary>


INSERT LOG MESSAGES HERE

```

Is this a regression?

No

Regression additional context

No response

Platforms

iOS

OS Version

not relevant

Device

not relevant

Specific to simulators

No response

Additional context

No response

[thisisabhash]

Hello,
Please use the Lazy Load feature for loading the child elements. The documentation is available here:
https://docs.amplify.aws/cli/migration/lazy-load-custom-selection-set/

For example, call pattern will change like below:
https://docs.amplify.aws/cli/migration/lazy-load-custom-selection-set/#scenario-3-belongs-to--has-one-access-pattern

Previously

let comment = /* queried Comment through DataStore or API */
let post = comment.post

With the latest codegen

let comment = /* queried Comment through DataStore or API */
let post = try await comment.post

[agrabz]

Hello, Please use the Lazy Load feature for loading the child elements. The documentation is available here: https://docs.amplify.aws/cli/migration/lazy-load-custom-selection-set/

For example, call pattern will change like below: https://docs.amplify.aws/cli/migration/lazy-load-custom-selection-set/#scenario-3-belongs-to--has-one-access-pattern

Previously

let comment = /* queried Comment through DataStore or API */
let post = comment.post

With the latest codegen

let comment = /* queried Comment through DataStore or API */
let post = try await comment.post

Hi Abhash,

Thank you, but this isn't what I want. I don't want to fetch what I don't have already. I want to know if it's already loaded or not and apply logic based on that. Fetching without the proper logic is unnecessary load on the network. I don't see why loadedState is internal. If there's no specific reason, could you please make its getter public?

[github-actions]

This has been identified as a feature request. If this feature is important to you, we strongly encourage you to give a 👍 reaction on the request. This helps us prioritize new features most important to you. Thank you!

[agrabz]

With all the respect, I don't understand why this is a feature request and not a bug. This is a serious usability issue. The Amplify SDK allows me to use an object that should not be used and instead of throwing an exception it crashes the application.

[atierian]

allows me to use an object that should not be used and instead of throwing an exception it crashes the application.

Can you elaborate on that please - how are you using an object that shouldn't be used and how is it leading to a crash?
Please paste a full crash report if you have one. Thanks!

edit: I see it in your original post now. Taking a closer look.

[atierian]

We're looking at publicly exposing the loadedState.

In the meantime, you should be able to call fetch() before accessing it if you're unsure. If the List is already loaded, fetch() is a no-op. I recognize that's not very ergonomic because fetch() is async - we're prioritizing the work and will get back to you here with any updates.

[agrabz]

Wow, thank you Ian, I honestly didn’t expect this. Also my bad that I didn’t write at the beginning about the assertion failure. Yeah as you say async fetching can be an option or I’m also thinking about a different modeling strategy, but that is cumbersome. Thanks again for looking into it.

…

On Fri, 13 Oct 2023 at 16:46, Ian Saultz ***@***.***> wrote: We're looking at publicly exposing the loadedState. In the meantime, you should be able to call fetch() before accessing it if you're unsure. If the List is already loaded, fetch() is a no-op. I recognize that's not very ergonomic because fetch() is async - we're prioritizing the work and will get back to you here with any updates. — Reply to this email directly, view it on GitHub <#3286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATFLPZYBS2GKNZXMD5IUGKTX7FH5XAVCNFSM6AAAAAA5ZN7J6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRRGY2DGNJRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[thisisabhash]

@agrabz we've opened a PR to address this - we're working to put out a release soon. We thank you for your patience.

[agrabz]

Thanks a lot Abhash for the great news!

…

On Fri, 13 Oct 2023 at 22:13, Abhash Kumar Singh ***@***.***> wrote: @agrabz <https://github.com/agrabz> we've opened a PR to address this - we're working to put out a release soon. We thank you for your patience. — Reply to this email directly, view it on GitHub <#3286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATFLPZ3CMOD2ZEOLSA5MUYDX7GOHFAVCNFSM6AAAAAA5ZN7J6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRSGE2DIOJVGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[atierian]

The isLoaded property was added in 2.21.0 released yesterday (10/20/2023).

Note, we kept the assertionFailure in there when accessing without fetching first. This only crashes in debug builds (-Onone); it won't crash / returns an empty array in release builds (-O).

Thanks again for reporting this.

[agrabz]

Thanks a lot again!