Building a Simple Notes Contract
A brief of my experience of building a Notes App on NEAR
The contract was quite simple with its features, some basic CRUD operations, and the ability to share a note to another account, but the procedure for a newbie like me to start building it from scratch wasn’t straightforward. It took time, energy, some research of similar projects, reading a lot of code, asking many questions at various platforms, coming across different approaches to making it finally.
To my aid, I had already been through the “sample–thanks'' and the “sample–lottery” examples. This gave me a basic idea of how contracts were written and the ideas and methods I could use to devise my contract efficiently.
First off, I laid out a basic plan of what my Note model would look like and how my contract would go about processing it across various function calls. I initialized the project using the
create-near-app command and started coding. Apart from creating a module for a note, I also created a “Vector” class that extended the persistent vector class and wrote some additional functions that I could use to process a vector apart from the ones already present in the class template. You might wonder where I am using vectors in my contract. Actually, a vector in my initial approach formed the basis of all the notes linked to an account. I later found out that there were other more efficient ways to frame a storage object, but we will get to that part in a while.
The Pitfalls / Learnings
Starting your first ever project in a new framework and not running into errors seemed too good to be true when I ran my partially built application for the first time. As expected, I ran into an instantiation error after a few initial contract calls. This seemed to be a really intricate and technical error because I couldn’t really find something on the net and the NEAR discord server that could help me resolve the issue. I ended up posting the query on StackOverflow which proved to be another dead end.
Finally, I went to my mentor with the issue and was suggested to make the application without the
create-near-app command as it was known to have some issues with its build. Instead, I could create files from scratch as I continued developing the applications as per my need. However, the issue persisted and it was then I accidentally realized that the logging function that I had been using had been misspelled. I could now move ahead, coding the other methods of the contract.
After making the basic CRUD functions, I realized my edit function seemed to work fine and make appropriate changes in the vector storing my notes by logging at necessary places within the method but while listing the notes in the vector, these changes did not reflect. Unable to see why this was happening, I decided to move ahead with making the last feature of the contract and come back to this at the end. For the last feature, I decided to maintain a set that would keep a track of all the accounts that the owner allowed to make changes to in the contract. They would essentially now have the same privileges as the contract owner. I took this as an example from the “sample–lottery” app. However, it gave me a memory out-of-bound error which seemed to be resolved when I created the set outside the “Contract” class.
The New Approach
Upon getting further clarification on what the sharing feature was about, I was not really sure of how I would implement it. I went through a few examples on the Lear-NEAR collection on GitHub and came across the “NCD–mail” example. It was a simple messaging application from one account to another which was implemented using the maps with the account-id as keys and the vector of messages as value. This seemed to be a better implementation for my application. I refactored my code accordingly with the vector now being replaced by the unordered_map. This seemed to work and simultaneously also resolve the updating issue I was facing earlier.