feature(discussions): More compact listing of lastest discussions

[ewinslow]

Removes several features to make the listing cleaner/more compact:

• All the actions/controls (like, mark-as-spam, remove-ad, etc.)
• The preview text (people need to write better titles anyways)
• Which group it was posted in (usually don't care)

Refs #18

[ewinslow]

Here's what it would look like:

Demo at https://development-ewinslow.c9.io/www.elgg.org/discussion

[juho-jaakkola]

The appearance of the new listing if fine.

The resources/discussion/index.php pretty much reinvents the wheel. I take it that it's like that just for the time of demoing the new appearance?

[ewinslow]

@juho-jaakkola Actually it was kind of my goal to experiment with a different way of doing layout. I would not have had as much freedom to experiment if I tried to use existing views/layouts.

In particular, there is a much stricter division here of logic from presentation than what we typically have. I build up all the necessary data before rendering any of the view such that rendering is just simply walking the object graph as needed. This approach would theoretically allow us to extract that logic to a data router that builds the graph on the fly, and the view need not be changed. I think extracting to a data router would be better than extracting to a controller per view, because it's more decoupled.

By "data router", I mean something along the lines of what Netflix's Falcor router does (https://netflix.github.io/falcor/documentation/router.html). Ours would be in PHP and synchronous of course, but basically the idea is that the router matches the path through the graph that you've requested and generates the data for you. It's a higher level abstraction that lets you stop worry about where the data comes from or how exactly to get it, and just request it. That's what you want for views, it seems to me.

The graph includes all translatable text, menu items, icon urls, etc. There are no services (elgg_echo, elgg_get_entities, ElggEntity methods) needed in the rendering portion (except for elgg_view, but that's a rendering service so that gets a pass).

WDYT?

[ewinslow]

Extracting this to a data router would mean:

• this information would be available to any view that needed it, and
• queries could be customized/optimized without overriding views

@mrclay might be interested in that last point, since we were talking about adding names to queries...

[ewinslow]

Oh, and flexbox. Wanted to use that. It's awesome

[mrclay]

Besides losing the hover menus, I generally don't like giving up the flexibility of allowing plugins to alter the list items, menus, etc. I suppose in the short term we'd break this down into simpler views that only render what's passed to them.

But if the goal is for views to announce their own data needs, we really should go ahead and figure out how to do this client-side. I'd say use something like Falcor/Relay but neither of those seems built to let plugins collaborate on the views.

I'd like to get my hands dirty with hypeLists. While it's not revolutionary and firmly in the web 2.0 "render all on the server" camp, Elgg may be stuck in that camp for some time and we could use some easy UX wins.

[hypeJunction]

I really do like that currently views provide a snippet. I don't want to be wasting time on a discussion that has a grandiose name, but lacks substance, usually first two sentences give a pretty good idea whether I want to go in or on. Also having controls right there, makes it easier to do things like filter out spam.

[hypeJunction]

@mrclay Let me know if you need any info re: hypeLists.

[ewinslow]

@mrclay

Besides losing the hover menus, I generally don't like giving up the flexibility of allowing plugins to alter the list items, menus, etc.

Lack of pluggability is merely a short-term wrinkle.

But if the goal is for views to announce their own data needs, we really should go ahead and figure out how to do this client-side.

Maybe, but let's worry about one thing at a time. Implementing Falcor's router in PHP would be non-trivial, but there is something already in the works, I'm told. Hopefully it's clear how views written like this will make it easier to try out Falcor when the time comes. In the meantime, this refactoring prepares our views to consume data from an API similar to Falcor. And regardless, it already provides a nice separation of concerns. This is all just an experiment, of course.

I'd say use something like Falcor/Relay but neither of those seems built to let plugins collaborate on the views.

Actually Falcor seems quite well suited to letting plugins collaborate. What makes you say otherwise? A few can walk the graph as deeply as it wants to find the data it needs. It just needs to be passed a root node.

Consider this approach merely a stepping stone. We'll need to organize our data like this eventually if we do switch to Falcor because we'd need to feed our data through a router.

@hypeJunction

having controls right there, makes it easier to do things like filter out spam.

Mark-as-spam is an important action but should it really clutter up the main discussion UI? Do you have any examples of other projects' UIs where mark-as-spam is so front-and-center? I couldn't find any. If you really like I can add just that one back. Would you miss any of the other actions we had?

Personally I'd like to hide actions like that behind a context menu or dropdown menu or something.

We could provide a triage UI that allows doing bulk actions, but I didn't think that to be necessary in this case.

[ewinslow]

Something else I'd like to do is get all the page shell chrome converted to this format as well. I imagine this would start purposely hardcoded for www.elgg.org (similar to the current page), and then we could refactor to make it pluggable again under the new rendering approach...

[mrclay]

Actually Falcor seems quite well suited to letting plugins collaborate. What makes you say otherwise?

Spoke too loosely. I just don't know enough about it. What's not clear to me is how the data would flow into the views. Does the whole page graph get passed down everywhere? Or does the router pass in only the needed data? If the latter, I don't see how we'd transition our current views to it. I think I'm just not seeing the end game here.

[ewinslow]

Does the whole page graph get passed down everywhere?

That is the mental model, yes. The router just makes this feasible because the values in the graph are lazily computed when requested by the view. On the client the whole thing is async, so a promise/observable is returned and the template system is responsible for waiting on the value to resolve before rendering.