UUIDs not working as row ids in DataTables 3

bg7

A while back I upgraded from DataTables 1 to 2 and ran into issues with row ids and escaping those strings. Allan and Kevin, you guys kindly helped sort through those issues.

https://datatables.net/forums/discussion/81238/inconsistent-results-looking-up-rows-by-unescaped-and-escaped-rowid-in-datatables-2-x-but-not-1-x#latest

The end result involved switching over to use UUIDs for all our row ids. I'm now in the process of upgrading to DataTables 3 and I'm running into problems using those UUIDs as row ids.

According to the documentation here:

https://datatables.net/ref/core/type/DataTable.RowSelector#string---#ID

it says:

"Unlike CSS this value does not need to be escaped"

Unfortunately that doesn't seem to be the behavior I'm seeing now. Instead I'm getting errors like this:

In the code it looks like it's trying to use it as a CSS selector (which won't work because it starts with a number):

Also, I was playing around with those row lookups in the console and discovered that '#0' seems to look up row 0 which was unexpected as I figured it would fail as well but apparently not. Using other numbers, e.g. '#00' and '#1', throw errors.

I'm not sure if I'm missing something or using the API incorrectly or if this is a DataTables bug. Any advice would be appreciated.

Thanks.

Ben

kthorngren

Using UUID's works in this test case:
https://live.datatables.net/gujocipi/1/edit

Note the row id property used is id and is defined using rowId. If you remove the rowId option then you will see the same error, for example:

dataTables.js:2362 Uncaught SyntaxError: Failed to execute 'matches' on 'Element': '#550e8400-e29b-41d4-a716-446655440002' is not a valid

If you aren't using the DT_RowId property, which is the default Datatables looks for, then you will need to define the property using rowId.

If this doesn't help then please provide a test case showing the issue.

Kevin

allan

Something must be running the uuid through filter() as a DOM selector. @bg7 are you able to link to a test case showing the issue so I can track it down?

Allan

bg7

Allan,

I did some more digging. It appears to be specific to cases where the row is missing. I had Copilot put together an example and an explanation:

---

https://live.datatables.net/veginizo/1/edit

The key failing case is probe #2 in the JS:

• table.row('#14c503bc-d2d0-4847-9559-973ebc65c696').count()

That UUID starts with a digit and is intentionally not present in the table.
Instead of returning 0, it throws:

Failed to execute 'matches' on 'Element': '#14c503bc-d2d0-4847-9559-973ebc65c696' is not a valid selector

For comparison in the same test case:

• Probe #1 (existing numeric-leading UUID) works
• Probe #3 (missing alpha-leading id) returns 0
• Probe #4 (missing numeric-leading UUID with CSS.escape) does not throw

So this seems specific to the missing-row path for numeric-leading IDs, where row('#...') appears to hit CSS selector parsing (matches) instead of a row-id lookup path.

---

Does that make sense?

Thanks.

Ben

allan

Hi Ben,

Many thanks for looking into it more. It is indeed exactly the same issue as before, in the same part of the code.

Basically, the code will attempt to do a fast lookup, and that is safe, but if nothing is found, then it attempts to check it as a DOM selector. I'm tempted to put a check in there to have it stop at that point if the selector is just an ID string, and nothing else (check would be for whitespace and colon characters I think).

Let me ponder that a little.

Allan

bg7

Allan,

Makes sense - I had a feeling it was failing over to the CSS lookup. I'm on board with having it stop instead of failing over if that seems reasonable. No argument with sleeping on that decision though.

Thanks.

Ben

bg7

Allan,

I think I've just about got our app updated to work with DataTables 3 now, minus this UUID issue. Any thoughts on if what you suggested about keeping it from failing over would work?

Thanks.

Ben

allan

I've put in a little trap to catch when a simple ID selector is being used, and it slips into the not found case. In such a case, passing it through the CSS selector engine isn't going to find anything and it can, as we've seen here, just result in an error, so I'm happy putting this for a patch release.

There are probably other places where you might run into similar errors - you might want to consider adding a simple letter in front of the UUIDs to make them valid CSS selectors, but I'm okay with this change to prevent that particular error.

Allan

bg7

Allan,

Thanks for updating it. Duly noted about possible other trouble spots. Anything in particular I should keep an eye out for?

I did consider prefixing the UUID with something static but was hoping to keep it clean if possible. We're using the UUID in multiple places and I'd prefer not to have to strip that prefix back off elsewhere if possible.

We've switched over to npm for all the DataTables libraries. Is this going to get rolled into an npm release shortly as well?

Thanks.

Ben

allan

Anything in particular I should keep an eye out for?

Just anywhere that it might be used as a selector. It will work specifically when using it as a DataTable row selector, and possibly that is all you will need, but beyond that - maybe! It depends on your application .

Is this going to get rolled into an npm release shortly as well?

Yes, I'm going to release 3.1.5 tomorrow morning.

Allan

bg7

Allan,

I loaded it up and it looks good!

Thanks.

Ben

allan

Awesome. Thanks for letting me know.

Allan