Ember 1.13 support

[jrhe]

Currently ember-table breaks with 1.13. I expect this is mainly because of glimmer.

Notes from tinkering:

The first thing which breaks are references to tableComponent as it seems it hasn't been injected when it reaches certain references. Replacing this injection code with an alias to parentView seems to get things ticking a bit further. Why is this mechanism used for providing a reference to the table component? It seems very hacky.

After this references to this.$() fail. $() only seems to be available after render, which makes sense as it get the jquery element for the current component/view. These seem to be fixable by delaying till after rendering of the component using Ember.run.schedule('afterRender', ...).

Doing these two things removes the errors but results in a non functioning table. The header row is rendered along with its contents but the contents aren't visible and I can't figure out why. The rows themselves aren't rendered.

[jimnanney]

Got a fork of your work so far? I'm going to go down the 1.13 path soon, and anything I can do to make this easier would be a good thing.

[shaunc]

@jrhe -- could the problem be the antiscroll stuff trying to read the "actual" dimensions of the thing its writing into, and not finding the element as it hasn't been drawn yet?

[jrhe]

I don't have a fork as it was more exploratory hacks rather than anything all that useful. It seems that the widths dont get propagated down to the right views resulting in some being 0

[goodwink]

I'm very interested in this as well as we're about to kick off an ember 1.13/2.0 effort. If there's a fork or something we can contribute to in order to help I will have several people available in the next few weeks.

[HenryVonfire]

Views won't be available in ember 2.0 and ember-table is completely base on views so there will be a lot of work ahead to switch from views to components. I've been playing around to see if I can do that easily but I'm facing a problem with the mixin register-table-component. Here is a schema of the things I've been able to convert into component successfully (the green boxes):

[joeruello]

@HenryVonfire Have you got a fork we can have a look at, happy to help.

@azirbel is there any preferred way for us to tackle this?

[jrhe]

@HenryVonfire When I was playing around I stripped out registerTableComponent and just used parentComponent aliases to hard code the references whilst I tried to figure out the rest of the stuff

[HenryVonfire]

@joeruello yep, here you have. You may find it a bit weird (It isn't very conventional) because every view has an equivalent component called the same way with an x at first. I did that to be able to replace specific views for components without losing the original code :sweat_smile:

@jrhe did it work for you? I tried that but somehow it didn't work for me (I probably missed something though)

[jrhe]

@HenryVonfire Yup it worked as much as I got something rendering but all the dimensions were being computed wrong so nothing was displaying. Ended up having to do some debugging work to get the right reference for various views. Probably a better way of doing this but things weren't working so I thought I'd brute force it. Created a method which gets triggered on didInsertElement and in the debugger trying parentView, parentView.parentView and so on till tableComponent was located.

[HenryVonfire]

I've managed to make the header works by passing all the properties needed so I've gone this far:

...but is extremely ugly to see the components filled with all those properties. I tried to wrap them into an object but it fails when it reaches the header-row (or better say the xheader-row component).

the branch can be found here

[azirbel]

Quick note - ember list-view is also working on this (https://github.com/emberjs/list-view/issues/245). We may want to rewrite Ember Table to use list-view, and use that to get glimmer support. This would also make sense since list-view is now a more official/well-supported project.

[shaunc]

I'm eager to see this working -- is there something I can do to help? is @HenryVonfire 's branch good to continue... or should I try to base on list-view per @azirbel 's suggestion?

[BryanCrotaz]

I'm looking at removing views in @HenryVonfire fork: see https://github.com/BryanCrotaz/ember-table

[gitowiec]

Hi, I wonder if there is any schedule to make Ember-Table compatible with Ember 1.13? Please, any date would be very appreciated, because based on it I could make decisions to stay or to go on.

[BryanCrotaz]

I'm working on migrating some of the ember-table ideas into ember list view. Anyone up for helping?

Bryan Crotaz Silver Curve

On 27 Jul 2015, at 09:53, Marek notifications@github.com wrote:

Hi, I wonder if there is any schedule to make Ember-Table compatible with Ember 1.13? Please, any date would be very appreciated, because I could make up decisions to stay or to go on.

— Reply to this email directly or view it on GitHub https://github.com/Addepar/ember-table/issues/337#issuecomment-125133056.

[jrhe]

@BryanCrotaz Might have some time next week.

What ideas in particular? Kris Selden (https://github.com/krisselden/list-view/tree/2.0.0) and Ray Tiley (https://github.com/raytiley/list-view/tree/2.0.0) are driving list view at the moment. It seems that their forks have the features required by ember-table. More info on their progress here: https://youtu.be/ltzN4v-ymo4?t=19m50s

@azirbel How would older versions be supported? I know you are keen to make sure there is at least some support for older versions of ember in ember-table. Moving to the new list-view is likely going to limit us to 1.13 because of the new list view API and the internals now relying on glimmer functionality.

[BryanCrotaz]

list-view allows a layout to be provided. I want to bring in the columns array and have a row component that connects cell components up to the column array. The column object (as in ember table) says how to render the cell, drives the width etc. The header cell component pushes into the column object and the table cell pulls from it.

On 27 July 2015 at 10:23, jrhe notifications@github.com wrote:

@BryanCrotaz https://github.com/BryanCrotaz Might have some time next week.

What ideas in particular? Kris Selden ( https://github.com/krisselden/list-view/tree/2.0.0) and Ray Tiley ( https://github.com/raytiley/list-view/tree/2.0.0) are driving list view at the moment. It seems that their forks have the features required by ember-table. More info on their progress here: https://youtu.be/ltzN4v-ymo4?t=19m50s

@azirbel https://github.com/azirbel How would older versions be supported? I know you are keen to make sure there is at least some support for older versions of ember in ember-table. Moving to the new list-view is likely going to limit us to 1.13 because of the new list view API and the internals now relying on glimmer functionality.

— Reply to this email directly or view it on GitHub https://github.com/Addepar/ember-table/issues/337#issuecomment-125140639 .

Bryan Crotaz Managing Director Silver Curve

[azirbel]

@jrhe we're starting to move away from the idea of continual support for older versions of Ember - it's just not manageable. I recently released versions for Ember 1.8 - 1.12 (you can see compatibility in https://github.com/Addepar/ember-table/blob/master/CHANGELOG.md). Ember CLI usage isn't really affected, but users of e.g. globals and Ember 1.9 have a choice: use Ember Table 0.6.0, maintain a branch and build their own Ember Table for 1.9, or upgrade Ember. I think these are all reasonable options for different cases.

(For anyone confused by this: we maintain a globals build in https://github.com/Addepar/ember-table/tree/master/dist. This build has to be compiled with the same version of Ember that client apps are using).

Our strategy moving forward will be to support the most recent version of Ember. It's ok to make breaking changes in the upgrade to 1.13 - seems like there's no way around it. If there is enough demand/need, we could consider maintaining a 1.12 branch and backporting bugfixes.

[phpdiddy]

Any rough timeline on when 1.13 support can be expected?

[bradfrosty]

+1

[nestortmj]

Same question -- any timeline for 1.13 support?

[shaunc]

@BryanCrotaz is trying to import ember-tables views into list-view. Meanwhile, @arzibel has suggested basing ember-table on list-view. However, I'm not so sure if that is such a good idea. List-view takes a 1D list and fills a 2D space with it, whereas ember-table has a 2D structure. However, I guess if the layout is flexible enough it would be possible to delegate the mechanics to a list-view layout. (The details of how the layout work still aren't apparent to me.)

I'm very eager to see this move forward. I've been poking into the 2.0 list-view implementation -- there is really a lot of work to be done there, and implementation seems to have stalled.

I have some time available - where would be best to help out? Should I continue with what @HenryVonfire started and @BryanCrotaz continued or does @arzibel want to push for a rewrite based on list-view?

[HenryVonfire]

I took a break on this because what @azirbel commented about using list-view (I have to take a deeper look into it to get a better understanding). It seems that list-view is still in the process of adapting to ember 2.0 and I don't know how long will take them to release the next version :disappointed:

[BryanCrotaz]

I've been contributing to ember list view as I believe that's the best starting point for a new ember table. I've made the 2.0 fork work with ember data as a start. Now thinking about migrating the column map into a list view layout object

[HenryVonfire]

@BryanCrotaz super! can you share your fork to take a look? :3

[BryanCrotaz]

On my phone so can't easily find it but click on the number next to Forks button on ember list view repo and you'll see it

[shaunc]

This fork of ember-collection https://github.com/shaunc/ember-collection.git has all tests passing for the "fixed-grid" layout (waiting on PRs for integration with official ember-collection -- the successor of ember-list-view).

I'd like to turn to getting ember-table working now. Has anyone made any progress on a list-view/ember-list based version?

... or should I fork from master, which hasn't been inactive it seems?

[BryanCrotaz]

I'm currently looking at list-view and realised that table is a wrapper around list-view. list-view only handles the scrolling section of the table. The header and footer are not part of list view.

I've created a new addon, ember-infinite-table, to be a 2.0.0 compatible ember-table, wrapped around ember-list-view. Join me there...

Maybe it needs to be wrapped around ember-collection instead?

[shaunc]

Ah - here ... yes it should be wrapped around "ember-collection" I think. I'll take a look. You are trying to support the ember-table interface but with a ground up implementation? I was just trying to decide weather to take that approach myself (thinking about, e.g. all the tooling, legacy examples...). I'll clone & roll up my sleeves. :)

[BryanCrotaz]

Skype discussion? I'm bgcrotaz

[cyril-sf]

Hi,

I'm the director of product engineering at Addepar.

Sorry for the delay, we have been busy with our product those past months. We are definitely interested in pushing that work. We just released Ember Charts as an Ember-CLI addon ( thanks @artych ! ) and are looking now to update our open source libraries to be compatible with the latest Ember versions.

We'd love to work with the community to get to that point. Let me know if you're interested in taking part in that project.

cc @HenryVonfire @BryanCrotaz @shaunc

[DanChadwick]

This is excellent! Thank you very much for your efforts. I am using the ember-table 2.0 PR look forward to progress on that version too.

@cyril-sf - Is it possible to comment on the future for ember-table? Will it continue as is, or do you foresee a re-write using ember-collection or ember-list-view for the lazy rendering? It would help us in our planning to peek under your wizard cap.

[cyril-sf]

@DanChadwick All of our open source libraries are really at the core of our product ( See that video https://vimeo.com/123359531 , it really starts 50 seconds in ) and want them as polished as possible. So we will definitely keep working on them. We believe in Ember and in open source.

Since they got created, a lot happened in the Ember world (Addepar was an early adopter) and we definitely know we'll have to rewrite them at some point ( think composable components here for example ).

We are in the process of planning that work, thinking how we can get the libraries compatible with the latest Ember, while we are upgrading our own app. We definitely don't want to slow down that process because we are not on Ember 2.0 yet. This is why I want to engage with the community to find the best possible solution.

[artych]

Let me know if you're interested in taking part in that project.

@cyril-sf, I'd like to participate, but mostly on weekends.

[DanChadwick]

@cyril-sf - The link for the video is instead to a forum thread about linking times. I would be interested in seeing your product. I would be happy to contribute, but I'm very new to Ember at this point. I'm still at the "poke at the fire with a stick until magic happens" phase. ;)

Do you see #374 getting committed, or do you envision a different path to ember 2.0 compatibility?

[cyril-sf]

@artych I'll ping you when we are ready, thanks for offering to help!

@DanChadwick I edited the link.

The PR from @artych seems to follow the good practices. We would need to invest a bit more time to confirm that. Nevertheless, the performance issue reported is a blocker as it's a selling point of Ember Table. We talked in the past about switching to ListView but it doesn't work w/ Glimmer ( see https://github.com/emberjs/list-view/issues/245 ). We most likely want to look at ember-collection as there's no reason anymore to rollout our own implementation. There are probably some more adjustments to make before merging it. And unfortunately, the library wasn't initially shipped with tests, so there will be some manual testing required too.

[billy-addepar]

This version of Ember table is no longer supported. If you want to continue discussion, you can open the issue on Ember Table Legacy. The new version of Ember table now supports Ember 2.0 & higher version