-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guard params, action params and actor input #449
base: scaffold-new-version
Are you sure you want to change the base?
Conversation
|
@@ -76,6 +76,7 @@ export interface ActorBlock extends BlockBase { | |||
properties: { | |||
src: string; | |||
id: string; | |||
input: JsonObject; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct in the grand scheme of things - input
(just like params
) is basically unknown
at this level. There is no restriction for it to be an object.
On top of that, we'll just have to handle inline expressions here somehow. So we need to figure out some strategy for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but studio right now only accepts a JSON object so I thought we'd start but that and work our way to more coverage. Plus, the problem is not unique to parameters or input. It's true about almost anything that comes from code so we'd have to change almost everything for better coverage some time soon :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - but for the core of the config schema it's even OK to just give up on things that we can't handle (as in - error or something). With input
, context
, params
, etc - all of those are "slots" for user-provided content. When it comes to them handling them gracefully is table stakes.
I think that perhaps the support for those properties is not that robust in the Studio anyway. So I'd even consider drafting this PR for now - so it can act as a reminder that we have to improve the story around this. I just imagine that we'll have to make substantial changes to how this is represented in the digraph so I'm not sold on getting this in in this form as I don't think it buys us a lot right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When/if we decide to pull this in - it will still be 15min of work tops to reuse this work and rebase on top of whatever changes we might have on the trunk at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine by me. Params and input need to be handled before the new VS Code extension is released anyway, so this can wait.
No description provided.