Plugin Builder: SSA Fields of Type "Date" Come Across as Strings

I’ll report this as a bug (as I’m pretty sure this is new), but in Server Side Actions, inputs of type date are coming across as STRINGS, not Dates. At least, this happens if you pass “Current Date/Time” to a date type input of an SSA.

Here’s an example. Here’s a date field input to an SSA:

And here we feed a date to that input in the editor:

And what we find if we inspect this “date” is that it comes across as a string, not a date.

I discovered this as expected time math was not working. You can see both things here. Here is our return code:

You’ll see that the return field for time_to_execution should come back as a number (the subtraction of one date from another, but it returns null). The reason that returns null is that the type of properties.start_time is not a date, but a string.

Here’s what happens at runtime:

You’ll note that Time to Execution comes back as null because we have attempted to subtract properties.start_time (which is a erroneously a string, instead of a date as specified) from instance.data.init_time (which is a date).

That properties.start_time is a string is confirmed by the fact that Start Date comes back as “string” (because what we are sending back here is typeof(properties.start_time), which should report "object", but properties.start_time is erroneously being sent as a string.

This bug is NEW, BTW, as I’ve built plenty of other SSA’s that take date inputs. At present, they must all be malfunctioning due to this bug. (Luckily, none are used in production.)

There are other bugs in the plugin builder for SSA’s, by the way, In particular, the get() method of List objects does not behave as the get() method of List objects in element plugins. The .get() method of a List is supposed to take (start, length) as arguments. (And that’s how it’s documented.) However, it turns out that, at the moment, List.get(start_index, length) is interpreted as List.get(start_index, end_index_exclusive).

That is, if you are trying to get the second element of a List, you should do:

List.get(1, 1) // <-- get me 1 item from the List object, starting at position 1

But this will return null (again, in SSA’s – in elements this works as expected).

Instead, what works is:

List.get(1, 2) // <-- this successfully retrieves item 1 because this method is (erroneously) expecting a start index and a non-inclusive end index. So this says, get me the items in the List starting at 1 and ending before 2.

Now, perhaps this second bug is forgivable because it’s almost a certainty that I am the first person ever in the history of ever to work with List.get() in this manner in SSAs.

However, that the Bubble team didn’t notice this bug is due to crappy testing. You will note that the edge cases for List.get() will falsely assure you that List.get() is functioning correctly and according to documentation.

That is, if List.get() works as documented, these calls will work as expected:

List.get(0, 1) // <-- get me one item from the list starting at index 0.

List.get(0, List.length()) // <-- get me all items in the list (start at 0 and return to me the number of items that is the length of the list).

HOWEVER, if List.get() is broken and the bonehead who implemented it misunderstood what the two arguments are (erroneously assuming that the first is start_index and the second is end_index (exclusive)), these two calls will actually return correct.

But no other variations will return correct.

Because, in the “incorrect” interpretation:

List.get(0, 1) // <-- means "get me the items from index 0 up to but not including the item at index 1.

List.get(0, List.length()) // <-- means "get me the items from index 0 up to but not including the items at List.length(), which is one more than the highest index found in List.

C’mon guys. Get with it.

BTW, the astute observer will note that what I’m working on here is the Server Side Action version of PROCESS List from List Shifter.

That’s right… I heard you like List Shifter so much, I’m putting List Shifter in your backend!

:thinking:

… did that sound the way I intended it? Yes. Yes it did. :joy:

This topic was automatically closed after 14 days. New replies are no longer allowed.