Help making tutorial apps

Guys can we move this thread to the new Dev Forum?

It seems like a perfect fit, as it would be incredibly useful to new devs looking on there

EDIT: just made a thread myself. Join & discuss!

Are you sure? Got a slightly different impression as to what its purpose was meant to be. And moving or continuing this there?

JSON.parse() is a standard library function so you can look it up but essentially you give it some text that is in JSON format and it returns a JavaScript object equivalent to that structured text (ie with the same members and values).

So for example, a structure/object expressed as text in JSON format such as:

{
   body: "foo",
   metadata: "bar"
}

Pass that to JSON.parse() and it would return an object with members “body” that has value “foo”, and “metadata” that has value “bar”.

var mything = JSON.parse(’{
body: “foo”,
metadata: “bar”
}’):

returns an object so you do:

alert(mything.body);

And it would display a message box with the text “foo”.

Hope that helps.

EDIT:

Does one prepare code assuming they know what the response will be?

One tests for all possible responses and handles then accordingly. If you look at my code you’ll see this.

2 Likes

What’s the xht?

But I think I get what you’re saying. To get the individual componants of the JSON passed back from the API, since we know what is expected from the API, we can parse the response into it’s componant parts using JSON.parse() and then reference the individual isolated components. So correct me if I’m wrong but to isolate the token from the response returned by the API would look something like this.

//Declare variables
var endpoint = 'http://localhost:8100/auth';
var endpointLongname = 'http://localhost:8100/dns/safenetwork';
var response = xhttp.responseText;
var payload = {
  "app": {
    "name":"Hello World",
    "id":"Hello World Alpha 1",
    "version":"0.0.1",
    "vendor":"Blindsite"
  },
  "permissions": [
    "SAFE_DRIVE_ACCESS"
  ]
};
var responseParsed = JSON.parse(response);
var apitoken = responseParsed.token;
var apipermissions = responseParsed.permissions;

//Check to see if the user has a token aka status 200.
//I'm wondering if or how to get the first user ID in the list?  That is how does one get one's Public ID?
if (xhttp.status == 200) {
    xhttp.open("GET", endpointLongname.apitoken, true);
    xhttp.send();
    document.write("<p>Hello World!  Hello, " + response + "!</p>");
} else if (xhttp.status == 400 || 401) {
    // Attempt to get a token.
    xhttp.open("POST", endpoint.payload, true);
    xhttp.send();
} else {
    document.write("<p>Authentication Failed.</p>")
}

I’m sure there are a lot of mistakes. But that’s what this is all about. Find the bugs and correct them.

2 Likes

Your getting there David, I know this can feel like eating a dessert :wink: but there is an oasis - actually many of them - to help you on your way and I think you’re approaching one right now.

You have the order back to front above because the status indicates whether or not the request succeeded, and therefore whether you have been given a token to decode.

So look at my code and try to understand that, and then fix your code above. You’ll see I’m checking the status code before I try to decode the response text.

I think you’ve got the essentials now so reading code will start to get a bit easier if you can skip over bits you don’t fully understand yet and fill in those blanks only as needed.

At least that’s my approach: learn as little as I can get away with while I’m getting going, and only when I feel ready do I dive into the more complex stuff.

There’s still stuff in that file that I don’t understand - one reason there is code there commented out is when I modify something I tend to leave the earlier version in place in case it stops working and only delete it when I’m sure what I have is doing what I intended. Later I’ll clean it all up, but for now it’s a work in progress, a scratchpad for my own use rather than code that’s ready to share (sorry about that :slight_smile: but I still thought it was close enough to what you needed from what’s available).

1 Like

I created this basic demo to give an idea on how to make an API call. You can find it here: http://simplesafe.safeguard.safenet/ (alpha network)

First press the authorize button to get a valid token. Then you can post, get and delete a file.

I kept the code as straight forward as possible to make it easy to understand. So there is no jquery, no promises, no css and even no constants. Each function (post(), get() and remove()) are self contained so there is a lot of redundancy but it shows at a quick glance what’s needed to make the API call.

Open the dev console to see the response you get from the server.

Hope this help.

index.html
simple_safe.js

8 Likes

Should we all, as a community, finally start putting our links here in proper safe:// form?

Possibly flagging people’s links that are still in the old .safenet form?

Wondering how much we should do to enforce the decision we’ve made for proper safe:// formatting.

I’d love to see this happen

1 Like

All hail Emporor @whiteoutmashups introducing tyrany to SAFE 1 link at a time. I didn’t agree to use safe://, or declare i was going to switch over to the safe browser, nor do I think anyone should be penalized for using .safenet. My god man people have a choice as to what apps they use and what protocols they code with. Who said what was proper or not? safe:// is only functional on the safe browser and it’s not even built yet. If you start flagging posts for being in .safenet i’ll be flagging posts because they’re in safe:// and not in .safenet.

4 Likes

lol you’re crazy dude.

good point, about the current state of development,

but be ready for this to happen eventually.

1 Like

Hey guys, what do you think about this as a start to fulfilling the desire of this OP thread?

I think it’s a good straight-to-the-point intro to the ideas of REST & APIs, and now we need to start getting going on creating API tutorials for SAFE in things like Python, Javascript, etc, to create the “Tutorial Apps” requested in this OP.

I also think this could be super powerful for SAFE to offer.

I haven’t read this whole thread, but have you received this information / tutorial yet?

I think we also would have to decide on a few things, like:

  • what language do you want to use?
  • do you want to create a desktop app or a web app? (this helps with the first ?)
  • actually, I think that’s about it.

So what do you say, @Blindsite2k ?

Well I’m trying to write it in javascript/css/html since thats what I know and am familiar with.

A web app would work for now. It’s just a hello world project to figure out the apis.

1 Like

That all sounds perfect to me! Seems like the quickest and easiest way to get this done.

Looks like SAFE-JS is the answer here; the only question is if it’s updated enough to work with the current network–and if not, which network should we use for it? Or should we just wait until @joshuef returns from vacation and is able to update it?

Is there a version of SAFE-JS that is usable right now?

No, I don’t think so. It hasn’t been updated in awhile. That’s why I’m having to do all this research.

Gotcha. So we need to make our own version, that sends REST API calls with javascript.

That’s what you’re working on?

I’ll see if I can help. Looks like it’s time to read this whole thread :stuck_out_tongue: the good thing about doing it this way is that once we find a generic way to create REST calls in JS, then nobody should have to rely on wrappers or anything. And we should create a clear step by step tutorial once we’ve got it

1 Like

That’s kind of why I’m doing all this. I posted some code earlier. I’ve been working on my computer lately so haven’t had time to code. Had some new hardware installed and had to reformat it so I’ve been doing updates and what not. It’s being annoying. But anyway the code is there if you want to tinker.

1 Like

@whiteoutmashups with all due respect, you might be a bit naïve in asserting that wrappers won’t be needed.

The wrappers themselves are most often built on top of, wrappers, papering over some of the oddities of the underlying XHR or corresponding mechanism for talking HTTP.

While it’s totally viable to go bare in order to get a feeling for how things work “under the hood” you’ll rather quickly realize there’s a lot of repetition and small niggles that can be reused between requests.

Once you extract those and make them reusable… you’ve most likely built a wrapper yourself already.
Also keep in mind that if existing wrappers break, that implies that any code you’ve written towards the same API would equally break. It just becomes a question of whom should carry the burden of updating.

You. Or the author of your favoritte wrapper.
It’s trade-offs all the way down.

2 Likes

@whiteoutmashups high marks for keeping at it :slight_smile:

Maybe we can set ourselves a new intermediate goal and replicate all the Node examples in the API documentation by adding additional ones for other languages, starting with regular Javascript, i.e. using no JS libraries (speaking of wrappers)?

And there is the code @DavidMtl gave us. If we dissect this and rearrange it we may have the above already.

Maybe step back and do the same for .Net @drunkcod :slight_smile:

I myself got this really stupid notion of trying to do this from the bowels of MS Office.
Try to get something sitting out there on the new network from within Excel

2 Likes

@JBishop I think that would be very valuable.

This can be included in the documentation with tabs on code samples, to select the language you are using. I saw that somewhere and it was very neat way to present the info (possibly in the Google Drive or Dropbox API docs).

Thanks all this really helps.

Can’t make any progress without getting rid of ego and asking the stupid questions sometimes, and I’m more than prepared to keep doing that :slight_smile: