Comment by mattlondon

Omg yes finally someone acknowledges this. I am always pointing out how react and jsx are a port of XHP. This is why react was class based at first (because php is a class based OO language).

Hack was created later though. XHP was a php 5 extension created around 2008

react can be pure functions that take in props. Given a set of props, ideally data primitives, the outputted view is guaranteed. it's nice.

In practice, the entire JS ecosystem enjoys flying off the rails, every season, but it's not strictly react's fault.

To answer your question, however those props get into the component is up the the M & C. can be async server, or shoved in as json in the script tag.

M stands for Model layer. This layer handles business logic and knows nothing about UI. It does not have any html or CSS.

V stands for View. This layer handles HTML and CSS. You can use React here.

C stands for Controller. Controllers know about Views and Models and which model objects to instantiate for which view. It makes REST API calls and does caching, and handles errors. Controllers know about the application state and decide what page to display next.

For an application written in this style see: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

(This app doesn't use React, but does use TSX, and you could use React as well).

- M for Model: your data model. - V for View: views of your data. - C for Controller: does stuff with your data.

In the original MVC architecture, the fundamental idea was that the model was responsible for storing the application state, a view was responsible for rendering output to the user, and a controller was responsible for responding to user interactions.

The model can be completely unaware of any specific views or controllers. It only needs to provide an interface allowing views to observe the current state and controllers to update that state.

In practice, views and controllers usually aren’t independent and instead come as a pair. This is because most modern UIs use some kind of event-driven architecture where user interactions are indicated by events from some component rendered by the view that the controller then handles.

My go-to example to understand why this architecture is helpful is a UI that features a table showing some names and a count for each, alongside a chart visualising that data graphically. Here you would have a model that stores the names and counts as pure data, and you would have two view+controller pairs, one managing the table and one the chart. Each view observes the model and renders an updated table or chart when the model state changes. Each controller responds to user interactions that perhaps edit a name or change its count — whether by typing a new value as text in an editable table cell or by dragging somewhere relevant in the chart — by telling the model to update its state to match (which in turn causes all views observing the model to refresh, without any further action from whichever controller happened to be handling that user interaction).

In practical terms for a React application, we might implement this with a simple object/Map somewhere that holds the names and values (our “model”) and two top-level React components that each get rendered once into some appropriate container within the page. Each component would have props to pass in (a) the current state and (b) any functions to be called when the user makes a change. Then you just write some simple glue logic in plain old JavaScript/TypeScript that handles keeping track of observers of the model, registering an observer for each top-level component that causes it rerender when the state changes, and providing a handler for each type of change the user is allowed to make that updates the state and then notifies the observers.

There are lots of variations on this theme, for example once you start needing more complicated business logic to interpret a user interaction and decide what state change is required or you need to synchronise your front-end model state with some remote service. However, you can scale a very long way with the basic principle that you hold your application state as pure data in a model that doesn’t know anything about any specific user interface or remote service and instead provides an interface for any other modules in the system to observe and/or update that state.

Mvc is why there's 3 languages: HTML CSS and JavaScript

The separation is already there

People have just failed to understand it

You have any more sources on MVVM being a mistake?

I found WPF rather nice to work with. Same with knockout.js and Angular I don’t see much downsides.

Everyone can write bad code of course in each of them but I think it was working quite well.

I've heard many people assert that 2 way binding is a mistake, but I didn't think it was settled. It still seems simpler to me than so called uni-directional data flow.

Those are all stateless MVC over HTTP, which is a very different architecture from stateful MVC for long-lived UI. The latter was invented for Smalltalk by Trygve Reenskaug, and is far more relevant to front-end web.

Stateful MVC uses Publisher/Subscriber (or Observer) to keep Views and Controllers up-to-date with changing Models over time, which is irrelevant for stateless MVC over HTTP. Plus, in stateful MVC the View and Controller are often "pluggable," where a given Controller+Model may use a different View for displaying the same data differently (e.g. table vs. pie chart), or a given View+Model may use a different Controller for handling events differently (e.g. mouse+keyboard vs. game controller). Whereas, in stateless MVC over HTTP, the controller is the "owner" of the process, and won't generally be replaced.

And in the world of front-end web, stateful MVC really is mostly dead. MVVM and Component-based architectures (using the Composite pattern) have replaced it. A runtime is usually responsible for wiring up events, rather than individual controllers. Controllers don't need to be swappable because events can be given semantic meaning in components, and Views don't need to be swappable because you can instead render a sub-composite to change how the data is shown.