←back to thread

873 points belter | 2 comments | | HN request time: 0.003s | source
Show context
dtquad ◴[] No.42948592[source]
>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy

As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very little time to migrate to Vite and update dependencies. By 2019/2020 React Hooks had already been out for some time but there were still some class components in the app. They were easily migrated to functional components + Hooks using ChatGPT.

replies(9): >>42948755 #>>42949267 #>>42949480 #>>42949689 #>>42951645 #>>42952358 #>>42953864 #>>42954167 #>>42960182 #
kflgkans ◴[] No.42952358[source]
If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me.

Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I could reason pretty well about what was called when and how state was manipulated.

Then hooks came around, I tried them a few times, but I just felt so lost. Suddenly everything is intermingled in one function and we're using side effects to react to changes and manipulate state. I could no longer understand when which code was executed, and especially following and manipulating state became impossible for me.

The projects I already, I kept with class components. Haven't done any new front-end projects since then.

replies(4): >>42952500 #>>42952837 #>>42953730 #>>42954908 #
sesm ◴[] No.42954908[source]
React's mental model has always been UI = F(data) and in ideal case any component is a pure function. But, of course, in most real apps there are cases when this mental model breaks: internal state, animations and side effects. The old way to provide escape hatches for those cases was to wrap a function into a class, where original function is 'render' method and the cases above are handled with lifecycle methods. The problem was that one piece of functionality often required updating several lifecycle methods, and for a big component that non-locality made things very hard. Hooks are a different way to express non-purity that keep code more local.
replies(1): >>42954991 #
1. kflgkans ◴[] No.42954991[source]
Thanks, that makes sense. Interesting perspective on the UI = F(data), I did not know that. I still wish the mechanics were a bit more... intuitive... I guess? Personally, I'm a big fan of The Elm Architecture [1]. I felt that is a very nice way to separate state and logic. But I'm not such a big fan of Elm itself (subjectively).

[1] https://guide.elm-lang.org/architecture/

replies(1): >>42963929 #
2. skydhash ◴[] No.42963929[source]
There was a great interview on ACM Queue [0] where they explain that paradigm. As a rule of thumb. Try to keep everything functional, and if you want to have state, keep it contained to its component.

[0]: https://dl.acm.org/doi/10.1145/2984629.2994373