Safe Browser Dev Updates (@v0.4.2)

Hey @DavidMtl, so most functions will parse the reponse to give the clear result from the api. Only the file endpoints will return a full response as these can be used in a few different ways by the app (depending on type of file/size etc), so parsing these responses is currently left to the app.

for example:

safejs.nfs.getFile( token, dirName + '/' + fileName ).then( response =>
        {
            response.text().then( text => {console.log('The text of your file, if it was a text file:',text)}) 
        });

Hope that helps/clarifies.

As ever, if you think docs can be updated for clarity pop an issue on the repo or PR. Happy for all input!

2 Likes

@DavidMtl more detail here: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Body

1 Like

I have some safe-js examples that are the beginnings of a test suite against the network. I’ll tidy this up, and provide some notes on how this should roll in Safe Browser, and that should hopefully clarify a lot of stuff.

I’ll get into that just after I’ve got the last kinks out of the sync setup.

2 Likes

WoW that’s a lot of work, thank you for doing that each testnet for us!

Does “fell” mean the websites you successfully found through guessing?

Yes me either. Sounded like a way to fill in your functions for local testing but I’m not sure how to use it

Safe Browser w/ sync. Pre-release for testing v0.4.0-3

I’ve pushed the latest version of the SAFE Browser that will sync to the network if/when authorised.

All beaker sql endpoints have been converted, so:

  • history
  • favourites (bookmarks)
  • sitedata
  • settings

are now stored on the network :boom:

Using these features.

Right now, the best way (due to beakers lack of shortcuts) for adding favourites, sitedata etc is via the console:

window.beakerBookmarks.add('<siteurl>','<sitetitle>')
beakerSitedata.set('<url>','<key>','<token>')
beakerSitedata.get('<url>','<key>')

The sitedata methods are analogous to standard browser localStorage, but on the network itself (localStorage itself will save to the computer)

History should update by itself, as you would expect.

Caveats

This version is not ready for general use. There will likely be a variety of bugs with syncing, so please only dive in here if you’re ready to help debug such things :smiley:

Aside from a refactor, just testing various use cases and looking for network errors is the most important thing here. So keep an eye on your Launcher logs. If you are having problems, it’s probably best to download and build from source to get a clearer look at errors. (both syncing, and triggering auth etc).

Known Issues

Rapidly adding / changing data results in mutation errors on the network. I’m investigating the best ways to handle these.

The redux store and async save flow is reasonably stable now in bookmarks. I need to refactor site-data etc to work in the new fashion.

The safe-status page doesn’t currently update, you’ll have to refresh to see the current status.

Refactoring

Right now the code has a couple of different flows for data storage, bookmarks being the latest and most robust in terms of the app and network. I’m planning to refactor everything to a common pattern, like this.

There’s also the ‘safe-status’ page, which currently, you have to refresh to see updates. This can be easily refactored for a release, but for dev there’s limitations on debugging right now with this in place.

Todos for BrowserSync:

  • Update SAFE Status and browser pages upon data change.
  • Implement error reporting and retry save/auth network errors
  • Refactor reducers and stores.
4 Likes

Is this what’s supposed to happen? Tried a few ways:

1 Like

Yup. Then if you check the ‘favourites’ page (accessed via opening a new tab) you should see it added.

You can check for a file write in the launcher logs too.

2 Likes

Hey @joshuef, I’m getting a response.text is not a function with this code. I’m using browser v3.6-0. You can see my code here: safe://simplesafe2.davidmtl/

Any idea what I’m doing wrong?

1 Like

Can you post the code you’re using here? (your site wont load for me)

Are you seeing any launcher interactions / logs?

That’s strange. I’m using launcher 0.9.3 and browser 0.3.6. Here’s the code:

var filename = document.getElementById("filename").value;

window.safeNFS.getFile( token, filename ).then( response =>
{
    response.text().then( text => {console.log('The text of your file, if it was a text file:',text)})
}).catch(function(error) {
    console.log(error);
});

Yes, authorization, creating a file and reading a file all show up in the launcher logs.

1 Like

You could set a breakpoint and examine the response object using the debugger.

I did, you can see the content of the response object in my reply a few post above. You won’t see functions though so it’s a bit hard to see what’s available and what is not. Anyway text() isn’t for some reason so if anyone else have a basic working example I could compare to see what I am doing wrong. There’s no rush though, this can wait for the official examples by @joshuef. Thanks for the help.

1 Like

Hmmm. Okay, I see the site now. And I’m facing the same problems with beaker’s sync at the moment too.

Not entirely sure where the problem lies, but I’m pretty sure it’s not with your code at this point.

Got to run to work now. I’ll dive in and get this straightened out this evening :thumbsup:

3 Likes

You can see the functions if you type the name of the variable in the console followed by a ‘.’ as in “response.” Edit: see this post for a screen capture example:

EDIT: The following issue points to an example which is successfully using safeNFS.getFile() and my posts there give details that will help you run it. I think I’m using slightly later beaker than you, so worth trying that perhaps.

https://github.com/theWebalyst/remotestorage.js/issues/1#issuecomment-258649149

3 Likes

So. this is sorted on safe-js master.

The failing response.text was related to this issue from @ben where buffer was also missing in the browser.

An update to both safejs and safe browser are coming with these changes so you can continue soon, @DavidMtl

2 Likes

New SafeBrowser RC, with refactored store and sync (debounced to reduce mutation errors), as well as with updated safe-js to get around text() and buffer() issues with getFile.

@DavidMtl this should get you going again. Please note the updated getFile docs in safejs :thumbsup:

    safejs.nfs.getFile( token, dirName + '/' + fileName, 'text' ).then( text =>
    {
        console.log('get new file',text)
    });
2 Likes

Aaaand a new release. Now with updating beaker pages with authentication information, when you add things to the store.

1 Like

It works, good job!

“Reauthorise with SAFE Launcher” doesn’t seem to do anything, though, I guess that’s for the sync. In the console I get a “Protocol description undefined” message when I click on it.

1 Like

Right now with this latest there’s a couple of minor issues with auth. I’ll be looking into this later today :thumbsup:

Glad its working for you so far, though!

2 Likes