search

wolf-packs / wolf-core

🐺 Declarative development for state driven dynamic prompt flow
MIT License
29 stars 1 forks source link

Slot Functions Parameter Order #151

Closed howlowck closed 5 years ago

howlowck commented 5 years ago

Is your feature request related to a problem? Please describe. I know we just switch the parameter order to be consistent with onComplete. However, as I am writing out the examples in wolf-bb. I'm realizing it is not ergonomical to have the storageLayer as the first parameter. This is because most of the time, I'm not concerned with the state on the slot level. I believe this was the reason why we had submittedValue as the first parameter in the first place.

Describe the solution you'd like All the slot Functions to have the submittedValue as the first parameter and storageLayer second.

Describe alternatives you've considered We can keep the order consistent if we also switch the onComplete parameter to have submittedData first followed by storageLayer.

Additional context

kevinleung23 commented 5 years ago

@howlowck I like this suggestion a lot. The decision to be consistent was actually made with DX in mind (in an attempt to be helpful). This is good actual DX feedback and I agree the parameters should be ordered based on developer frequency of utilization.

Marking potential and will revisit in an upcoming sprint. However, feel free to mark accepted and get this in the backlog. Since this concerns API, this should be done sooner rather than later. 👍

kevinleung23 commented 5 years ago

Potentially a new feature but tagging it here because of relevancy.. noticed Slot.validate is the only property to not have access to the storage layer object.. Do we want to add this as a second parameter so all slot properties are consistent?

Use case: A user would like to validate the submittedValue based on values within the state.