Add Anywidget Front-End Module spec support with ui.anywidget()
#5137
Conversation
| callbacks: {}, | ||
| get: function (key) { | ||
| log('Getting value for', key, ':', this.attributes[key]); | ||
| const value = this.attributes[key]; |
There was a problem hiding this comment.
If this just return value, this raises an error:
Uncaught (in promise) DataCloneError: Failed to execute 'structuredClone' on 'Window': #<Object> could not be cloned.
at reembed (1b7ef5d7-1cf7-4947-8f06-0f33e5db9f95:29:20)
at Object.render (1b7ef5d7-1cf7-4947-8f06-0f33e5db9f95:146:11)
at anywidget.js:96:47
|
Thank you @azjps! A very interesting PR which opens up a lot of possibilities. May be a better idea to target this for 3.0 branch since I'm not sure how many releases will be left for 2.x, and 3.0 has different JS dependency management and other changes. Also considering release schedule and workload. But please don't make that change until either @falkoschindler or @rodja agree - I'm just suggesting. |
evnchn
added
feature
|
@evnchn I suppose for #5021? Currently there's no 3rd party npm dependencies so if I rebase on top of the 3.0 branch, the examples still run fine. But I'm not too sure where the JS files should go now (in particular this one: |
|
Oh I thought Yes there is some changes in how things are organized in 3.0, but no I'm not familiar with it since I resumed contribution recently. Regardless, it looks like this will be in 3.0 so whether we merge this into main then the 3.0 branch, or merge this into 3.0 then that goes into main, just Git logistics at this point. It'll be fine either way. |
|
Very very interesting, @azjps! Unfortunately it'll have to wait until after 3.0. I'm looking forward to reviewing it! |
|
@falkoschindler no problem, maybe it would be nice to include it as a selling feature with the 3.0 release? The current PR still works with 3.0. |
|
Trying to feature-freeze for 3.0, but you can argue this is an independent new element so we can slip it in though. Main limiting factor is manpower to review, I think. To be honest, feature-freezing is mutually in opposition to a banger 3.0 release, but I guess we have to strike a balance somewhere. |
|
@evnchn Got it, yeah IMHO this is a new feature that is disjoint from any existing code, but up to you guys when you have capacity to roll out. I've added a trivial unit test and some barebones website documentation now to hopefully make it easier to review, can maybe flesh out a fuller example if I have some time but it would effectively just be an addendum to the |
Details: https://anywidget.dev/en/afm/#what-is-afm AFM describes the basic contract for front-end frameworks to support anywidgets, namely calling render({model, el}) to create a widget and implementing the model.get/set/save_changes() API to synchronize state to the backend, and .on() to register callbacks for changes from the backend. Implement AFM by having set() $emit a update:traits callback with the wiring done in ValueElement (which listens to update:VALUE_PROP). Conversely, register traitlets observe() handlers to call Element.run_method() to emit model callbacks registered by on(). Add a simple example page which shows an anywidget and nicegui button synchronized, and a altair slider and nicegui slider synchronized.
* Only console.log when _debug property is set (default: False) * Remove patched altair.JupyterChart; have just left a comment explaining that the implementation is buggy currently * Other minor formatting / docs cleanup
Altair is one of the more popular plotting libraries, so add a dedicated wrapper for ease of reference, although the implementation is just a very thin wrapper over anywidget. Also add an example of altair usage.
Move anywidget related python/JS code to anywidget/ directory.
falkoschindler
added
🟠 major
3 participants
Motivation
Refer to #5096 for details: add support for anywidgets to be rendered in NiceGUI, such as the 70+ examples from the anywidgets gallery: https://try.anywidget.dev/. For example, this solves #657 (adding
altairsupport); for convenience, this PR exposes aui.altair(chart: altair.Chart)although its a one-line wrapper aroundui.anywidget().Roughly speaking the flow is:
traitlets.HasTraits.observe()to listen to changes to anywidget's traitlets; on observing changes, callnicegui.Element.run_method("update_trait", <trait>)to invoke any callbacks on JS side registered bymodel.on("change:<trait>")in the anywidget'sesmmodel.save_changes()$emits the state oftraitstoValueElement._handle_value_change, where any changed traits will be set on the anywidgetIt also might simplify feature requests for other pure-JS libraries, for example it took me a couple of minutes to vibe code a TradingView LightWeight chart widget (#813) that I iterated on in Jupyter and then copy-pasted into NiceGUI, without needing to add any code to NiceGUI.
Implementation
I borrowed most of the structure behind the AFM implementation from the few examples out there such as marimo.
Known issues:
model.send()method in AFM is left unimplemented, haven't checked how its usedinitialize() / render()are not currently usedmodel.save_changes()currently sends all traits back to python including unchanged traits, which is unnecessarily expensivealtair: JS errors whenaltair.paramsare updated but this is an issue withaltair:JupyterChartaccesses.changedproperty in callbacks vega/altair#3868on_changecallbacks is very jittery -- see the recording below, I'm not sure what throttling / debouncing needs to applied. Is there an easy way to link the two NiceGUI elements on the JS side?Screen.Recording.2025-09-13.at.11.57.08.PM.mov
Progress