Eh, I wouldn't say that's true. It has a lot of "Christian democratic" parties (the likes of CDU/CSU), and also a bunch of 'liberal-conservative' parties (there's a fair bit of crossover). However, it's pro-Europe, and certainly not particularly nationalist. Nationalists (at least ethnoreligious nationalists; leftist nationalists like Sinn Fein go elsewhere) would largely be in ECR, the absurdly-named 'Patriots.eu', ESN.
I was just responding to the usage that the parent commenter had which was
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
which I interpreted as the only possible meaning, in relation to React, being UI components that must rerender as close to immediately as possible vs. UI components that do not need immediate rerendering when the underlying data has changed.
I realize that is not a particularly correct use of the phrases, but then that is what happens when you use a concept from one type of development metaphorically in another type of development, memetic slippage as it were.
> In immediate mode, the scene (complete object model of the rendering primitives) is retained in the memory space of the client, instead of the graphics library. This implies that in an immediate mode application, the lists of graphical objects to be rendered are kept by the client and are not saved by the graphics library API. The application must re-issue all drawing commands required to describe the entire scene each time a new frame is required, regardless of actual changes.
React is simulating immediate mode by having the developer describe the full rendered result from the current data state. The developer / app code doesn't need to keep track of what changes need to be done to get the browser from its current state to the desired state, React does that for you.
Retained mode is where the developer / app does have to concern itself with the current browser state and issue the desired updates themselves, like how everything was done in the jquery era and earlier.
>components should be simple and not store data in themselves.
That is a ”controlled component” model which is bad for interactivity, especially text inputs.
If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.
Without a rerender, it must now use a reactive binding to update the field value.
If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.
Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.
I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.
Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.
reply