Notebooks: Variables Panel
- Dominant language
- TypeScript
- Stars
- 117
- Forks
- 51
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 4
Description
people want to parameterize notebooks. That's super cool, but reusing the dashboard mechanism of variables, isn't very notebook-y. So lets try something else out!
- [ ] add a new panel type
- [ ] use the wasm AST parser to get a list of variables and params (`v.{whatever}` and `param.{whatever}`) used in the query. see `src/flows/context/query.tsx` -> `_getVars` for the technique
- [ ] if the panel's source query doesn't have any variables, display some text that informs the user of such, and how to add one (use a raw flux panel, reference the `v.varname` somewhere in the query)
- [ ] if it does have some, display the list of the variable names next to a means for the user to set the variable's value
- [ ] when the panel runs `generateFlux`, if there are variables, and they have values, generate the `option v = {}` header for the query.
- [ ] work with product to figure out what to do if the query already has a `option v = {}` or `option param = {}`. i'm a fan of preloading the value of the old option into the input on the panel when you create it, then allowing the user to override it, but that's not for me to say
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with src/flows/context/query.tsx and its _getVars technique for extracting notebook variables and params from the WASM AST. Trace the panel type and generateFlux flow, then define the empty-variable and editable-variable states. Done requires variable discovery, value injection into generated queries, and a decided behavior for existing option v or option param declarations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, wasm
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100