Document/allow usage without ember-data about ember-infinity

[hhff]

Hi @treyhunner ! It's going to be very possible after #32 is merged, as we'll give the addon user a way to pass in the promise generator for the infinityRoute.

We've also just exposed a hook ( updateInfinityModel ) that is overridable. It controls how new objects are added to the infintyModel, so if you're using vanilla Arrays of POJOs you can make it work too.

[treyhunner]

@hhff great, thanks! I will soon be using vanilla arrays and plain old JS objects because my data is purely static/read-only.

If I use POJOs before #32 is merged, should I specify an empty model and then use updateInfinityModel to push in my data on init/activate/etc.?

Thanks! 😃

[hhff]

yup - that should be fine. Gonna need to update #32 to be a currying style overridable "promise generator", so I'll be a sec before it gets in

[khirakawa]

+1, would be great to have a way to use this without Ember Data.

[john-kurkowski]

Looks like #32 merged? Still unclear from the README.md that Ember Data is required or not.

The infinityModel() method still makes explicit checks for it. Locally I've commented out the checks. Then I just have to make my service type and its response type look like an Ember Data Store to ember-infinity. It's tightly coupled glue code, but it's not too bad. The good news is, this library is almost data-layer agnostic.

[hhff]

Thanks @john-kurkowski ! Ember Data is still a requirement.

Given your work on this already - do you want to take a stab at completely de-coupling it?

[john-kurkowski]

Sure. You can see what I described in my allow-use-without-ember-data branch. Before I invest in a full blown PR, is it roughly what you were looking for?

[hhff]

Hi @john-kurkowski ! I'm just seeing this now - sorry! I watch a ton of repos and occasionally miss stuff.

This is exactly what I was thinking. Would you be able to make a PR for us to discuss this further?

[john-kurkowski]

I don't have time now, but I've set a reminder to look at this again in 1 month. I may have time then.

If you can't wait, do with my branch what you will!

[hhff]

Thanks @john-kurkowski !

[john-kurkowski]

Don't thank me yet. Things haven't let up for me. I unfortunately won't be getting back to this any time soon.

I'll leave my fork's branch available for the intrepid.

[hhff]

thanks @john-kurkowski

one of these days!

[xomaczar]

Any updates on supporting infinity scroll w/o ED.

[hhff]

hi @xomaczar - no, not yet. It most likely won't be done until someone submits a PR, or I need the feature myself.

If you'd like to take a stab at implementing @john-kurkowski's approach - I'd be down to accept that PR!

[xomaczar]

@hhff I did an initial spike, it looks promissing, however the only problem is related to ember-version-is addon which depends on ember-data module - specifically its VERSION attr. As you might imaging this creates problems for resolver when it tries to find ember-data in the consuming app. I was able to fix it in my app by providing an ember-data fake module - but it's a hack and not fit for general use.

[xomaczar]

I haven't pushed the code to my fork yet as I was trying to figure out a nicer way to handle it.

[xomaczar]

@hhff any ideas on removing/patching ember-version-is dependency on ember-data?

[hhff]

Hi @xomaczar - should be super straightforward to patch ember-version-isto not require DS: https://github.com/hhff/ember-version-is/blob/a4fe3d77827dfa4bf968486c19404a41aed47c21/addon/index.js

Failing that - I'm not against removing ember-version-is completely - we don't necessarily need it to do simple version checking.

Thoughts?

[xomaczar]

I am ok with either one. Although, the second option results in less code being bundled in.

[hhff]

yup - I'd be cool with the second @xomaczar ! I'm sure there's some libs out there that are already doing something like that we could jack

[tyreepace]

Hi - I was wondering what the status was regarding removing or patching ember-version-is? Would love to use this addon but don't want to have to create a hack to get around the ember-data check. Thanks!

[hhff]

hi @tyreepace - at the moment I'm focused on removing the coupling of Ember Infinity pagination control to the route.

IMO - the workload for Non-Ember Data is:

• Remove Ember Version Is for a lighter version check (we shouldn't need to ship the entire Semver lib with Ember Data)
• Move to a "promise generator" format (this will be easier after my current work)

If you'd like to take a stab at removing Ember Version is - please do!

[snewcomer]

@tyreepace @xomaczar Hey all! Just if anybody is curious, you can use your own custom data store now in the options hash. Another note, the query method you use needs to return a promise, which I think in most cases makes sense, but will remove that req.

#215

https://github.com/hhff/ember-infinity/blob/master/tests/acceptance/infinity-custom-store-test.js#L8

[xomaczar]

What API should the custom store expose? I see you using push and findAll - anything else?

…

On Apr 18, 2017, at 10:37 AM, Scott Newcomer ***@***.***> wrote: @tyreepace @xomaczar Hey all! Just if anybody is curious, you can use your own custom data store now in the options hash. Another note, the query method you use needs to return a promise, which I think in most cases makes sense, but will remove that req. #215 https://github.com/hhff/ember-infinity/blob/master/tests/acceptance/infinity-custom-store-test.js#L8 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[snewcomer]

@xomaczar you can define it with storeFindMethod in the options hash. Still need to document it.

https://github.com/hhff/ember-infinity/blob/master/tests/unit/mixins/route-test.js#L77