-
-
Notifications
You must be signed in to change notification settings - Fork 130
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
Reduce duplication in route #88
Conversation
} | ||
|
||
this.set(this.get('_modelPath') + '.reachedInfinity', true); | ||
if(this.infinityModelLoaded) { |
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.infinityModelLoaded
is always going to be undefined here - it's not used anywhere else. We should use _canLoadMore
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.
we're checking _canLoadMore
as the first line of this method, this merely copies the previous lines 242:247 and 257:259
Thankyou @davidgoli ! I've been putting this work off for a while now. Thankyou a million! |
I'm traveling for the next week or so, so my response time may be a little slow, but I'll get to these issues ASAP. |
|
||
promise.then( | ||
newObjects => { | ||
this.updateInfinityModel(newObjects); |
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.
in my other PR, all of this could go into _notifyInfinityModelUpdated
Rewrote the route test to be more explicit about what failed when a failure happens. Also added an assertion to ensure the page number is correct (converted from |
It would be nice to standardize, when an asserted value is a boolean, to always use |
|
||
this._loadNextPage(); | ||
|
||
return false; |
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.
So I don't think it's actually necessary to return false;
from this method. The action itself does not return false, or return the value of this method, so it is probably unnecessary.
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.
personally, I think it should always return a promise
@hhff OK, I think I'm done with the code churn here, pretty satisfied with how it's factored now. Please take a look at let me know if there's anything here you'd like me to change or clarify. |
In addition, this PR incorporates the code change in #89 and supercedes that branch. |
@@ -102,6 +102,12 @@ export default Ember.Mixin.create({ | |||
*/ | |||
totalPagesParam: 'meta.total_pages', | |||
|
|||
actions: { | |||
infinityLoad() { | |||
this._infinityLoad(); |
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.
lets return here
I thought |
oh yes they are sorry I forgot that Ember 2.0 requires hooks to be defined for them to run... Ember 1.x did not - that's actually all good! I need to find time to do one last look over all of this (this week sometime - this is a huge refactor so I wanna be certain we're good) but thankyou so so much for this amazing work @davidgoli |
@hhff merged in master |
@@ -283,17 +278,61 @@ export default Ember.Mixin.create({ | |||
|
|||
@method updateInfinityModel | |||
@param {Ember.Enumerable} newObjects The new objects to add to the model | |||
@return {Ember.Array} returns the updated infinity model | |||
@return {DS.RecordArray} returns the updated infinity model | |||
*/ | |||
updateInfinityModel(newObjects) { |
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.
updateInfinityModel
is a public hook that current addon consumers are using to modify what happens when a payload is received.
By moving all of this functionality here, we're introducing breaking changes to users who are using this hook, and we're making the hook less useable.
Ember Infinity had over 250,000 downloads on NPM last month - this refactor is fantastic, but for such a simple lib we really can't be introducing breaking changes!
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.
Fair enough. I made this change because the goal is to call updateInfinityModel
not just after page 2+ but also on page 1 (see #90). I do think at a minimum we'll want to ensure infinityModelUpdated
gets called.
On that topic, updateInfinityModel
is a weird concept to me. What is it? Is it a hook? Is it a call to super? Particularly since this is a mixin, ideally the API would only use hooks that don't depend on a call to super, so users don't have to worry about return value or messing up functionality. The problem with the infinityModelUpdated
hook however is that it's called outside of the current run loop, so that bound params may not be updated from new results before the next page load is triggered. We could leave updateInfinityModel
and infinityModelUpdated
as is, but we'd still need a hook that lets you update the bound params within the same run loop.
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 agree that we shouldn't introduce breaking changes in this PR, but I would almost advocate for deprecating the current usage of updateInfinityModel
since it's inconsistent, and moving towards a new hook.
I'd also advocate for moving currentPage
into the new updateBoundParams
(or whatever) hook, and treating it as just another bound param. In our cursor-based infinity list, for example, the server doesn't even use the page number, it's just along for the ride.
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.
Not in this PR though of course
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.
Not sure why updateInfinityModel
ever returned anything, the return value isn't used in calling code... but I'll maintain that functionality
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.
we should also add a test to ensure that we preserve the functionality you're concerned about... it's not currently tested
Thanks @davidgoli - added a comment about a breaking change above. I also love all the work you're doing refactoring the test suite! That's going to close an issue we've got open for upping the code-climate. However because it's such a huge refactor of the main codebase, I'd prefer we kept the old test suite for this PR, and move the new test suite refactor to a subsequent PR. The old test suite hasn't let an regressions happen thus far, and I'd be more comfortable merging this if it's passing. |
@hhff re: the test suite refactor, sure thing, I did all of that work in its own commit so it should be easy to split that off into its own branch. |
@hhff Not sure what's going on with the build, looks like an issue with the ember-data remote? It's not a test failure. I suspect this is happening across all builds right now.
|
@hhff comments addressed |
|
||
return infinityModel.pushObjects(newObjects.get('content')); | ||
return newObjects; |
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.
on this first page, this array becomes the infinityModel that is returned on subsequent calls
Hi @davidgoli ! @mkorfmann & I did a review of this yesterday - we think it's so so good and we're so thankful for your work here! This is our only suggestion (for readability): This also means the
|
Thanks @davidgoli ! I think an Ember.run trigger like |
@davidgoli - also maybe checkout #77 - would that solve your problem in #90 ? We plan to add that shortly after your PR gets in 👍 |
@hhff I've made the revert as you requested, let's merge this PR then we can hash out fixes to #90 separately. I also made a documentation change so |
Also FYI I have that test refactor branch ready to go as soon as this gets merged! |
Good stuff! Just want to give a big 👍 for the work you're doing here @davidgoli :). BTW: Will #77 definitely help you resolving #90 and #89 or are you not sure yet? Peace out :) |
@mkorfmann I'm into discussing #77, I think it has some flaws (not least of which includes submitted with failing tests) but I think the general approach is ok. We can discuss on that PR though, is this one good to go? |
@davidgoli All right! Thanks for submitting sum feedback on #77 :). This PR must be good to go, I'm tempted too just merge it but I wan to get @hhff's absolution before. |
Sorry all - been travelling! ok @davidgoli - please squash the commits and I'll merge & release! this is |
@hhff squashed, but there's gonna be an extra commit, a merge from master, to resolve conflicts - FYI |
@davidgoli You can rebase upstream master to get it back to one commit 😄 |
extract call inf model hook extract infinityModelLoaded into a shared method reduce number of args to methods expand documentation remove variable use a finally minor style tweaks extract assertions from initializer; fix logic around loadingMore only use _finishLoad to set reachedInfinity use startingPage for initial request have first page & page 2+ share all code consolidate response handling in updateInfinityModel extract getter for infinityModel; label private methods consolidate buildParams code wrap all assertions in a single method consolidate & simplify don't need extra call to _finishLoad reorder & simplify const-ify all variables change name of _finishLoad for consistency don't load more results if _canLoadMore is false ensure that the page number is reset when the model hook is run again make updateInfinityModel not private document param Allow setting starting page as 0. fix it for canary keep compatibility with pre-canary restore updateInfinityModel revert updateInfinityModel as requested
what @kellyselden said! <3 |
@hhff got it... it's done, should be gtg |
will merge when it passes, you're a total monster @davidgoli |
thanks for the review @hhff ! got another one coming right up |
🎉 2015-10-20 23:13 GMT+02:00 Hugh Francis [email protected]:
|
This branch is motivated in anticipation of some upcoming bugfixes. The state of the route is difficult to reason about due to numerous duplications and minor inconsistencies between the initial load and page 2+ loads. This branch attempts to bring them into line with each other. No tests have been changed, because no behavior has been changed.