Live Blogging the Development of a New Feature: via ReactJS and .NET Core. Part 5.

Well, would you look at this…

With a sense of personal accomplishment, we conclude, “It appears our work here is done…”

“Not so fast, my friend.” — President Corso.

Truth is, our feature shouldn’t even be exposed to the world yet because its development is missing a critical step.

But, which critical step?

Consider that a tease because I’ll answer that question toward the end.

First, let’s discuss how we’ve gotten to where we are so far.

Since our last update, all of the major functionality associated with the run-log’s image file has been completed. The user now has the ability to upload an image from a remote location (like their phone) to the run-log. And the run-log, on its end, was wired to download and display that image.

During the process of implementing this, we learned a little more about cloud storage with Microsoft Azure and, ultimately, were able to save a “blob” to which we could store our run-log image.

At least one requirement, however, remains elusive: Along with their image, the user needs to be able to upload a date. And the run-log should automatically update its date to display the one provided by the user.

So, pour a ☕ and let’s do this thing.

Now, I know what you’re thinking: this should be easy, right?

I get where you’re coming from. Because it seems like our present task — to allow the user to upload a date — is pretty similar to the one we just completed that allowed the user to upload an image.

So, initially, it might seem to make sense to use a similar solution. We could create a blob in the same container in Azure that stores the image and then stream the date provided by the user to that blob.

Agreed: Makes sense.


I was poking around the Azure portal, where I found that we could explore the blobs and other items that we upload to storage. When we click to open the blob associated with the uploaded image for our run-log, we discover, among other things, this:

So meta.

It appears we can save key/value pairs to our blob object. Sounds perfect for our current needs.

The first google result for the query, “blob metadata”, directs us to Microsoft’s official documentation for getting and setting blob metadata.

And 🙏 — it’s super easy:

Minor details aside, that’s really all there is to it. At least so far as the uploading (POST) aspect of this tasks goes.

As for coding the image download (GET) aspect, it’s just as simple.

I won’t discuss today much about the client-side implementation (though, in summary, we used the fetch API to call the GET method in our back-end controller, and saved the text from the response as the value to the “date” key in our component's state object).

I’ll note, though, that to make the response that we send back to the client super easy to work with, I changed the GET method’s return data type from an IActionResult to a simple string.

This decision, as far as I know, causes our GET request to violate the standards of a RESTful API. And, to be honest, that bothers me. But, for now, it works.

Optimization will have to wait for its day.

Alright. So, at the beginning of today’s update, I teased that I’d reveal why our project is currently unsuitable for distribution.

Truth be told, it’s no big secret and the reveal will not be shocking to any developers reading out there, experienced and junior alike:

🥁 (← clearly, a drum roll)

Our project lacks any automated testing.

And that’s unacceptable.

In many professional environments, the code-base is controlled in such a way that the project will not build until successfully passing automated unit testing. There are many benefits of automated unit testing and one that immediately comes to mind is that it helps prevent deploying code that was unintentionally broken by a modification in a seemingly unrelated area.

For this project, we’re not going to go as far as utilizing any sort of continuous integration deployment pattern that incorporates our testing such as that described above, but we will set up unit tests in both our .NET code (likely using the NUnit testing framework) as well as in our ReactJS application (Likely using Jest, because of its integration with Create-React-App. But there are other good options that we will consider.).

That — testing — will be the subject of the next update.

So, until then, thanks for reading!

(Please click HERE to continue to the next part in this series.)




#dotnet #javascript #physics?