Filter and sort functionality on par with dom-repeat #123

Open
eibens opened this Issue Oct 17, 2015 · 21 comments

Comments

Projects
None yet
@eibens

eibens commented Oct 17, 2015

It would be great if repeating elements like iron-list had dom-repeat functionality. So is there a way to sort and filter items in an iron-list while preserving bindings? Or did you explicitly decide against it?

I think this is another use-case for my dom-repeat proposal in the main Polymer repository.

@blasten

This comment has been minimized.

Show comment
Hide comment
@blasten

blasten Oct 19, 2015

Member

I agree that the list should support filtering and searching in the same way as dom-repeat.

Member

blasten commented Oct 19, 2015

I agree that the list should support filtering and searching in the same way as dom-repeat.

@eibens eibens referenced this issue in eibens/studienplaner Oct 20, 2015

Open

Improve performance of course list rendering #4

@maria-le

This comment has been minimized.

Show comment
Hide comment
@maria-le

maria-le Nov 27, 2015

I also agree 100% we definitely need filtering and sorting capability for iron-list.

I also agree 100% we definitely need filtering and sorting capability for iron-list.

@deadlyfingers deadlyfingers referenced this issue in thaliproject/postcardapp Dec 7, 2015

Closed

Edit my postcards #70

@capitanbatata

This comment has been minimized.

Show comment
Hide comment
@capitanbatata

capitanbatata Jan 6, 2016

In the meantime a workaround is suggested in StackOverflow.

In the meantime a workaround is suggested in StackOverflow.

@kasperstorgaard

This comment has been minimized.

Show comment
Hide comment
@kasperstorgaard

kasperstorgaard Feb 4, 2016

In the meantime a workaround is suggested in StackOverflow.

For me, the main issue with the StackoverFlow computed filter workaround is that I lose selectedItem(s) when filtering like this.

In the meantime a workaround is suggested in StackOverflow.

For me, the main issue with the StackoverFlow computed filter workaround is that I lose selectedItem(s) when filtering like this.

@indolering indolering referenced this issue Feb 7, 2016

Closed

scrollToItem #194

@fakiolinho

This comment has been minimized.

Show comment
Hide comment

+1

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Feb 25, 2016

Contributor

The problem with the workaround list on StackOverflow is that iron-list resets its scroll whenever you delete a record.

Contributor

indolering commented Feb 25, 2016

The problem with the workaround list on StackOverflow is that iron-list resets its scroll whenever you delete a record.

@tstewart15

This comment has been minimized.

Show comment
Hide comment
@tstewart15

tstewart15 Apr 7, 2016

Is there a timeline on this feature? I don't see it on the Feature Backlog #10

Is there a timeline on this feature? I don't see it on the Feature Backlog #10

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Apr 17, 2016

Contributor

So how would iron-list be able to discern between events such as a record being deleted and a filter search being performed? In the former, you want iron-list to keep the scroll position but in the latter you want the scrollbar to be reset.

Contributor

indolering commented Apr 17, 2016

So how would iron-list be able to discern between events such as a record being deleted and a filter search being performed? In the former, you want iron-list to keep the scroll position but in the latter you want the scrollbar to be reset.

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Jun 20, 2016

Contributor

The canonical work-around for filter functionality has the unfortunate drawback of resetting the list scroll position whenever the list is mutated. I've created an enhanced workaround which scrolls back to the correct list position.

Edit: The above workaround has terrible performance on IE11 when used on my real-world elements (literally 3 seconds even though it scrolls okay otherwise). The only other way I can think to fix this is to update both the model and the view without triggering a recomputation of the computed filtered array. You can update the view using Polymer's this.splice to remove the item from iron-list's items array, which also also appears to remove it from the computed filter array (so make sure you are using one-way data binding!). Then use native array mutation methods to remove the item from the master array. Note that this is dangerous as one must update master array bindings manually.

Note to @blasten: when implementing this feature, try to avoid scrolling when the filtered list is mutated as it can run into performance issues :)

Contributor

indolering commented Jun 20, 2016

The canonical work-around for filter functionality has the unfortunate drawback of resetting the list scroll position whenever the list is mutated. I've created an enhanced workaround which scrolls back to the correct list position.

Edit: The above workaround has terrible performance on IE11 when used on my real-world elements (literally 3 seconds even though it scrolls okay otherwise). The only other way I can think to fix this is to update both the model and the view without triggering a recomputation of the computed filtered array. You can update the view using Polymer's this.splice to remove the item from iron-list's items array, which also also appears to remove it from the computed filter array (so make sure you are using one-way data binding!). Then use native array mutation methods to remove the item from the master array. Note that this is dangerous as one must update master array bindings manually.

Note to @blasten: when implementing this feature, try to avoid scrolling when the filtered list is mutated as it can run into performance issues :)

@mherbert71

This comment has been minimized.

Show comment
Hide comment
@mherbert71

mherbert71 Jul 21, 2016

Definitely something that is lacking in iron-list for sure.

Definitely something that is lacking in iron-list for sure.

@venicia

This comment has been minimized.

Show comment
Hide comment
@venicia

venicia Jul 29, 2016

Please consider this a higher priority, these functions should be built-in to this component. The performance we gain by using this component is so needed for our applications but we lost the other important functions which are to provide the user the ability to filter and sort the list.

venicia commented Jul 29, 2016

Please consider this a higher priority, these functions should be built-in to this component. The performance we gain by using this component is so needed for our applications but we lost the other important functions which are to provide the user the ability to filter and sort the list.

@sasivarnan

This comment has been minimized.

Show comment
Hide comment
@sasivarnan

sasivarnan Aug 12, 2016

Any update on this? ⌚️ 🚶 😟

Any update on this? ⌚️ 🚶 😟

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Aug 13, 2016

Contributor

To everyone asking for updates, this is a complex feature and blasten is overworked!

@blasten maybe you could outline how you would like to have this implemented and ask others to contribute.

Contributor

indolering commented Aug 13, 2016

To everyone asking for updates, this is a complex feature and blasten is overworked!

@blasten maybe you could outline how you would like to have this implemented and ask others to contribute.

@blasten

This comment has been minimized.

Show comment
Hide comment
Member

blasten commented Aug 15, 2016

Hi all! Let me ask @kevinpschaaf. The only reference is dom-repeat in Polymer. https://github.com/Polymer/polymer/blob/master/src/lib/template/dom-repeat.html#L301-L309

@dtruffaut

This comment has been minimized.

Show comment
Hide comment
@dtruffaut

dtruffaut Sep 5, 2016

I 👍 this feature request.

The "observe" attribute, able to look for items subproperties changes (https://www.polymer-project.org/1.0/docs/devguide/templates#filtering-and-sorting-lists), is really needed for iron-list.

I 👍 this feature request.

The "observe" attribute, able to look for items subproperties changes (https://www.polymer-project.org/1.0/docs/devguide/templates#filtering-and-sorting-lists), is really needed for iron-list.

@43081j

This comment has been minimized.

Show comment
Hide comment
@43081j

43081j Sep 8, 2016

If someone could have a go at this, that would be great. It should just be a copy (almost) of what dom-repeat does.

Being unable to sort is a huge problem, especially when dealing with firebase collections. Seeing as polymerfire splices items in one by one, any work around would result in triggering re-renders of the list per item.

43081j commented Sep 8, 2016

If someone could have a go at this, that would be great. It should just be a copy (almost) of what dom-repeat does.

Being unable to sort is a huge problem, especially when dealing with firebase collections. Seeing as polymerfire splices items in one by one, any work around would result in triggering re-renders of the list per item.

@indolering

This comment has been minimized.

Show comment
Hide comment
@indolering

indolering Sep 8, 2016

Contributor

@dtruffaut @43081j Please use reactions buttons and the star button to show your support, I don't want @blasten to have to lock this thread.

Contributor

indolering commented Sep 8, 2016

@dtruffaut @43081j Please use reactions buttons and the star button to show your support, I don't want @blasten to have to lock this thread.

@43081j

This comment has been minimized.

Show comment
Hide comment
@43081j

43081j Sep 14, 2016

One suggestion related to this, too, is that the functionality added for it be placed in a separate component.

Reason being, there are plenty of situations where we may want to sort/filter an array but maintain change notification/bindings. While I'm sure you could duplicate dom-repeat's logic to iron-list, it would not fix the problem for other situations needing this behaviour.

This would also mean dom-repeat could use the same element to handle this logic. Currently its very troublesome trying to implement this manually.

43081j commented Sep 14, 2016

One suggestion related to this, too, is that the functionality added for it be placed in a separate component.

Reason being, there are plenty of situations where we may want to sort/filter an array but maintain change notification/bindings. While I'm sure you could duplicate dom-repeat's logic to iron-list, it would not fix the problem for other situations needing this behaviour.

This would also mean dom-repeat could use the same element to handle this logic. Currently its very troublesome trying to implement this manually.

@tstewart15

This comment has been minimized.

Show comment
Hide comment
@tstewart15

tstewart15 Sep 14, 2016

Hey @43081j , I actually already submitted an issue requesting this type of enhancement: Polymer/polymer#3571

I created this component myself, and it works well, except when using it with iron-list, due to this Issue I filed against iron-list: #300

tstewart15 commented Sep 14, 2016

Hey @43081j , I actually already submitted an issue requesting this type of enhancement: Polymer/polymer#3571

I created this component myself, and it works well, except when using it with iron-list, due to this Issue I filed against iron-list: #300

@karthik-hande

This comment has been minimized.

Show comment
Hide comment
@karthik-hande

karthik-hande May 20, 2017

Even I am facing same issue while handling huge data

Even I am facing same issue while handling huge data

@phidias51

This comment has been minimized.

Show comment
Hide comment
@phidias51

phidias51 Jun 15, 2017

It might be easier to break this issue into two separate issues: one for sorting and another for filtering. The other thing to consider is that we already have specific array functions (this.splice, this pop, etc) to make it easier to manipulate arrays. Perhaps this functionality should be added there, and then reused in array-based components like iron-list.

Filtering might be implemented by simply having the internal template test for validity. Something like this...

  <iron-list ...>
    <template is="dom-if" test="_myFilterFunction">
     <paper-card ..></paper-card>
    </template>
  </iron-list>

This would obviate the need to change the model and maintain both a filtered and unfiltered model.

In general, how would sorting and filtering work in conjunction with firebase-query where results are returned not all at once but in drips and drabs? Would updates to the model trigger resorting/refiltering?

If the user changes the filter function, the new filter should then be applied, and the list should be re-rendered. This commonly occurs when the user changes filtering criteria like "filter by company where company == 'Google'".

It might be easier to break this issue into two separate issues: one for sorting and another for filtering. The other thing to consider is that we already have specific array functions (this.splice, this pop, etc) to make it easier to manipulate arrays. Perhaps this functionality should be added there, and then reused in array-based components like iron-list.

Filtering might be implemented by simply having the internal template test for validity. Something like this...

  <iron-list ...>
    <template is="dom-if" test="_myFilterFunction">
     <paper-card ..></paper-card>
    </template>
  </iron-list>

This would obviate the need to change the model and maintain both a filtered and unfiltered model.

In general, how would sorting and filtering work in conjunction with firebase-query where results are returned not all at once but in drips and drabs? Would updates to the model trigger resorting/refiltering?

If the user changes the filter function, the new filter should then be applied, and the list should be re-rendered. This commonly occurs when the user changes filtering criteria like "filter by company where company == 'Google'".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment