-
Notifications
You must be signed in to change notification settings - Fork 43
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
Feature/3.0.0 #56
Feature/3.0.0 #56
Conversation
05c59f0
to
fea98e1
Compare
fea98e1
to
03fd8cb
Compare
065cfe1
to
3107ae2
Compare
60b60cc
to
7106bb3
Compare
Co-Authored-By: Fran Casas <nflamel@gmail.com>
85a3485
to
94ecd88
Compare
84ccc45
to
6fbb666
Compare
expect(requestError).toBeInstanceOf(ErrorObject) | ||
expect(requestError.payload).toEqual({ foo: 'bar' }) | ||
expect(requestError.error).toEqual(null) | ||
expect(requestError.requestResponse).toEqual(null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what would happen if the exception isn't raised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand. We are explicitly raising that exception, it can't not* be raised. It would be raised with empty values in the worst-case scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌 I'm just worried that in case something made that code correct, the test would just pass.
model (attributes: { [key: string]: any } = {}): Class<*> { | ||
return Model | ||
} | ||
abstract model (attributes?: { [key: string]: any }): new(attributes?: {[key: string]: any}) => T; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 was is das?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
model
is an abstract method returning a generic T class constructor that should be defined in child extending this parent class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
omg, javascript syntax is getting out of hand haha
@@ -210,7 +200,6 @@ export default class Model extends Base { | |||
.then(data => { | |||
this.set(data) | |||
this.commitChanges() | |||
return data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason for it unless there's a concatenated then
statement.
const promise = new Promise((resolve, reject) => { resolve('payload') })
promise.then(payload => { return 'another payload' })
promise.then(payload => console.log(payload))
// output => 'payload'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the question. Do we want to keep the promise returning the response or not? This is a backward incompatible change I understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a backward incompatible change. The promise resolves with the HTTP response to all its hooked then
statements, regardless of the return statements of each particular then
callback.
This is what I'm trying to explain in the piece of code above ☝️ , notice that the second then
statement receives the original promise resolution result, and not the returned value of the first then
statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I see. I'm not sure the complexity added with withRequest
is worth it. I think this is actually also the reason why the switch from async/await
to raw promises (can't attach twice a then
just using await
).
@@ -284,15 +277,16 @@ export default class Model extends Base { | |||
this.set(this.applyPatchChanges(data, changes)) | |||
} | |||
}) | |||
|
|||
return data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
if (optimistic && this.request) this.request.progress = progress | ||
}) | ||
|
||
const { promise, abort } = apiClient()[method](this.url(), data, { onProgress, ...otherOptions }) | ||
|
||
promise |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are we using promises now instead of async/await?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been like this since the 3.0.0 alpha PR. Do not want to introduce more entropy in this PR.
@@ -239,7 +228,7 @@ export default class Model extends Base { | |||
@action | |||
save ( | |||
attributes?: {}, | |||
{ optimistic = true, patch = false, keepChanges = true, ...otherOptions }: SaveOptions = {} | |||
{ optimistic = true, patch = false, keepChanges = false, ...otherOptions }: SaveOptions = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this keepChanges
flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was introduced in the 3.0.0 alpha PR. From description:
Saving keeps changes that were made after the request started but before it finished (can be disabled by passing the option keepChanges = false).
And you reverted the change in this commit.
b96cd53
to
2a5c2db
Compare
WAT
keepChanges
behaviour.mustFind
andmustGet
methodsonProgress
request
attribute in Model. The attribute tracks the last request.