Suggested change to "Sort the table" task solution in "Modifying the document" article

[paroche]

In the "Modifying the document" article, for the last task "Sort the table" (https://javascript.info/modifying-document#tasks) the solution given is:

let sortedRows = Array.from(table.rows)
   .slice(1)
   .sort((rowA, rowB) => rowA.cells[0].innerHTML > rowB.cells[0].innerHTML ? 1 : -1);
table.tBodies[0].append(...sortedRows);

Which obviously works for the table provided. But it would not work for a table with no header or with a header with more than one row, or for a table with a footer. I would like to suggest a simple change to make the solution more flexible so that it can accommodate any type of header or footer situation:

let sortedRows = Array.from(table.tBodies[0].rows)
    .sort((rowA, rowB) => rowA.cells[0].innerHTML > rowB.cells[0].innerHTML ? 1 : -1);
table.tBodies[0].append(...sortedRows);

(Only code between 'Array.from(' and '.sort' is changed). The code with table.tBodies[0] instead of just table is about the same length, is maybe a little easier to understand (we get the array of rows from tBodies[0], sort it, then write it back to the same place), and is more flexible. And it could easily be adapted to handle tables with multiple table bodies.

[iliakan]

What if there are many tbodies? :)

[paroche]

Well, with the current code in the task solution, all the rows in all the table (except the 1st, thanks to the slice(1)) in all the tbodies, including the header and footer rows, would be sorted together and put in the first tbody, while any other tbodies would be rendered empty. Which is probably not what would usually be desired.

With the code I recommended, just as it is, the first tbody would be sorted properly and the others left as they were.

But if one wanted to handle multiple tbodies, it would be a simple matter to use the code I recommended, slightly modified to reflect indexing on table.tBodies, in a loop. e.g.

  for (let tbody in table.tBodies) {
    let sortedRows = Array.from(table.tBodies[tbody].rows)
      .sort((rowA, rowB) => rowA.cells[0].innerHTML > rowB.cells[0].innerHTML ? 1 : -1);
    table.tBodies[tbody].append(...sortedRows);
  }

Seems to work. BUT, to be fair, for my HTML I had a separate thead for each tbody, which according to MDN you can't do (only one thead per table, they say), but still, it does seem to work that way in Chrome, Firefox, Edge, Opera, and Safari (Windows version). If you were doing it the way the MDN documentation says you have to, with each tbody having the headers inside it as <th> elements within <tr> elements, you would then have to skip the 1st (or however many header rows there are) row(s) in each tbody, similarly to how it was done in the original solution (but in the tbody, not in the table as a whole). It's unfortunate because then you would have to know how many header lines there are, and it would have to be the same for each tbody (or things would get more complicated).

(BTW, I found that while multiple thead elements in a table does seem to work (at least sometimes), despite what one might have heard, things do still get screwy if you have multiple tfoot elements in a table. I realize this may not be news to you.)

[paroche]

Seriously? That doesn't seem right.

[iliakan]

If the table has only one tbody, is the solution wrong?

[iliakan]

Here I aim to provide the solution for 1 tbody. And then people can easily adjust it.

Did I miss something from your words? Please let me know.

[paroche]

As I initially stated, the current solution works for the example, with one tbody and one thead, one row in the thead, and no tfoot, but it wouldn't work very well if there was not exactly one row in thead, or if there were any rows in a tfoot element.

The solution I gave would.

Also, basically, I think it's more logical to take the rows to sort from the same element that you are returning them to (tbody), rather than taking them from the parent table, then appending them to the child tbody.

So for the above reasons I think it would be a little better.

From the point of view of just solving the example as given, without worrying about other possibilities, the main argument I would make is the logic one -- you want to have the sorted rows in tbody, you don't want any rows that are in table that aren't in tbody to move in to tbody, so why not just take the rows directly from tbody in the first place?

So I think taking the rows from table.tBodies[0], which is also where they will be appended after the sort, makes more sense. And I see no advantage to doing it the other way.

[iliakan]

• From what I see, the most common case is when a table has only 1 tbody. Even if the table has also footer/header, those are not sorted.
• Also, for this particular task, from the educational standpoint, it's better to have 1 tbody.
• Making things more complex does not increase the learning value proportionally.

Given all that, let's have the task with 1 tbody case. Should I add that condition to the task formulation?

[iliakan]

Once again, thank you for your ideas and healthy criticism ;)

[paroche]

I'm trying to be very clear, even redundant, but somehow I'm not making my point. I am not suggesting a solution for multiple tbodies (except yesterday, when I thought you were asking for one). The current solution WOULD sort any footer (if there were one), and put its row(s) into the tbody. Basically, it only works for the exact configuration of the example. And the change I suggested would not only be a bit more flexible in that regard, I think it would be simpler and more logical. And I think it is LESS, not more complex than the current solution, in the sense that it no longer needs the slice function.

[iliakan]

Oh, right. Sorry, hopefully now I got the point.

P.S. It could be easier for me to read your text if it were split into paragraphs. Somehow github just puts the whole text together.

Maybe when you're making line breaks, you make single breaks, not double breaks. Markdown merges such line breaks together, turning the whole text into a single huge line.

[iliakan]

I mean, not always, sometimes.

[paroche]

Good to know! I do look at the previews here in GitHub (when I don't, I'm sorry), and it seems OK.. But I can add more spacing. In general, I'm a fan of whitespace.