Summary

In the second article of this series (click here to read part 1), I’m going to introduce the two types of state that exist in all user interface (UI) applications: essential and derived. It’s necessary to know the difference between the two otherwise you will not be able to implement them optimally. That will almost certainly result in a UI that is harder to maintain and re-renders unnecessarily, harming the user-experience.

Before we jump in, I’d like to briefly talk about a great paper on software complexity called “Out of the tar pit”. It’s an academic paper from 2006 that discusses in detail how software complexity is the root cause of most software development problems. I highly recommend reading through it if you’re interested in deeply understanding what makes software engineering complicated. It’s a bit of a long read, but definitely worth your time. The paper also discusses the impact of state, so it will also help you better understand how to solve state management issues as well.

Summary

This is the first in a series of posts about my philosophy around state management in Javascript User Interface (UI) applications. I want to note that I’m coming from a background having worked on some fairly large frontends, and may have some bias towards patterns that suit that situation. That doesn’t mean I want to push powerful frameworks for all situations. Far from that, I want this series to inform the reader on whether heavier frameworks are the right choice for their project.

In this introduction, I’ll be going over the definition of state management and how it relates to user interfaces. Then I’ll present a rudimentary example and go over its flaws so we can have a better point of reference when going over some frameworks available in the community. In addition to providing a basic summary, I’ll give some of my recommendations on which types of frameworks to consider.

This is part one of a two part series, in which I’ll detail an effective approach for architecting a validation framework for complex objects in WPF. In this part, I’ll talk about what is necessary to fully implement INotifyDataErrorInfo. There are a number of other tutorials about this interface, but I don’t feel any go into enough depth about what to do when facing a complex hierarchies of models. For this tutorial, I’m going to assume you’ve seen a few of these tutorials or have tried implementing INotifyDataErrorInfo, so I may skip over some of the more mundane aspects.

Over the past few months, I’ve been working on a hobby project, which I’ve uncreatively called MyDailyStuff. It’s written with Go on the backend and Typescript on the frontend (which I’ll talk about in another post). Code for the site is available at my github profile.

I’ll start with the summary of how I feel about Go. Basically, I’m glad it’s gaining in popularity because I think it has a good chance of taking a lot of marketshare from NodeJS, which shouldn’t be used nearly as much as it is. This isn’t to say that Go is a perfect language, far from that. There have been numerous posts about the pros and cons of Go on Hackernews and the like, so I’ll try to keep this focused on my experience building my application.

It’s a problem every web startup wants to have: too many users using their web application, bringing the server to its knees. Here are some common causes from my experience, each of which I go into more detail below.

• Too many requests made per page
• One or more database calls made for every request
• Too many calls made to your cache stores per request
• Push Notifications
• Template rendering

Recently I’ve added in the foundations for supporting an Android version of an MVVM/WPF application using Xamarin. The process wasn’t too bad and it only took a few days. Most of the time was spent replacing incompatible libraries with versions that were compatible.

Fortunately, a lot of open source authors are providing PCL versions of their libraries or supporting Mono outright. This means I can just simply reference those versions in the specific platform projects. So I was able to continue using Autofac, protobuf-net, and many others.

Coming from a web background (ASP.NET), tackling WPF was a lot more of a learning curve than I expected. I am glad to have this experience, and look forward to doing some Android development with Xamarin. Here are some notable things I’ve learned over this past year of writing a WPF app.

Ok, so it’s just the old platform that’s dead, not my blog. It’s been a long time since I’ve updated this blog, or even looked at it. Over the past year I switched to a new startup, and it’s been consuming a large portion of my time. Since I haven’t been updating this blog, I most certainly haven’t been updating LameBlog, my terrible second project in Node.JS. There were a lot of shortcomings in that little project, although it was at least very reliable. With the recent release of Ghost.JS and my lack of interest in fixing LameBlog, I think now is a great time to just use another platform. Hopefully I won’t have to switch again anytime soon.

I’ve learned a lot of interesting things over the last several months that I’d like to write down, but that will have to wait for later.