Using ListViews is hard

[tjvantoll]

I built Groceries as an ng2 web app (see https://github.com/tjvantoll/Groceries), and I’m trying to port as much of that code as possible to the Groceries {N} app.

One thing that struck me is just how much harder it is to build a list in {N}. For Groceries web I was able to trivially bind a <ul> to an array of objects. In {N} trying to accomplish the same task is considerably harder. Here’s a short list of things I’ve found that I have to do. (The full code is in this .html file and this .ts file.)

1. Use <item-template> and <template> instead of ngFor. I realize this is due to the difference in how our ListView works, but I thought it was still work explicitly mentioning.
2. Use the async pipe in my template.
3. Set the component’s changeDetection to ChangeDetectionStrategy.OnPush.
4. Bind to an rxjs/Observable instead of just a simple array.
5. Wrap the array in a WrappedValue so that {N} recognizes pushes to the array.

Really all I want to do is bind the <ListView> to a simple array like I can do in ng2 web apps, so if at all possible I’d love to see 2–5 above go away. <ListView>s are really common and I don’t think I’ll be the first person to be confused by these requirements. Removing them would also allow for more code reuse between {N} and web apps.

[vakrilov]

@tjvantoll You can still use the ngFor approach for the groceries app. The main difference is that the list-view is much more complex control that uses visualization and container recycling. However, for simple scenarios with smaller number of elements (e.x. when all elements are visible on one screen) there is no need for such optimization. You can see an example here.
That said, I agree that if you really need to use the list-view - maybe we can think of a way to make it easier. Any suggestions are welcome.

[tjvantoll]

Thanks @vakrilov,

The whole idea behind Groceries was to show how to implement common things people will need in their apps, and for that reason I really want to keep the <ListView> in there. I think it’s reasonable that we have extra steps in place as long as they’re well documented and we can explain why they’re there. If we truly can’t get rid of any of these other steps, I’ll need some help in the future explaining why they’re necessary. For now I’ll think about ideas of how we might be able to clean things up. Ideally we could use something like this, because it’s pretty true to the ng2 web syntax:

<ListView>
  <template *ngFor="#item of list">
    <!-- use #item -->
  </template>
</ListView>

... but I realize that’s probably not even possible.

[ligaz]

What if we introduce our ngFor like directive that will basically bind the ListView's items property to the Iterable and bind the current variable name to the $value in the template.

The Observable \ WrappedValue shouldn't be necessary if we monkey patch (mixin) the items source object with an EventEmiiter and emit the events we are expecting. We can emit those events using Angular's IterableDiffers and DoCheck abstractions.

[nsndeck]

The issue is fixed with commit #96. Generally new ListView component will support stock JavaScript array (both set directly or via RxjsObservable with async pipe). item-template tag is not needed anymore. There is one known issue with a very easy workaround - ListView does not render if placed directly on Page, but wrapping it in any Layout control will do the job. For more information about how to set and use ListView see ListView and ListViewAsync updated examples.

[tjvantoll]

Excellent! Can’t wait to try this out 😀

[dotdreaming]

+1. When is this feature going to be ready?

[rrcoolp]

Hi @tjvantoll ,

Are you familiar with the problem with NGFOR performance issues? I am finding when using NGFOR the rendering of lists is extremely slow...i.e. When you TAP and see the actual rendering complete (it can take upto 2 seconds) on a IPHONE 6....This seems quite unreasonable - which is basically what I am using across my APP - but finding the whole experience extremely poor....

I thought I'd point you to an issue I have opened - which hasn't had any major interest from the {N} team to look at - so thought to ask if it is something genuinely going wrong. or is it my approach. As theoretically speaking this should be quick (super-quick).

Check out the already opened issue here:
#500

PS: Check out the issue number (500) <---- internal error.....No coincidence here...lol

Thanks in advance.