As a Roblox developer, it’s currently a bit annoying to have to remember that BindToRenderStep will only accept an integer for its priority, not a RenderPriority EnumItem.
The vast majority of EnumItem uses in APIs allow for the passing through of the EnumItem, not strictly the value itself. TweenService takes EasingDirection and EasingStyle EnumItems. UserInputService takes KeyCode EnumItems. Therefore, it seems reasonable that BindToRenderStep should accept RenderPriority EnumItems. It’s a very simple problem, but because it’s an outlier in its behavior, I somehow always forget about the quirk and wind up wasting a minute or two whenever I implement it.
BindToRenderStep should be upgraded to match the behavior of other APIs: it can receive the value directly, or an EnumItem where the value is acceptable.
If Roblox is able to address this issue, it would keep me from having to start a test session, and then go back and fix my mistake, every time I used BindToRenderStep. It would also better match the behavior of the rest of the API.
I agree. This limitation also makes the RenderPriority enum useless, because it’s only useful for the Value property currently. At this point we might as well memorize the numbers.
My understanding of this is that not accepting a RenderPriority EnumItem is intentional. Furthermore, there are no good use cases for binding directly on an EnumItem’s priority.
To understand this, first note this comment on the DevHub:
If two bindings have the same priority, the Roblox engine will randomly pick one to run first.
If you look in the most recent PlayerScripts, you’ll see that there are several places where BindToRenderStep is called. Here are two examples:
As you can see, those bindings sit exactly at the value of the EnumItems. Accepting a RenderPriority EnumItem would necessarily mean that your binding would also sit at these priorities. This also applies to any existing binds you may have made elsewhere in your code.
As noted above, binding more than one function to the same priority causes unpredictable/unreliable behavior. For this reason, I can’t personally see the use case of supplying EnumItem arguments.
Furthermore, the gaps of ~100 between each RenderPriority EnumItem’s integer value are to allow the developer the space and flexibility to strictly define the order that your bindings will execute.
This logic also applies to ContextActionService:BindActionAtPriority, which similarly accepts an integer priority level (not an EnumItem).
I agree with what sircfenner above me said, but wanted to make one note:
Typed Lua should solve this as well when it gets smarter (it might be able to already though?). EnumItem can’t be passed for a number, so it should warn you in the editor.
