SessionStorage property in JavaScript

The read-only sessionStorage property accesses a session Storage object for the current originsessionStorage is similar to localStorage; the difference is that while data in localStorage doesn’t expire, data in sessionStorage is cleared when the page session ends.

// Save data to sessionStorage
sessionStorage.setItem("key", "value");

// Get saved data from sessionStorage
let data = sessionStorage.getItem("key");

// Remove saved data from sessionStorage
sessionStorage.removeItem("key");

// Remove all saved data from sessionStorage
sessionStorage.clear();

This is a good candidate for saving text between refreshes. Here is an example;

// Get the text field that we're going to track
let field = document.getElementById("field");

// See if we have an autosave value
// (this will only happen if the page is accidentally refreshed)
if (sessionStorage.getItem("autosave")) {
  // Restore the contents of the text field
  field.value = sessionStorage.getItem("autosave");
}

// Listen for changes in the text field
field.addEventListener("change", () => {
  // And save the results into the session storage object
  sessionStorage.setItem("autosave", field.value);
});

Reference

https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

Clean Shave: Razor Pages for Web Forms Developers

If you’re an ASP.NET Web Forms developer and you’re unsure of how to take your skills to the future of the .NET platform (e.g., .NET Core or .NET 6), there’s hope. Although Microsoft won’t port Web Forms, you can apply your existing skillset to a similar framework, called Razor Pages. You’ll still need to think about this new platform differently, but if you take the time, I think you’ll find a similarly powerful and easy to use tool to create web applications.

Where You’re Coming From

Back in the early 2000s, I was a C++ developer and was one of these “you’ll have to take my pointers out of my cold dead hand” guys. But once I was introduced to how garbage collection worked in .NET, I was a convert. In those early days, I was writing ASP.NET (after my time writing components for ASP projects).

The reality was that I didn’t understand how the web actually worked, but I was tasked with creating websites and web apps using ASP.NET. Microsoft came to my rescue by introducing Web Forms. Nowadays, Web Forms gets quite a lot of hate from many directions about how un-web-like it was. But it helped people like me dip my toe in the web world without the fear that comes from something new. Microsoft successfully turned desktop developers into web developers. But it wasn’t without inherent risks.

Web Forms introduced drag-n-drop designing to web development. Under the covers, it was trying to hide the details of the web and feel like the server-side code was something akin to a stateful development solution. Add in ViewState and Session State, and lots of developers were able to accomplish a lot of value for their companies and employers.

But it’s now 2023. We’ve been through a world of change since those early days. For many Web Forms developers, it can be overwhelming to be asked to learn JavaScript on the client, separate concerns into Controllers and Views, and write code that is truly stateless. But that’s where we are now. There isn’t a perfect upgrade path to ASP.NET Core for Web Forms developers. But there are some ways to apply our existing knowledge without throwing out the baby with the bathwater. In comes Razor Pages.

Introducing Razor Pages

As an answer to Web Pages, Microsoft introduced ASP.NET MVC as a Model-View-Controller framework that separated (and simplified testability) views and logic. This has been the prevailing framework for many projects, although it never did replace Web Forms. After .NET Core was introduced, Razor Pages was introduced to have a model closer to a page-by-page solution instead of complete separation. Now with Blazor, another solution has been added to the quiver of tools. For this article, I’m going to focus on Razor Pages themselves as I think it’s the most straightforward migration path for Web Forms developers.

… this article is continued online. Click here to continue.

Page is Dirty using JavaScript

In the bad old days of desktop applications, every form object in the world had a Dirty property that let you easily check to see if the user had made any changes to the data on the form. It’s almost as easy with client-side code running in the Web browser, provided you use jQuery. This line finds every input tag and ties the tag’s change event to a JavaScript function called flagChanges:

$("input").change(function () 
            {
              flagChanges();
            });

Read more in Visual Studio Magazine;

Other References

https://www.c-sharpcorner.com/blogs/page-is-dirty-using-javascript1