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

Unable to send along extra options #6

Closed
timohermans opened this issue Mar 31, 2015 · 15 comments
Closed

Unable to send along extra options #6

timohermans opened this issue Mar 31, 2015 · 15 comments

Comments

@timohermans
Copy link

For my application I would like to send along extra options, like sorting / active / etc. filters. Now I implemented some extra logic for me in the route.js, but I guess creating an issue would be the right thing to do :).

@joshudev
Copy link

I had this issue today too. So I've forked and created a pull request. I handled this by adding a 'params' option which gets merged into the store.find request.

Pull request: #7
Fork: https://github.com/joshudev/ember-infinity.git

@timohermans
Copy link
Author

@joshudev Nice solution. However, wouldn't it be better to not use a params object and just extend the object itself?

@joshudev
Copy link

I did think about doing it that way, but then wondered whether it's cleaner to use a params object in case in future there will be options that need to be set that you wouldn't want getting passed on to store.find. I don't mind so much either way, but it's more explicit with the params object.

@timohermans
Copy link
Author

Haha I agree on that as well 😄 . Both has it's pros and cons. Let's see what @hhff has to say about it

@joshudev
Copy link

Yeah I'm just happy I got me an infinite scroll! It's funny that I went to log the same issue only 30 mins after you did!

@hhff
Copy link
Collaborator

hhff commented Mar 31, 2015

Hey duders!

Thanks so much for the PR! This is definitely something we need. Ultimately, all of the params will be passed into the store.find call anyway, so IMO there's no need to separate them then re-merge them.

I think we just need to jimmy-jangle the code so that it passes through the full object to the store#find method, but just pulls out the startingPage and perPage and sets them correctly in the final params.

Thoughts?

@joshudev
Copy link

That sounds good to me! Also I noticed the travis build is failing on my fork - I think I should have used Ember.$.extend instead of $.extend.. anyways.. so will you add this feature quite soon? I'm using my fork on the project I'm working on for the moment.

@joshudev
Copy link

p.s If you want me to adjust the fork and test, I am happy to do so.

@hhff
Copy link
Collaborator

hhff commented Mar 31, 2015

I'd love if you updated your PR @joshudev ! A test or two would be nice also.

Doesn't look like we'll need $.extend with this approach at all

@timohermans
Copy link
Author

Nice, this all sounds like music to my ears, haha. Thank you guys!

@bruce
Copy link
Contributor

bruce commented Apr 7, 2015

Came to post the same issue. Glad to see it's already underway! 👍 😄

@bruce
Copy link
Contributor

bruce commented Apr 7, 2015

Since it's been a few days, I've submitted a PR (#9) along the same lines with passing acceptance and unit tests. Comments welcome.

@joshudev
Copy link

joshudev commented Apr 7, 2015

Thanks @bruce. Looks good! @hhff - it would be great to have that merged in as soon as possible.

@hhff
Copy link
Collaborator

hhff commented Apr 7, 2015

Woo!

reviewing this now

@hhff
Copy link
Collaborator

hhff commented Apr 8, 2015

closed via #9

@hhff hhff closed this as completed Apr 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants