It seems a little crazy to think about an application as just a reflection of the data, but I believe it is actually true. I've been building front-end browser applications for a long time, but it wasn't until I started getting into Clojure and ClojureScript (which was pretty recently) that the lightbulb went off for me.
What Are Components Really?
Let's forget about the syntax and specifics of Angular components or React components and just think about things abstractly for a moment. The concept of components is actually pretty simple. Fundamentally, it's just a way of enabling you, the developer, to break down your application into modular, composable chunks. It also let's you tie together your front-end "skeleton" (the HTML elements that would be completely static without JavaScript) and the data (which is stored in your JavaScript code). A component often represents one visible section of a web page and normally includes an HTML file, a JavaScript file, and a CSS file (or files that compile down to each of these or the equivalent).
What Do You Mean By "Data"?
You might laugh at that question, but data is a pretty overloaded word. Sure, your application has data, but it has variables, functions, algorithms, and all kinds of other crazy things so where do you draw the line between data and not data? Can you point at something and tell if it's data? Well, I'm going to give you my definition of data. To me, the "data" of your application is all about the literals, and when I say literals it basically boils down to two things: strings and numbers. Sure, some languages (like C) only have characters (not string data type), and languages like Java have many different types for various use cases for numbers (Integer, Float, BigInteger, Ratio, etc.). However, in my mind these all roll up into strings and numbers, the two ways to really convey an underlying value. The only other thing I consider data besides the literal are collections. In an actual real-world application we often have collections of these literals (or collections of other collections, but if you keep digging you'll eventually hit some literals). Collections have slightly different features and names in different programming languages, but they are often called things like: Array, Vector, Hash Map, List, etc.
So that's what data is, according to Jim. Literals and collections. That's it! This is why when talking about Clojure people often say the phrase, "code is data". In Clojure, everything is an expression, even function calls. The syntax to write an expression is just a list collection containing the function you want to be invoked along with the arguments you pass to it. In Java you don't put every statement inside of an array, do you? No, that doesn't even make sense... But in Clojure you do. In Clojure, all the actual code is contained in list collections, and collections are data. Therefore, in Clojure the code is data. Ok then, let's move along!
Tying the View to the Data
This is an area where front-end frameworks like Angular or React can help out a lot. In the old days when the web was just a young lad we would have to manually update the DOM with JavaScript code when we changed something (queue the nostalgic JQuery memories). These modern frameworks offer a nice syntax for, in one way or another, reading a value (or multiple values) from the data and displaying it in the HTML template. With Angular and React changes are detected as well, and the refreshing of the page is largely handled automatically. This is fantastic for us as developers because all we need to do is focus on the data. In fact, I can remember a quote from one of my teachers, George Dagger, back when I took his AngularJS class. He would say, "AngularJS makes you a promise. It promises that if you can get your data correct then Angular will handle displaying it in the view". This is absolutely true, and it alludes to the the fact that what you see on the screen of is actually just a reflection of the data.
The Data Should Be In One Place
(And Not in the Components)
Whether you are developing for Angular or React, only the beginner tutorials recommend keeping the data of your application inside of the components. Maybe many people begin by just hardcoding variables in their controllers, but really it should be refactored out (and you'll run into problems when you want to share data across multiple components). In my early AngularJS projects I basically invented a very rudimentary example of a data store. It was simply an AngularJS service that contained an object. I could then inject this singleton service into any component (or other service) in my application, and everyone was sharing the same data. This satisfies our rule of 1 (there should not be multiple instances or objects representing the same data) and the rule of separation (that the data should be separate from the controller logic). This worked fine on the small projects, but there is another popular way to store and interact with your data: Redux.
Redux: The Big Guns of Data Management
There is one single phrase that I must have repeated in my head thousands of times over a few months before I finally understood Redux. I already had my Angular-service-object way of managing state, and I was curiously about yet it very resistant to adopting it. The phrase kept reminding me of the subtle problem with my homegrown data store. The phrase that was repeating in my head was, "When something in your data changes, you don't know what changed it". Indeed, I would set a variable on my service's object and it would change. I wouldn't know what controller changed it, what line of code, nothing. This in itself won't cause your app to break, but it can make debugging issues in large apps a huge drag that could eat up a ton of time. Suppose someone finds a bug in the application- but of course the application is just displaying its underlying data. Ok, well how do you know where the data got fudged up? There isn't really a good answer in my simple service solution. Especially if you have interconnected components and cascading changes that affect your data in multiple ways, things can get hairy pretty quickly. With Redux, every change to the data is triggered by an action. When debugging you can then follow along and step through every change in your data to try to see exactly where things went wrong. With a somewhat elaborate message dispatching system and strict rules for keeping your data immutable, Redux has emerged as the "enterprise level" solution for keeping track of your data in the modern age of front-end development.
How Does This Help Me?
I'm imagining someone reading this and saying, "Ok. Your app represents the data. So what?". I don't know why it was such a big deal when I came to this realization, but for me it just simplifies software development in so many ways. Have you ever tried redrawing a sketch of a picture when you are holding it upside down? The point of it is that it takes away the oppressive left-brain thought processes and allows you to see things for what they really are. It's analogous to looking at the drawing as it's lines instead of the image that it represents. A wise person once said that drawing well is more about seeing than it is about moving your wrist. I like to believe there's an analogous phenomenon going on in front-end development. People think of their favorite sites as tools for them to wield, as places for them to escape to, and things that benefit them in some way. However, when you step back and look at it as just a manifestation of some collection of strings and numbers it just seems so much less complex. I know others see software as what they use it for, but now I see everything as just a visual representation of data. It's as as my eyes are now open that I can imagine a clean path from taking any software project from an idea to a reality by just deciding on what it's underlying data will be and how the user interacts with it. I hope I've inspired something in you so help you see front-end development a bit differently. Build a pretty way to visualize the data, and then build a means for the user to manipulate the data. You can do those two things and build virtually any front-end application!
What Do You Think?
Do you agree that all front-end apps are just pretty, interactive manifestations of data? Have I fundamentally changed the way you think about programming? Or, possibly you disagree and can provide some counterexample. Maybe you knew all this already and you are angry that I wasted so much of your time with this post. hehe. In any case, I'd love to hear from you so feel free to leave me a comment. Happy buiding! :)
RSS Feed