This is the place to report things that seem to be broken.
Anything that crashes, feels wrong, doesn’t work, or is confusing.
The first thing we do with any bug report is go make it happen ourselves, so the more specific you can be, and the more useful information you can include, the better the chance that we’ll be able to see and fix the problem.
Is this intended to just be the place to report Computation Layer specific bugs, or any Activity Builder bugs? (Or indeed, any Desmos bugs?)
Bug Report: “slider” → “sliderBounds”
Calculators made at desmos.com/calculator/… save slider bounds as “slider”. This works fine until you download the contents and try to render them in your own web-page. At this point, it ‘forgets’ all about the slider bounds and doesn’t include that data, because it is expecting “sliderBounds” as specified in the API: view-source:https://www.desmos.com/api/v1.6/docs/examples/slider-bounds.html
Things resolve themselves if you manually change “slider” → “sliderBounds”, but you shouldn’t need to. It’s strange that “slider” even works at all. Please update this behavior to be consistent with the terminology used in the API.
To recreate:
Hi J.T.,
Just FYI, this is a forum for the Computation Layer scripting language, not for the graphing calculator API. In the future, you can try support@desmos.com or open a ticket through support.desmos.com for more general support inquiries.
That said, I’ll take a swing at this while we’re here. I think the confusion is that there are two different sets of expression properties: (1) those that are saved in the serialized graph state—i.e., the result of getState(), which I think is what you mean by “source”—and (2) those that are suitable for passing into the setExpression() method to set/update expressions—which are outlined in the API docs. If the problem occurs because you’re manipulating the graph state directly, you should avoid that. Graph states are intended to be opaque. If you want to update an expression programmatically, you should use the setExpression() method instead.
In the case of sliders, we do happen to save a slider property in the graph state, but that’s just implementation detail that you can/should largely ignore. Graph state shapes and property names change between versions, and you shouldn’t write code that relies on them. If you want to update the slider bounds via setExpression() you should include the sliderBounds property in your argument, as laid out in the docs.
I’m guessing a bit here, because I’m not sure exactly what workflow you have that’s causing problems, but an outline of exactly what you’re doing to “download the contents” of graphs from demsos.com and “render them in your own web-page” might help. But there definitely shouldn’t be a step where you’re manually changing property names in the serialized state.
Chris