Make WordPress Core

Opened 10 years ago

Closed 7 years ago

#28050 closed enhancement (wontfix)

Consider using Backbone Views for List Table updates

Reported by: wonderboymusic's profile wonderboymusic Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-patch
Focuses: javascript, administration Cc:

Description

List Tables are kinda clunky. (Duh!)

I just Quick Edit'd the first post in the list to have a date that is 1 month ago. Did the list table re-render? Not Really! Did the post move down the list? No!

If the list table class could return state via a toJSON()method, all that is left is rendering a master view template that contains subviews for each row.

Real time updates would be killer. Imagine real time searches...

I have been thinking about this a lot lately. If something sane emerges, it could be cool.

Change History (9)

#1 @kitchin
10 years ago

For plugin authors, post/page Quick Edit is already difficult to hook into, have to keep that in mind. (Even if you think you've got it, something comes up like <select> elements needing a setTimeout(...,0) trick to populate.) So making the whole table and navigation etc. features load by js would be tough.

I see two enhancements needed, one less js and one more js:

  1. Less javascript. Quick Edit only refreshes the single row, as you say. Sometimes a plugin has page/post list columns in other rows that really need an update after QuickEdit. So I propose a boolean hook that says "reload the table, don't refresh the row." When switched on, it would change the ajax "Update" button to a normal form submit ('get' unfortunately). That's only possible now by hooking into wp_redirect, after recreating a lot of the Quick Edit code and using a new button (or fooling the js by modding the DOM), as far as I know. A normal form submit would reload the whole table of course.
  1. More javascript. Populate everything dynamically, as you propose, but add a filter to disable it, so plugin authors can choose to avoid writing tricky js to replicate what they've already written in php for creating the view, and for validating saves. Maybe add js "hooks" to wp-admin/js/inline-edit-post.js by adding trigger's. I guess now you can do jQuery on()'s for the right events, but js triggers would be more explicit.

And like you say, this would be a worthy feature. Waiting for page loads is tiresome!

Last edited 10 years ago by kitchin (previous) (diff)

#2 in reply to: ↑ description @adamsilverstein
10 years ago

This is a grand idea! Great in concept and grand in scope.

Its something I have been thinking about as well and would love to see happen. I got as far as some mockups a while back and was both excited and overwhelmed at the possibilities.

One approach that could help make the task achievable would be breaking the components down and handling the switch to Backbone/Ajax piece by piece. The search part is straightforward, and Backbone-ifying the Bulk Edit/Quick Edit features would be a big win. Eventually we could add the list itself and address pagination, sorting and filtering.

Building in layers like this might also help us keep the rather solid no-js experience as well, with the eventual goal of a completely ajaxified experience.

Count me in!

Replying to wonderboymusic:

List Tables are kinda clunky. (Duh!)

I just Quick Edit'd the first post in the list to have a date that is 1 month ago. Did the list table re-render? Not Really! Did the post move down the list? No!

If the list table class could return state via a toJSON()method, all that is left is rendering a master view template that contains subviews for each row.

Real time updates would be killer. Imagine real time searches...

I have been thinking about this a lot lately. If something sane emerges, it could be cool.

#3 @ericlewis
10 years ago

This would be teh hotness.

#4 @helen
10 years ago

Could be good plugin material, probably would be better enabled by having a JSON REST API. :) I'm for anything that gets rid of wp-lists.js.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by paaljoachim. View the logs.


8 years ago

#7 @jtsternberg
8 years ago

As an aside, quick-edit/bulk-edit JS is woefully short on events to hook into, to the degree that monkey-patching is the suggested method for populating custom column fields: https://codex.wordpress.org/Plugin_API/Action_Reference/quick_edit_custom_box#Setting_Existing_Values 😩

So even a partial rewrite as suggested would be beneficial if nothing else but to make it easier for devs to hook into.

This ticket was mentioned in Slack in #core-restapi by adamsilverstein. View the logs.


7 years ago

#9 @wonderboymusic
7 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

There are better options for rendering views with the JS these days.

Note: See TracTickets for help on using tickets.