5 ms·
I don't agree with your core thesis, "redraw" and "draw" are imperative verbs which are ubiquitus in winapi, `return <b>{msg}</b>` is not a verb but a value, th
by dustingetz 11y ago
I don't agree with your core thesis, "redraw" and "draw" are imperative verbs which are ubiquitus in winapi, `return <b>{msg}</b>` is not a verb but a value, this not superficial or an implementation detail, but rather a massive change in programming model to the point that IMO comparisons that overlook this difference are not useful at best and harmful at worst
- onli 11y agoWhy? Where is the practical difference for the program design between "returning html that the browser then draws" to "drawing themself" at the end of the flow? Serious question, and I'm not a Windows programmer, I might be missing something.
- dustingetz 11y agoyour question resolves to when to choose imperative vs OO v functional, and while I'm not going to try to discuss that here, they are profoundly different. Winapi is imperative, React is functional.
- coldtea 11y ago>Winapi is imperative, React is functional. That's a red herring. That would be relevant if we were discussing the imperative vs functional methodology. But what the article discusses is the similarity in the architecture of two view management systems. And even more so, the imperative changes in the Windows scheme described are encapsulated inside the views, and the overall system is more functional that you give it credit for. But, again, I think that this is beside the point.
- duncanawoods 11y agoI call forceUpdate to trigger redraws when view state is managed outside of props. Feels like an imperative redraw to me. https://facebook.github.io/react/docs/component-api.html#forceupdate https://facebook.github.io/react/docs/component-api.html#for...
- aljones 11y agoWell, yeah. That isn't the recommended way to use react.
- duncanawoods 11y agoIts pretty essential for non-trivial applications with data-structures more complex than can be handed over to React. setState is just sugar - it also calls forceUpdate.
- bmm6o 11y agoThere is no practical difference. You could argue that manipulating the DOM is the closest analogy to Draw(), but trying to make a distinction between that and generating HTML (that is going to be used to update the DOM) seems like splitting hairs.
- bmm6o 11y agoAnd: It's true that DOM manipulation could be seen as "lower level" than HTML generation, but the main difference for programmers is the API. A framework that forced you to call createNode('b') and createTextNode() and appendChild() would not get the adoption that one which lets you say "return '<b>Foo</b>', all other things being equal.
- kpmah 11y agoComponents drawing themselves is a side effect, and components returning markup are pure functions of their state. One is a lot easier to unit test than the other, for example.
- coldtea 11y agoThat's because HTML has an abstract declarative way to define the layout/drawing whereas Windows did not. But that's not especially important when it comes to React in general. The important is that the "how to draw myself" (in a high level) never leaves the view, not whether the "drawing instuctions" happen inside the app (as low level draw commands) or outside (by a mechanism that handles composable values representing markup). In both cases the view is a black box -- in that nobody else determines it's layout/style/contents. Whether somebody else or the view itself draws them might reflect a functional vs more imperative style, but it's not the key benefit of react. In fact there are React implementations like React-Canvas that don't use the DOM/diffing mechanism at all -- they just invalidate the whole top level "viewport".