Is it possible to load activities from desmos.com into your calculator object via the desmos api?

[Michael McVeigh]

It seems like the options setting pasteGraphLink is what I'm looking for, but I can't seem to get it to work.  

In my code I have something like this

var calculator = Desmos.GraphingCalculator(elt, {pasteGraphLink: 'https://www.desmos.com/calculator/ymllorabgu'});

the API documentation says 

Paste a valid desmos graph URL to import that graph

Perhaps I'm not using a "valid" URL, but I'm not sure what constitutes a valid url in this case. Or have I just entirely misinterpreted the purpose of "pasteGraphLink"

any help would be much appreciated. thanks!

[Chris Lusto]

Hi Michael,

The `pasteGraphLink` option takes a boolean value. It determines whether or not pasting a graph link into the expressions list in a calculator instance should load the associated graph state. Maybe we can make that documentation a little clearer. If you want to actually load a graph state programmatically, you'll have to use `setState()`. If you hit a graph URL and specifically ask for JSON (either with "Accept: application/json" headers or with something like jQUery's `$.getJSON()` method), we'll actually return you some JSON that includes the graph state, so you grab the data you need that way.

Hope that helps.

Chris @ Desmos

--
You received this message because you are subscribed to the Google Groups "desmos-api-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to desmos-api-discuss+unsub...@googlegroups.com.
To post to this group, send email to desmos-api-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/desmos-api-discuss/6c52bf6e-ea45-4347-8d48-cf365b7ad957%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Lusto]

Hi Michael,

The `pasteGraphLink` option takes a boolean value. It determines whether or not pasting a graph link into the expressions list in a calculator instance should load the associated graph state. Maybe we can make that documentation a little clearer. If you want to actually load a graph state programmatically, you'll have to use `setState()`. If you hit a graph URL and specifically ask for JSON (either with "Accept: application/json" headers or with something like jQUery's `$.getJSON()` method), we'll actually return you some JSON that includes the graph state, so you grab the data you need that way.

Hope that helps.

Chris @ Desmos

[Michael McVeigh]

Terrific! Thanks for the lightning fast reply!

[Fabrice Neyret]

Hi ! it's still totally unclear to me how to proceed ( calculator.setState( " [URL] " )  won't work ).

May you please provide a example of code ? ( NB: it should be included in the list of base examples you provide, BTW).  

[Chris Lusto]

Hi Fabrice,

You can't pass a URL directly into `setState`. You first have to get the state for the saved graph by hitting its URL and requesting a JSON response. That response contains a `state` property that you can then pass into `setState`. Here's a working example. (It uses jQuery's `getJSON` method for convenience, but you can use whatever method you like to fetch the JSON response. The important part is that you pass the response's `state` into `setState`.)

We don't include this as an example in the documentation because it's not a pattern we typically recommend. While we work hard to ensure backwards compatibility between API versions, we can't ensure forwards compatibility, so graphs loaded from desmos.com into older API versions may not always behave as expected. For instance, we recently released a bunch of new statistics features that will land in v1.3 but aren't present in v1.2. So if you make a graph today on desmos.com using any of these new features, and then try to load the saved graph into a v1.2 calculator, it won't work.

We typically recommend that people author graphs in the same version (or older) of the calculator API that they're going to be displayed in.

Hope that helps!

Chris @ Desmos

[Fabrice Neyret]

Le jeudi 28 février 2019 18:04:03 UTC+1, Chris Lusto a écrit :

 Here's a working example. 

So great, thanks a lot !

for the other readers:   JQuery option => don't forget to add <script src="https://code.jquery.com/jquery-3.1.0.js"></script> in header.

 

We don't include this as an example in the documentation because it's not a pattern we typically recommend. While we work hard to ensure backwards compatibility between API versions, we can't ensure forwards compatibility,

good point. still, you allow  and present in the doc the pasteGraphLink:true   mechanism which has basically the same issue, and even worse since here you can't control the user.
While the coder can be expected to pay attention to the compatibility of a file with API.

Also I was tempted to try to make a web page with a best-of of my graphs, and I suspect (but maybe I'm wrong) that the API mechanism will be less resources-demanding that a series of embedding (iframe-based, cf export button). I guess I'm not the only one interested in this kind of applications.

Beside, it would be cool to have a decent API to access our graphs, since there is no easy way to get the *most recent version* of a graph (i.e. to have a pointer to the root and not to a version, as given in the menu in the interface), nor we have a way to access the list of our graphs.

Right now I have to script horrible parsing of resulting Desmos html to extract the necessary stuff to produce my DesmosGraphic icon-list page. 
-> Any plans ? ( basically, could look very much like the Shadertoy API )

[Chris Lusto]

Yeah, it's true that the `pasteGraphLink` option suffers from some of the same problems. Basically, we introduced that for internal use (it's very convenient for authors in our Activity Builder platform, which always runs something very close to the edge version of the API), and then discovered that it was useful for a few partners who (a) have very simple integrations and don't want to write much custom JS, (b) run pre-release versions of the API explicitly to take advantage of newer features that land in between stable releases, and (c) have pretty benign worst-case scenarios if a user attempts to load an incompatible state. But it might be worth us adding some caveats to the documentation.

An API to access your own graphs is an interesting. Nothing like that currently in the works, but it's a cool idea. The "most recent version" is a little tricky with our versioning story, since every time you save a graph it essentially just creates a brand new resource. We do save a reference to the parent hash on a save (you can see it in the JSON response), but we mostly use that internally for diagnostics.

Anyway, thanks for the thoughtful feedback!

Chris

[Fabrice Neyret]

Le vendredi 1 mars 2019 17:01:51 UTC+1, Chris Lusto a écrit :

The "most recent version" is a little tricky with our versioning story, since every time you save a graph it essentially just creates a brand new resource. We do save a reference to the parent hash on a save (you can see it in the JSON response), but we mostly use that internally for diagnostics.

 

even out of the scope of API, it is giga-annoying not being able to share a link on the root version (i.e.e "always latest") of a graph:

when I send my graph to colleagues, students, forum, web page, if I later correct a typo or add a small improvement I have to track and edit / resent the new version everywhere I gave the link. And if I forgot one, some people still see the old version. All the benefit of sending a link rather than a content is the ability to do post-sending corrections, which is not possible with Desmos (which is pretty unique in behaving that way).   
-> if you could give us this root link, shareability of graphs would gain a big step !