Begin transmission…
Studio table import & schema copying feature
by Dan Buchholz
Within the Studio, a feature lets you view any table across the Tableland network. But, there's also another level to this: you can take any table and import it directly into your Studio project.
For example, let's say you or someone else created this table with the Tableland SDK or smart contracts:
When you're on the table inspection page, there's a …
icon in the top-right corner:
Clicking that will prompt you with two options:
Import the table into your project.
For example, you might discover some random table on the network and could then use the CLI to run queries against the data—where the imported table can be contained in / referenced by your personal project.
Note: importing a table is an existing feature, but this saves you a couple of steps vs. manually typing in the data via a form input!
Copy the table schema.
That is, it doesn't copy the actual data stored in the table, but the table's definition is created in your project and can act as a nice starting point / help with ideation.
The goal of these two features is to make it even easier to interact with existing tables that weren't deployed on the Studio but are still accessible within it. As always, if you have feature requests, let us know on Discord or open an issue on GitHub.
Studio Sign In With Ethereum, localhost, and Brave
by Joe Wagner
This week we found an issue affecting our Studio dev team when working with the Brave browser, and the SpruceID SIWE npm package. We were able to fix the issue in studio and contribute an update to the SpruceID quickstart code base.
TL;DR;
If you're unable to use Sign In With Ethereum in a localhost sandbox with Brave Wallet, the fix is to start explicitly including the optional scheme
field in the SIWE message. An example of the needed change can be found here https://github.com/spruceid/siwe-quickstart/pull/41.
The Problem
While manually QA testing the Studio web app with Brave one of our dev team noticed the sign-in was no longer working. When attempting to sign in Brave, it shows the following error dialog:
A discerning eye will notice that the URL in the red text is http
, and the URL in parentheses is https
. Sign-in was working in all the other browsers being tested, so we figured that there was some nuance to Brave that was setting https
as a default for an optional value.
Further debugging led to the discovery that the spec shows the first field is the optional scheme
. It turns out that if the scheme
isn't provided, most browsers are either leaving it out or parsing it out of the uri
field. However, Brave's implementation of the spec is to set a default value of https
if scheme
isn't provided.
The Fix
The fix ended up being fairly simple. We updated our version of the siwe
package to one that supports scheme
and started parsing the scheme out of the page uri.
Here's the PR for our update: https://github.com/tablelandnetwork/studio/pull/270
We hope this helps anyone who runs into a similar issue. If that's the case, or you just want to say hi definitely give us a shout on Discord or Twitter.
New SDK v7 docs & templates are now live
by Dan Buchholz
The new Tableland SDK has been published officially as @tableland/[email protected]
—along with all other clients that depend on it (Local Tableland, CLI, Hardhat plugin, etc.). We've walked through the changes in our most recent Weeknotes, but the only major changes are:
Polygon Mumbai has been swapped for Polygon Amoy
ethers v5 has been swapped for ethers v6
Our docs site is now updated (https://docs.tableland.xyz) with all of these changes. Namely, the SDK usage hasn't changed, but many of the snippets had to be refactored to take into account the points noted above. Also, all of our template repos have been updated as well, so you can get started quickly with the newest SDK!
The Curb Cut Effect
by Jim Kosem
Accessibility seems to be trending. This is new in a way that is almost disturbing for several reasons, the first of which is why it has taken so long, and the second being what caused this. I think it might have to do with just wanting things to work.
We as as species have lived with the breakneck speed of technological advancement for two to three decades now. At no other point in our collective history has anything resembling this, and it’s all largely happened in how we learn to use and adapt to software patterns. Yet a lot of the basics have been somehow skipped. Whilst there are endless patterns and documentation for spatial design, which happened yesterday for all intents and purposes, there is little on how to navigate with a keyboard with something as notionally simple as a web page form autocomplete.
There is this idea of The Curb Cut Effect: if you make things better for people with access needs, you make it better for all users. For instance, most people use the curb cut whether in a wheelchair or not, because it’s just easier. The same goes for websites and tools. If they are simple in navigation and content structure, easy to read, and things like the tab focus work, it won’t be better just for some people, but for everyone.
End transmission…
Want to dive deeper, ask questions, or just nerd out with us? Jump into our Telegram or Discord—including weekly research office hours or developer office hours. And if you’d like to discuss any of these topics in more detail, comment on the issue over in GitHub!
Are you enjoying Weeknotes? We’d love your feedback—if you fill out a quick survey, we’ll be sure to reach out directly with community initiatives in the future!: Fill out the form here