4 ms·
I understand what you mean but at the same time in the web-dev world I find it interesting that React is migrating from OOP to functional. ("We recommend defin
by uticus 3y ago
I understand what you mean but at the same time in the web-dev world I find it interesting that React is migrating from OOP to functional.
("We recommend defining components as functions instead of classes." at top of page at https://react.dev/reference/react/Component https://react.dev/reference/react/Component)
- codeptualize 3y agoReact has always used functional programming patterns. They used classes to define components, but even those applied functional principles.
- meheleventyone 3y agoFrom the looks of things the main benefit is less boilerplate? What are the other benefits from beyond this?
- codeptualize 3y agoMainly hooks. Hooks make it easy to reuse component logic, something that was difficult with class components. You’d need HOC’s which are hard to deal with, especially with prop collisions and refs. (This change has little to do with OOP vs functional. React calls them function components, not functional. React has always used functional patterns, even in the class components.)
- meheleventyone 3y agoThanks I went and looked up the different approaches (have never written a line of React in my life) and I definitely like the hooks more on first blush.
- mike_hearn 3y agoReact isn't actually functional. It's OOP in disguise. There's no such thing as functional UI, in the classical sense of FP. It's one of the weaknesses of FP. Although React tutorials start by saying your UI becomes a pure function of your app's state, React components do have encapsulated state. Any time you call useState inside a react function you're doing something that doesn't exist in real FP programs. Additionally React boils down to a way to create DOM elements, which are highly stateful C++ objects exposed to JavaScript, implemented using inheritance: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/html_button_element.h;drc=b5fa1427d7ab0f37a5ea6f61fae9eec9fbda460d;l=34 https://source.chromium.org/chromium/chromium/src/+/main:thi... An HTMLButtonElement is a HTMLFormControlElement is a HTMLElement (and a ListedElement and a FormAssociated). The rules for how you write code in React (or Jetpack Compose) violate even the most basic rules of the host language. useState defines or returns what is effectively an object field (it's data associated with that widget), but it looks syntactically like a local variable. It's not a local variable though because its value will survive the exit of the scope. Nor is useState a normal function call because there's a hidden invocation counter used to work out what state slot you want, which is why you aren't allowed to call it inside conditional branches and why loops need special handling. So in React's "functional style" we can see that you're actually defining objects with encapsulated state, that register event handlers, that export properties and so on. It's just obfuscated to look like it's not OOP.
- mwcampbell 3y agoI'm curious, do you have a current favorite way of implementing UI, particularly for desktop applications, that isn't obfuscated and doesn't violate the rules of the host language? Or do you find that Jetpack Compose is a good choice overall despite those shortcomings?
- mike_hearn 3y agoI'm still making up my mind about Compose, there are aspects I really like and aspects I really don't. It's not the fault of Compose itself, the aspects I don't like are basically the conceptual model as copied from React. Honestly for recent simple GUIs I've made for my own in house tools I'm still using JavaFX. Mostly because I always seem to end up needing a good table view, and because I happen to know it. If I were working with it a lot I'd end up maintaining a TornadoFX style set of wrappers but for simple stuff the plain API works OK. Because I'm weird I'd probably use it for low-traffic web apps these days too, with JPro (jpro.one). Probably not for mobile web, and not for stuff where users are on high latency connections in general, but if the user has a nice big screen and a low latency connection I'd personally find it a lot easier and more productive than dealing with HTML and CSS. The results are indistinguishable for the user if you are careful.
- mwcampbell 3y agoThanks for that info. I promise the original intent of my question wasn't to find an excuse to nag about accessibility, but I should point out that JPro is certainly not indistinguishable from typical HTML for a screen reader user, judging by the JPro website. In particular, the links are marked up strangely, with a separate link for each word in a multi-word phrase, and there are no headings or landmarks to aid navigation. Just thought you should know.
- convolvatron 3y agoyou can certainly write functional UI using a differential 'pure core state on the outside model' (someone here had a discussion that gave this thing a name)
- kaba0 3y agoReact is not a UI library itself -- the actual UI stuff is delegated to the DOM. It is more like a library on top a UI library, that manages the state->representation flow (where reactive FP is indeed a good choice).
- ithkuil 3y agoAnd in case it wasn't clear let's say it explicitly: the DOM is pretty much an object oriented model (the O stands for object)
- mostlylurks 3y agoYes, but the fact that react uses the DOM is because that is what the very restricted platform gives you out of the box, and opting for other options would have several disadvantages that are purely the result of those other options not being directly provided by the platform itself. A reactive UI library (like react) could very easily be implemented on top of other UI paradigms as well, including decidedly non-OOP ones. There's nothing special about object oriented UI systems that motivates reactive UI libraries to use them except for the fact that that's what the underlying platform provides because that was what was in fashion when the platform was taking shape.