2

Quite a while ago there was a concerted trend in the industry to move towards adopting templating to separate markup from logic, or something like that. The result was much more pleasing to the eye and I would argue much easier to develop and debug.

I had no idea what to expect this weekend when I started examining react.js. I had heard it was a "functional reactive" take on web applications and that sounded good to me. I was very surprised by just how different it was than, say, Angular or Backbone or really every other library out there.

It is plainly obvious that the creators of react.js chose to buck the trend of templating and return to the ASP/PHP pattern of writing markup in code. This was a huge surprise to me because it is not as though they found a way to do so that is significantly less ugly than what we had before - they offer React.createElement and React.DOM but it is still what it is.

This means that it would be radically harder to port an existing, say, Angular application with a large custom stylesheet over to react.js in a manner consistent with their philosophy.

I'm having trouble though understanding what that philosophy is, or in other words, why on earth they made this decision. Obviously, they know what they are doing, and I do not, so please enlighten me...

tacos_tacos_tacos
  • 1,071
  • 1
  • 9
  • 16
  • 2
    Thanks, I've removed the obsolete comments. Now, you might be interested in taking a look at [Flux](https://facebook.github.io/flux/). It's react's mvc thingy, and it's a lot more closely comparable to angular than react itself. – yannis Dec 30 '15 at 09:28
  • Thanks, I did see it in passing but with so many libraries out there it's hard sometimes to figure out which ones are worth looking at. I'll take a look... but the fundamental question is the same, which is just... why? – tacos_tacos_tacos Dec 30 '15 at 10:51
  • Related question: [Why is JSX good, when JSP scriptlets are bad?](https://softwareengineering.stackexchange.com/questions/302942/why-is-jsx-good-when-jsp-scriptlets-are-bad). – sleske Dec 13 '17 at 12:51

2 Answers2

2

I am also MVC grown. I believe we'll need to dive into FLUX to understand full picture.

My understanding is that as HTML templating moved to browser (with Backbone or Angular frameworks), this single page application can provide much better interactive experience to user than traditional web app with server side tamplating. For example you application can hold the state of application and base on some user action update various HTML elements instantly without roundtrip to server.

But handling state turned to be complicated with Backbone or Angular 1.x (not sure how Angular 2 handles it so far), because MVC or MVx patterns couple data model with view via controller or directly. But what if you want to react in other views on state change of the this model? Angular 1 provides some features for handling this, but you can easily shoot yourself into foot with nested controllers or nested scoping.

So FLUX movement is trying to address this and introduced this unidirectional flow:

----> Dispatcher ----> State Store ------> Component(View) -----> Dispatcher

Component or various components are subscribed to certain model state changes and sends user actions to Dispatcher. Dispatcher based on these actions updates model (State store), which can again trigger one or more View updates. Dispatcher action doesn't have to be triggered from component only. It can be done from server also. This way sharing the state(models) between views is much easier.

Now, React.JS is component from above diagram. Fundamental part of is that it doesn't mutate DOM directly, but uses shadow DOM concept, where it gathers differences against previous DOM state and applies only them. So you can re-render a lot or even all of your components, without worrying about performance mostly.

Consequence of all this is that React component have these concerns:

  • Needs to use Shadow DOM to mutate HTML
  • Needs to subscribe to model (State Store) changes
  • Needs to dispatch actions against State Store

If you mix all these concerns into single component, you get JavaScript buried inside template as you discribed. I was also horrified about this when I started looking into these areas of UI development.

React ecosystem is evolving rapidly and there are attempts to enhance this. For example look how Dan Abramov (creator one of the hottest State Store libary called Redux) separates these concerns into so called Presentational and Container component types.

So long story short, it looks as step back at first, but if you dive deeper, you may gain much bigger maintainability benefits in long run in form of true decoupling model from view.

BTW, I recommend to check this video on FLUX vs MVC.

luboskrnac
  • 896
  • 8
  • 10
1

One important point to realize is that you don't write traditional string based templates. JSX is only a syntax sugar to create plain javascript object. It gives you static analysis and unit test ability. It it quite a difference from any previous attempts to mix code and markup.

As already pointed out with functional components which are just plain javascript functions which take arguments (props) and return JSX you can decouple view from logic as you wish and keep them in separate files, even in a separate NPM module you can easily share within your projects.

If you compare it e.g. to Angular2, it hooks template using decoration. React hooks it in its render method which can render just a single view component which subsequently renders the rest of the view tree without a stateful logic. Hence not much of a difference. Actually could anyone elaborate on any practical difference?

If you think about it what is the advantage of string based template which has limited possibility for static analysis, is hard to unit test if actually possible without E2E tests and requires proprietary templating language? Just stupid typos in hooked event handlers and such.

To create React "templates" I need just javascript which is just fine to use for this purpose with ES6 features. But some might prefer specialized language for it, it some cases it giver more conciseness.

Angular 1.x is not HTML either because its HTML is heavily annotated with proprietary directives which have to parsed in browser and converted to actual HTML.

What is the advantage of putting JS into HTML, which means putting code hooks into string? HTML is less powerful than JS. What is wrong with an idea to control less powerful HTML from more powerful JS? Especially when you can put in how many indirection you wish.

Learning JSX is pretty much to realize to use className and htmlFor and learn '{}' escaping. If you don't want to componentize, you can pretty much copy paste plain html and bulk find/replace above 2 arguments (possibly some more). As a advantage it is very easy to define repeating patterns as components to define app wide look&feel:

// ES6, advantage is you see props requirements from function signature
const Button = ({labelText, ...some more}) => (
  ... your "markup" ...
}

// ES5
function Button(props) {
  return (
   ... your "markup" using props.labelText...
  )
}

Is anyone able to summarize why previous attempts to mix code and markup failed? Does React has the same limitations?

petrn
  • 11
  • 1