Hey @boston85719, here’s an example:
Runtime: https://list-shifter-demo.bubbleapps.io/version-test/build-date-ranges?debug_mode=true
Editor: List-shifter-demo | Bubble Editor
This page has a Calendar Grid Pro element on it to give us a list of dates:
- The hot pink List Shifter takes a list of dates from that CG Pro as its Original List.
- We also configure the List Shifter’s Process Output Type to be date range.
Now List Shifter’s PROCESS List action can be used to operate on the list of dates and construct your desired list of date ranges, which can be pushed to List Shifter’s Processed List output.
I’ve also put an input on the page. This input lets you enter a number of minutes. These minutes will then be (1) added to the original dates and (2) used to construct a date range (starting with the original date and ending on the incremented date).
How you set this up in PROCESS List is a little tricky and I can see why it wouldn’t be obvious.
Examine the Custom workflow “Compute Date Ranges with Processed List”:
This action takes some list (in this case, List Shifter’s Original List - the dates shown in CG Pro) and then performs the processing steps on each element in the list.
What we desire to do for each date is:
- Take the original date and add the number of minutes to it that we specified in the input
- Construct a date range from the original date and the modified date
- Put that new date range into a list we can access
PROCESS List lets us do that. Here’s an explanation of the steps:
Step 1:
Take the current list item (which is a date) and convert it into its time representation in milliseconds (this is that getTime() does – this representation is also called “Unix time”).
This value is now stored as the result of Step 1. Internally in List Shifter, this is called “RS1” or “Result Step 1” and we can select it from the dropdowns in future steps.
Step 2:
Add the number of minutes we desire to that.
So now we take Result Step 1 and add (+ operator) the number of milliseconds.
For the second operand, we’d put “the number of minutes from the input times 60 times 1000” to get the number of milliseconds we need to add.
While we can build that expression in Bubble, we unfortunately cannot build that in the “Step Operand Y” field here. (This is because the type of these input fields is tied to the type set as List Shifter’s Process Output type, which is date range in this case. So you could only build a date range type expression here, but we need a number right now.)
So, rather than put the expression here, we define it further down in the Process List dialog. You’ll see for Step Operand Y I’ve selected a value from the dropdown: Numeric Constant.
If we need differing types of values like this, we define them down at the bottom of the PL interface. Here’s our setting for Numeric Constant (scroll WAAAAYYYY down!):
And there, just as you’d expect, is our math for converting the minutes specified in the input into milliseconds (value * 60 seconds/minute * 1000 milliseconds/second giveus us value in milliseconds, right?).
Anyway, the net result is that we take the original time, add some number of milliseconds to it and that value is now “RS2” or “Result Step 2”.
On to Step 3:
Now we take the result of step 2 (which is currently a number) and turn it back into a date, using the new Date() operator.
Now we have “RS3” or “Result Step 3” which is a date.
Step 4:
Now that we have two dates, we can construct a date range from them. We’ll take the original List Item as our start and RS3 as our end.
PROCESS List has a handy “make date range” operator that can construct the new date range for us, given two dates. The start is Operand X (here defined as the original List Item) and the end is Operand Y (here defined as Result Step 3, the new date we just constructed).
Now we have “RS4” or “Result Step 4”.
Being done with our computation, we now need to do something with RS4. What we want to do is push is onto List Shifter’s Processed List. We do that by setting “Push RS4 to Proc List” to yes.
We are done with our setup on the PROCESS List action! (We didn’t even need to use steps 5 and 6! Woot!)
Now, all we do is trigger that PROCESS List action whenever List Shifter’s Initialized/Updated event triggers OR when the Input is changed to a new value. That’s why I put the PROCESS List action in a Custom Workflow, so I could trigger it on those two different events more easily.
There ya go…
PS: BTW, you might notice that I clicked the “Debug Mode” checkbox in PROCESS List. This causes a bunch of logging to the console so you can see what PROCESS List is doing internally. This is useful when you’re constructing a new recipe in PROCESS List because it’s kinda like building a ship in a bottle, otherwise!