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

chore: encapsulate InternalModel usage #6246

Merged
merged 1 commit into from
Jul 12, 2019

Conversation

runspired
Copy link
Contributor

Depends on #6239

@runspired runspired added the code-review Tracks PRs that require a code-review label Jul 11, 2019
@runspired runspired force-pushed the cleanup/refactor-internal-model-usage branch from 59779f8 to 3796bd0 Compare July 11, 2019 08:24
@runspired runspired force-pushed the cleanup/refactor-internal-model-usage branch from 3796bd0 to 5cf43fd Compare July 11, 2019 23:45
@runspired runspired requested review from rwjblue and igorT July 11, 2019 23:45
@runspired
Copy link
Contributor Author

The ember-m3 failure is because M3 reaches into the InternalModelMap. We could provide a shim to preserve this but once identifiers work enters the cleanup phase that map will go away entirely anyway.

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a nice consolidation (into internalModelFactory and the like), makes the rest of the code a bit cleaner.

@runspired
Copy link
Contributor Author

Opened an issue in M3 to track the failure there: ember-m3/ember-m3#301

It's a test-only failure.

@runspired runspired merged commit 67affb0 into master Jul 12, 2019
@delete-merged-branch delete-merged-branch bot deleted the cleanup/refactor-internal-model-usage branch July 12, 2019 21:17
if (this.hasRecord) {
this._record.notifyBelongsToChange(key, record);
this._record.notifyBelongsToChange(key, this._record);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to pass in the second argument here, and in the case that we did, it would probably not be this._record but rather the value being set. Though that code path seems to have been removed, so we can just not pass the second arg

let normalizedModelName = normalizeModelName(modelName);

let internalModel = this._internalModelForId(normalizedModelName, id);
const normalizedModelName = normalizeModelName(modelName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recall a discussion in which we decided to only use const for constants, and not inside methods.

*
* @internal
*/
export default class InternalModelFactory {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fwiw, it seems a bit odd to me that something named a factory would also keep a cache of things.

Copy link
Member

@igorT igorT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments, I think the factory naming is the only real thing worth looking into, others we can look into as todos, other than the const discussion we should continue. 👍 on the refactoring

* @internal
*/
_internalModelForId(modelName: string, id: string | null, lid: string | null): InternalModel {
return internalModelFactoryFor(this).lookup(modelName, id, lid);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is still the old clientId concept it might be misleading to call it lid

internalModel.setId(id);
}

peekIdOnly(modelName: string, id: string): InternalModel | null {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

peekById maybe?

return internalModel;
}

build(modelName: string, id: string | null, data?: any, clientId?: string | null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we underscore the private methods like build?

}
}

modelMapFor(modelName: string): InternalModelMap {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we now refactor this to use this factory/map interface rather than having two things?

internalModel.notifyErrorsChange();
let internalModel = internalModelFactoryFor(this._store).peekId(modelName, id, clientId);

if (internalModel) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably assert if no IM here, that doesn't seem like a valid code path

let internalModel = internalModelFactoryFor(this._store).peekId(modelName, id, clientId);

if (internalModel) {
internalModel.notifyPropertyChange(key);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we assert or warn here if no IM

type: string;
clientId?: string;
id: string;
clientId?: string | null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be clientId?: string Or does that error?

pete-the-pete pushed a commit to pete-the-pete/data that referenced this pull request Jul 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-review Tracks PRs that require a code-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants