Rushabh PatelOne of the biggest issues for web developers is taking upon a confusing ecosystem of competing, armed with different options and trying to get a hang off what they really require. The main cause of this is an article of its own: developers treating web development tools like a mere checklist for employability, rather than providing solutions to actual problems.
One can get a better view of the JavaScript framework by looking at what JS frameworks are structured, what problem they try to solve, and how do they attempt to solve.
If you ask around, you’ll typically get a range of answers, from things like reducing code, keeping the structure clean, reusable elements, etc. However, these things are just side-effects. The actual purpose is pretty simple. They are used to map the application state to the DOM.
What that means, is understood by knowing the opposite, and the best practical way to deal with that is to show some jQuery.
JQuery is considered to be a much-maligned library, but it excels at the direct manipulation of the DOM. Nevertheless, the problem is that direct manipulation of the DOM is how you get cooties. Doing it well just gives you cooties faster.
There are many problems here. It’s not that elegant, but it serves well. Moreover, it is entirely arbitrary.
A bigger problem is how do we get the name of the animal selected? We have to do some pretty gnarly DOM checking.
This solution is mostly error-prone, and not very resilient by design. Two things could be active or none. It might change when someone changes a class, or when another set of toggle-buttons is added.
This problem of having a clear “value” is normally fixed by storing that value somewhere else in the form of a hidden form field. Therefore, doing this also makes it faster and easier to submit the data as a form.
This makes the overall interface handling slightly better. Even though we’ve fixed one issue, we’ve created another one. For starters, there’s markup here now that may not fill any purpose at all other than as a bin for a number on the form. However, there’s another deep issue.
Let’s say for example we have another function on our hands somewhere that sets the animal, we got the data from Ajax request for example, and it was loaded as part of editing. Hence, the value of the hidden input is correct, but none of the animals appear selected. Your application state is now practically useless. To use a technical term.
As the size of an interface or an application increases, the potential for this sort of interaction and error rises quite unexpectedly. Having to keep the interface in sync and connection with the underlying data becomes incredibly tiresome, unreliable, and error-prone. Hence, there is no other way sadly.
There are things wrong with this React, think of it more as a React-like pseudo code that will keep you up until you can’t take it any longer.
The structure of a React component is very simple — the data that creates the interface is kept in the state property. Drawing the component with render uses that state to make decisions about how to render elements. Nevertheless, changes to that state (all done via the.setState) cause the component to re-render themselves, redoing all the previous layout decisions. This “single source of truth” for how things should look and behave is extremely critical, and what we missed in our jQuery examples. Fundamentally all of these elements are in any case “bound” to the state.
The problem is, none of the potential issues listed in the jQuery examples above will ever occur in this React example. We haven’t even tried to avoid them. They’re just inherently not problems, they’re meant to be. And they won’t become problems.
Furthermore, this isn’t to say that there aren’t other issues that can occur. Actually managing that state properly and consistently, and especially transforming it across components, can be quite difficult. This is where problem tools like Redux and Ember Data come and clear them out.
Application architecture is a pretty complex thing, and this view binding side of things is only half the picture. It’s one that JavaScript frameworks do in similar ways, despite their differing syntaxes. Larger application patterns differ significantly and it’s for reasons like these (which are not related to this article) that I prefer using tools like Ember. But the how and why to bind the state to the DOM is something with near-universal implementation for all, from Backbone to Angular 6.
Moreover, it’s important that you know the real reasons these frameworks are for, what problem they help to solve. Because that’s very helpful in making informed decisions about which ones to use. That you need to use is not a matter of if, but when.
