Progressive list rendering.

[brockwhittaker]

Change longer lists to render progressively in pieces rather than all at once in order to not block up the UI.

[smarx]

Automated message from Dropbox CLA bot

@brockwhittaker, it looks like you've already signed the Dropbox CLA. Thanks!

[showell]

Is this is a prototype in the strict JS sense, or is it just an object? We mostly just use closures for objects.

[brockwhittaker]

I named it as prototype since it will work like one from an outside perspective, but no. It could however be made into one -- which may be a good use case as this will be called many times perhaps and prototypes consume lots less memory (as only one copy exists in memory).

[showell]

I actually don't want to move toward having a prototype; my concern was simply that the name was a bit confusing. I prefer this style:

var self = {};

self.render = function () {....};
self.init = function () {...}
self.clear = function() {....};

[showell]

I'm not doing a thorough review on this yet, but, broadly, this seems like a really nice encapsulation, so I like the general direction it's heading. I'd be curious to see how easily it could be extended to work for the buddy list, which is a little more dynamic in nature (but at the end of the day, just has single-item deletes/inserts to deal with, beyond what you've already done).

[brockwhittaker]

It would be possible on the list to proxy the array protoype and intercept incoming requests to display, but then again we may as well just use vue, in which case this closure will still exist but without the append to DOM code (just the append to DOM array code).

[showell]

Can we change func to something like get_renderer? I also think we might want to separate two concerns here by having two functions:

memoization: make that be a function that simply keeps track of objects and has the 3/4 lines of code to make that happen
renderer: make that function be the object with the "guts" and don't have it track objects

[showell]

We should definitely have a unit-testing strategy for the main piece of this, which is the lazy list rendering. If there are small pieces of this series that can be merged ahead of time, we should do try to work on getting those in first, and then spend some time making this code really testable. Node tests can handle some jQuery interactions ok, but it might make sense to have some functions that are easily stubbable, which might change how the code is organized a bit.

[timabbott]

This is really cool, but I'm not thrilled with how this has been developed, in that the last commit has a bunch of work that we're going to need to semi-redo due to merge conflicts, and that probably just shouldn't have been started until we had merged the framework and were happily using it in at least 1 place. Oh well.

To try to expedite progress on this project, I merged the first 3 commits (all but actually using the framework), after tweaking a bunch of comments and other style things in the actual rendering implementation. It's mostly harmless in that the code is unused, but I expect we'll need to do more work to make it work perfectly; but this should make it easy to work on the various pieces separately.

I think next we should proceed with 2 things in parallel:

• Start merging few applications of this. @brockwhittaker can you extract out the changes for e.g. the "stream subscribers" UI and submit a PR just adding those? You only need to port the changes from the last commit (and given the changes, it might be easiest to just use the git show output for that last commit as a reference and redo things over trying to resolve merge conflicts). And then we can add additional widgets as we go.
• I agree that ideally we'd write a good test suite for this library. @showell is probably best equipped to do that work; maybe makes sense to wait until we have 1 application working before starting on it. I imagine there'll be some refactoring and cleanup as part of that process.

Thanks for working on this @brockwhittaker! I'm going to close this PR -- we can use new PRs for further work on this.

[showell]

@brockwhittaker @timabbott I'm happy to help on the unit tests. I agree that the merge conflicts were a bit unfortunate (my fault, although I felt the admin split took priority), and perhaps a more incremental approach would have been better, but this is also really exciting, so I look forward to more progress here.