Our decentralized snippet application, powered by Blockstack, is starting to come together. We’ve seen how easy it is to add user authentication and basic persistence using Blockstack’s JavaScript library, Blockstack.js. This week, we’re going to add the ability to name snippets and the ability to save multiple snippets. In order to pull this off, we’ll have to dig into persistence again and show a slightly more complicated way of handling data.
Our Blockstack example app: Naming snippets
When we left off last week, our app opened directly to a snippet editing tool and loaded any work we may have saved to a snippet.json file we saved to Blockstack’s decentralized storage, also known as Gaia. The file we saved was a string-ified version of a JSON object that looks like this:
{
"html": "<div class=\"message\">The rotat….",
"css": ".message { \n text-align: center;\n …",
"js": "const colors = ['red', 'blue', 'orange', …",
}In order to support the naming of a snippet, we’ll have to restructure this object a little. We could simply add a name field alongside the other fields, but then the data (e.g., HTML and CSS) and the metadata (the name field) would be comingled. This isn’t the worst thing that could happen, but as metadata grows to include a description, the date it was created, the date it was last edited, and other fields, our object would get a bit trickier to read. In order to stay organized, let’s change the file structure to include a name field and a snippet field, which will be a nested object with the current properties.
{
"name": "Rotating Color",
"snippet": {
"html": "<div class=\"message\">The rotat….",
"css": ".message { \n text-align: center;\n …",
"js": "const colors = ['red', 'blue', 'orange', …",
}
}Now all we need to do is build out UI components to display and edit the snippet name and we’re set.
Our Blockstack example app: Handling multiple snippets
We’ve only had to deal with a single snippet so far, but we’d like our users to be able to save multiple snippets and to view a summary of them in list form before selecting one to edit. One data modeling option we have is to take our preexisting snippet JSON and wrap an array around it. Then we could persist the whole array to one snippets.json (note the plural) file, which would make it easy to retrieve all of a user’s snippets in one request later on. This approach is relatively simple to implement, but it has a few drawbacks.
First, the app will take longer and longer to load as users save more snippets. It will also take longer and longer to save, because a change to any snippet will require rewriting the whole file, which includes every snippet. The second drawback has to do with what we’ll be working on next week, which is to make snippets shareable. We’ll get into the details next week, but the basic requirement is that data sharing happens at the file level. If we want to share a single snippet, then we’ll have to store that snippet as a single file.
With all of our snippets in different files, we’ll also need an index of all snippets so we can easily show a list of snippets to a user without having to retrieve them all. That list might look something like this:
[
{
"name": "Rotating Colors",
"id": "7700d231-1d06-414c-84d1-ee96f10a2640"
},
{
"name": "Circle Designs",
"id": "a151d7f5-03ea-4c4f-acf2-683d2e3328d2"
}
]
Then, for each of those snippets we’ll have separate files named after the IDs in the list (e.g., a151d7f5-03ea-4c4f-acf2-683d2e3328d2.json) so we can load them up and save them to the right place. One consideration with this approach is that we’ll have to change two files whenever a snippet is renamed, created, or deleted.
Next week we’ll cover how to share data with other users of the app, add the ability to make snippets public or private, and launch our decentralized app! As always, you’ll find the full code to support named snippets and snippet lists available on GitHub. Questions or comments? Continue the conversation on Twitter: @freethejazz.