Don't take selection input in getAvailableActions endpoint
#706
Conversation
It's unnecessary, since the server already knows the selection. And when we flesh out the API, it will become necessary for clients to keep the server constantly informed of selection changes anyway. For example, the actions API is designed with the assumption that the selection state comes from the backend. Since the request no longer contains a body, we are able to make it a `GET`.
| { OpenAPI.available = \level -> do | ||
| prog <- getProgram sid | ||
| case prog.progSelection of | ||
| Nothing -> pure [] |
There was a problem hiding this comment.
I've gone with just returning an empty list when there's no selection. I don't know that much would be gained by throwing an error.
| :> Summary "Get available actions for the definition, or a node within it" | ||
| :> QueryParam' '[Required, Strict] "level" Level | ||
| :> ReqBody '[JSON] Selection | ||
| :> OperationId "getAvailableActions" | ||
| :> Post '[JSON] [API.OfferedAction] | ||
| :> Get '[JSON] [API.OfferedAction] |
There was a problem hiding this comment.
Perhaps worth updating the Summary to mention "current selection"?
There was a problem hiding this comment.
Aha, yes, of course.
There was a problem hiding this comment.
I'm happy with the code, but would like to discuss the approach further. In particular, I'm somewhat wary of making primer more stateful. It could well be the correct way to go, but I am missing the bigger picture at the moment. I think this would be good to discuss alongside your rework of the wider action API as that may clarify things.
|
We agreed in today's meeting that we'll continue to send the selection with every call, mostly in order to keep the backend more stateless. |
No description provided.