Reply sess 2
1. Yes. This also follows the design pattern that we more-or-less employ already for Sapphire. We chunk up files so each has their own dedicated purpose and is not muddied by other purposes. We're at least sort of object oriented that way. Furthermore, it being a separate piece means we can also separately use @ApplyOptions and any other decorators we may write in the future.
2. Yes, needed
3. I don't think that's needed but then I haven't written custom IDs before so I'm not sure.
4. I think it's pretty dang useful like this
1 Reply
Related to 3, custom IDs aren't meant for data storage but you totally can store SOME data in them for fully "stateless-y support". Thats why I'm wondering if the function shouldn't be a filter but a parser