Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AsyncHasMany resolves to ArrayProxy, can't access reload/createRecord methods on resolved promise #1525

Open
1 task done
charlesfries opened this issue Sep 21, 2022 · 2 comments
Labels
types:core:data Something is wrong with the Ember Data type definitions types:core Something is wrong with the Ember type definitions

Comments

@charlesfries
Copy link

charlesfries commented Sep 21, 2022

Which package(s) does this problem pertain to?

  • @types/ember-data
"ember-cli-typescript": "^5.1.1",
"ember-source": "~4.7.0",
"typescript": "^4.8.3",

Using latest types

What are instructions we can follow to reproduce the issue?

With the recent changes to store.query and ArrayProxy the following snippet seems to be completely type safe and valid:

const posts = await this.store.query('post', {}); // resolves to AdapterPopulatedRecordArray
                                                  // in my case this promise resolution is happening in model hook and update is in controller action
await posts.update(); // OK, no any leakage

My issue arises when I try to do a similar operation with an AsyncHasMany relationship using these updated types:

const post = await this.store.findRecord('post', 1);

await post.comments.reload(); // OK, post.comments is AsyncHasMany
post.comments.createRecord(); // OK, post.comments is AsyncHasMany

const comments = await post.comments; // resolves to ArrayProxy
                                      // this is all that I return from model hook, so I don't have access to unresolved relationship

await comments.reload(); // DNE on ArrayProxy
comments.createRecord(); // DNE on ArrayProxy

Expectation: reload/createRecord access on resolved relationship
Reality: reload/createRecord do not exist on resolved AsyncHasMany relationship type ArrayProxy

My question is: am I errantly accessing reload/createRecord on this resolved relationship, or is this a typing issue?

If the latter, what does PromiseManyArray need to resolve to to retain these methods? This is the current type:

type AsyncHasMany<T extends Model> = PromiseManyArray<T>;

class PromiseManyArray<T extends Model> extends PromiseArray<T, Ember.ArrayProxy<T>> {
  reload(): PromiseManyArray<T>;
  createRecord(inputProperties?: {}): T;
}
@charlesfries charlesfries changed the title AsyncHasMany resolves to ArrayProxy--no access to reload/createRecord methods on resolved relationship in controller AsyncHasMany resolves to ArrayProxy, can't access reload/createRecord methods on resolved promise Sep 21, 2022
@chriskrycho chriskrycho added the types:core Something is wrong with the Ember type definitions label Sep 22, 2022
@chriskrycho
Copy link
Member

It’s likely a types issue. The types for these haven’t meaningfully changed in a very long time. It may be best to tackle as part of the work we’re about to spin up for publishing preview types directly from the Ember Data repo (analogous to what we’re doing in Ember).

@chriskrycho chriskrycho added the types:core:data Something is wrong with the Ember Data type definitions label Sep 29, 2023
@tschoartschi
Copy link

tschoartschi commented Jan 12, 2024

We are facing a similar issue. What is the correct way to work around this problem?

What I tried is the following. (I try to illustrate it with pseudo-code and the previous example):

export const fixMeEmberDataHasManyToArray = <T>(input: unknown) => input as T[];
export const fixMeEmberDataHasManyToHasMany =  = <T extends Model>(input: unknown) => input as SyncHasMany<T>;
const comments = fixMeEmberDataHasManyToHasMany<CommentModel>(await post.comments);

await comments.reload(); // DNE on ArrayProxy
comments.createRecord(); // DNE on ArrayProxy

But that's a little bit tedious 😬 on the other hand, we can "easily" identify the problematic code sections later if the problems are fixed. But of course, it's just a hack. Therefore it would be interesting to get the opinions of the pros on what to do

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
types:core:data Something is wrong with the Ember Data type definitions types:core Something is wrong with the Ember type definitions
Projects
None yet
Development

No branches or pull requests

3 participants