Instead of cloning this.options again in handle-response.js, pass the options object from send-request.js. This way, pjax.state.options will also have the request options.
Instead of cloning `this.options` again in `handle-response.js`, pass the options object from `send-request.js`. This way, `pjax.state.options` will also have the request options.
Additionally, once this is merged, how do you feel about pushing out another release? I think there's been some significant improvements and fixes since v0.2.5 that would be great to get out there.
Additionally, once this is merged, how do you feel about pushing out another release? I think there's been some significant improvements and fixes since v0.2.5 that would be great to get out there.
Additionally, once this is merged, how do you feel about pushing out another release? I think there's been some significant improvements and fixes since v0.2.5 that would be great to get out there.
I agree. I think we should wait a few days to see if any other issues come up, and then we can push v0.2.6 and start working on v0.3.0/v1.0
>Additionally, once this is merged, how do you feel about pushing out another release? I think there's been some significant improvements and fixes since v0.2.5 that would be great to get out there.
I agree. I think we should wait a few days to see if any other issues come up, and then we can push v0.2.6 and start working on v0.3.0/v1.0
If you're explicitly disabling a test for a given code block with an inline comment, I think you should always re-enable it after to ensure that you don't accidentally lose coverage... or, alternatively, just disable the rule globally if you don't find it to be of any use.
In this case, // jscs:disable disallowImplicitTypeConversion should be paired with a // jscs:enable disallowImplicitTypeConversion somewhere or we should disable the rule altogether, IMO. Personally, I'd be quite happy to disable it, as I find !!element.name to be quite a convenient shorthand for casting to a Boolean.
If you're explicitly disabling a test for a given code block with an inline comment, I think you should always re-enable it after to ensure that you don't accidentally lose coverage... or, alternatively, just disable the rule globally if you don't find it to be of any use.
In this case, `// jscs:disable disallowImplicitTypeConversion` should be paired with a `// jscs:enable disallowImplicitTypeConversion` somewhere or we should disable the rule altogether, IMO. Personally, I'd be quite happy to disable it, as I find `!!element.name` to be quite a convenient shorthand for casting to a Boolean.
I agree it's useful to have the request available in this.state.options and in the options passed to the various Pjax events that are triggered, but perhaps the options object that is passed around should still be a clone to guard against accidental mutation of this.options by end users consuming the options object.
I agree it's useful to have the request available in `this.state.options` and in the options passed to the various Pjax events that are triggered, but perhaps the options object that is passed around should still be a clone to guard against accidental mutation of `this.options` by end users consuming the options object.
i.e.
```js
options = options || clone(this.options)
options.request = request
var tempOptions = clone(this.options)
//...
this.state.options = tempOptions
```
My bad. I just glanced quickly at it and I thought they were both disable rules, applicable to only the next line.
I'll revert that. Thanks for catching that.
My bad. I just glanced quickly at it and I thought they were both `disable` rules, applicable to only the next line.
I'll revert that. Thanks for catching that.
I much prefer semicolons. I think it makes the code easier to read, and prevents any ASI errors. Unless there is objection, I would like to add them all back in at some point, so I'll just leave this here for now.
I much prefer semicolons. I think it makes the code easier to read, and prevents any ASI errors. Unless there is objection, I would like to add them all back in at some point, so I'll just leave this here for now.
In case handleResponse() is called with this.options?
I'm not sure which scenario you're trying to preempt.
Do you mean:
```
options = options ? clone(options) : clone(this.options)
options.request = request
//...
this.state.options = options
```
In case `handleResponse()` is called with `this.options`?
What I'm trying to avoid is having this.options passed directly when events are triggered, as this PR changes trigger(document, "pjax:error", tempOptions) to trigger(document, "pjax:error", options), for example. Passing the options object directly could allow this.options to be mutated accidentally. The snippet you posted would prevent that from happening.
What I'm trying to avoid is having `this.options` passed directly when events are triggered, as this PR changes `trigger(document, "pjax:error", tempOptions)` to `trigger(document, "pjax:error", options)`, for example. Passing the options object directly could allow `this.options` to be mutated accidentally. The snippet you posted would prevent that from happening.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Instead of cloning
this.optionsagain inhandle-response.js, pass the options object fromsend-request.js. This way,pjax.state.optionswill also have the request options.@@ -40,8 +40,9 @@ var formAction = function(el, event) {var tagName = element.tagName.toLowerCase()Did you meant to remove this?
Additionally, once this is merged, how do you feel about pushing out another release? I think there's been some significant improvements and fixes since v0.2.5 that would be great to get out there.
@@ -40,8 +40,9 @@ var formAction = function(el, event) {var tagName = element.tagName.toLowerCase()Yes. The tests run fine without it, so it's not necessary.
I should have added it to #147, but I forgot to do it before I merged it.
I agree. I think we should wait a few days to see if any other issues come up, and then we can push v0.2.6 and start working on v0.3.0/v1.0
@robinnorth Is there anything else that needs to be done here before merging?
@@ -40,8 +40,9 @@ var formAction = function(el, event) {var tagName = element.tagName.toLowerCase()If you're explicitly disabling a test for a given code block with an inline comment, I think you should always re-enable it after to ensure that you don't accidentally lose coverage... or, alternatively, just disable the rule globally if you don't find it to be of any use.
In this case,
// jscs:disable disallowImplicitTypeConversionshould be paired with a// jscs:enable disallowImplicitTypeConversionsomewhere or we should disable the rule altogether, IMO. Personally, I'd be quite happy to disable it, as I find!!element.nameto be quite a convenient shorthand for casting to a Boolean.I agree it's useful to have the request available in
this.state.optionsand in the options passed to the various Pjax events that are triggered, but perhaps the options object that is passed around should still be a clone to guard against accidental mutation ofthis.optionsby end users consuming the options object.i.e.
Looks like an errant semicolon slipped through the net in a previous commit 😉
Sorry, I just realised that my code review was still 'pending'. Have published now so that you can see my comments.
@@ -40,8 +40,9 @@ var formAction = function(el, event) {var tagName = element.tagName.toLowerCase()My bad. I just glanced quickly at it and I thought they were both
disablerules, applicable to only the next line.I'll revert that. Thanks for catching that.
I much prefer semicolons. I think it makes the code easier to read, and prevents any ASI errors. Unless there is objection, I would like to add them all back in at some point, so I'll just leave this here for now.
I'm not sure which scenario you're trying to preempt.
Do you mean:
In case
handleResponse()is called withthis.options?I also much prefer them too, so that's fine by me.
What I'm trying to avoid is having
this.optionspassed directly when events are triggered, as this PR changestrigger(document, "pjax:error", tempOptions)totrigger(document, "pjax:error", options), for example. Passing the options object directly could allowthis.optionsto be mutated accidentally. The snippet you posted would prevent that from happening.