Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Tired of logic in useEffect, I built a class-based React state manager

thales.me

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#31

Post by benatkin »

apatheticonion wrote: post #19
hungryhobbit wrote: post #4

Javascript and classes go together like toothpaste and orange juice. All good JS programmers I know essentially pretend that classes don't exist in the language (or if they use them, they only do so rarely, for very niche cases). JS does not have classical OOP built in! It has Brandon Eich's prototypal inheritance system (which has some key differences), along with a 2015 addition to the language to pretend it has OO…

I have noticed that inheritance is largely ignored by experienced developers but it's a hard argument to make that "all good JS programmers do this". Classes are invaluable and are an extremely efficient and ergonomic way to manage state in GUI applications. That said, avoiding classes was published in some blog post at some point and the JS hype machine went crazy with FP. As a consequence, I have yet to observe a m…

Inheritance is used here:

https://github.com/thalesfp/snapstate/blob/ba8a8d7ce25d6a4ef...

I'm not sure if it would support inheriting from a custom store very well. It might get tricky with the templating. But the author of this seems to have done a good job of not ignoring inheritance.

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#32

Post by lateforwork »

DauntingPear7 wrote: post #24
lateforwork wrote: post #8

Earlier quoted context omitted.

Encapsulation, inheritance and polymorphism all work fine with JavaScript classes. OOP works just fine. What doesn't work in JavaScript is functional programming.

I don’t see how? You can do all sorts of FP in js and it even has some of it in its built in APIs. .then comes from FP

You are right, there are some FP features in JavaScript. But the way it is used in the predominant UI framework (namely React) is definitely breaks FP, see https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#33

Post by bobthepanda »

lateforwork wrote: post #27

You can use React in an MVC framework, with React used to implement the 'V' in MVC. You can use class components, and the code becomes extremely simple. Business logic is moved to 'M' layer (models) and the 'C' layer (controllers) coordinates everything. No hooks or other messy stuff needed. In fact, React was originally designed to be used this way (as the V in MVC)! See https://github.com/Rajeev-K/mvc-router

You can do this pretty simply with hooks and reducers, where the reducer/dispatch are the model/controller.

Class components have their own pitfalls when you start messing around with componentDidUpdate, which was part of the motivation behind functional components IIRC.

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#34

Post by lateforwork »

bobthepanda wrote: post #33
lateforwork wrote: post #27

You can use React in an MVC framework, with React used to implement the 'V' in MVC. You can use class components, and the code becomes extremely simple. Business logic is moved to 'M' layer (models) and the 'C' layer (controllers) coordinates everything. No hooks or other messy stuff needed. In fact, React was originally designed to be used this way (as the V in MVC)! See https://github.com/Rajeev-K/mvc-router

You can do this pretty simply with hooks and reducers, where the reducer/dispatch are the model/controller. Class components have their own pitfalls when you start messing around with componentDidUpdate, which was part of the motivation behind functional components IIRC.

Not everyone likes hooks. Class components may have issues, but if hooks are the solution I'll stay with class components, thank you very much!

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#35

Post by apatheticonion »

benatkin wrote: post #31
apatheticonion wrote: post #19

Earlier quoted context omitted.

I have noticed that inheritance is largely ignored by experienced developers but it's a hard argument to make that "all good JS programmers do this". Classes are invaluable and are an extremely efficient and ergonomic way to manage state in GUI applications. That said, avoiding classes was published in some blog post at some point and the JS hype machine went crazy with FP. As a consequence, I have yet to observe a m…

Inheritance is used here: https://github.com/thalesfp/snapstate/blob/ba8a8d7ce25d6a4ef... I'm not sure if it would support inheriting from a custom store very well. It might get tricky with the templating. But the author of this seems to have done a good job of not ignoring inheritance.

Personally this library isn't to my taste - but I successfully use classes (without inheritance) along with reactivity primitives to create beautiful, tiny and high performance React applications

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#36

Post by altbdoor »

dsego wrote: post #10

Sorry for being pedantic, but the first example could be rewritten to extract the pattern into a higher level hook, eg useNotifications. One way to simplify components before reaching for store libraries. The reusable hook now contains all the state and effects and logic, and the component is more tidy. function Dashboard() { const { user } = useAuth(); const {loading, error, notifications, undreadCount, markAsRead}…

Working with multiple teams in a large project, hooks can be a nightmare to maintain.

I see 7x layers deep of hooks, with no test cases to support them. Some of the side effects are not properly tested, and mocks that abstract away the whole implementation means the test case only works for certain scenarios.

FWIW this scenario might be an outlier in large projects, considering how some developers prefer to "just wrap the hook in another hook, and not worry about its internals".

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#39

Post by spankalee »

Weebs wrote: post #23
spankalee wrote: post #9

Earlier quoted context omitted.

Counterpoint: classes are a great way to bundle state and logic - which is exactly what UI components are - and components models should use classes more , not less. React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's curren…

They're modeling reactivity, not classes. It's a well established pattern in functional programming The one time setup mixed with repeated render calls is odd, but it's a design decision they made. It reduces boiler plate, though I don't necessarily agree with it because it is a leaky abstraction

Reactivity and functional programming are orthogonal though.

And in most functional systems the one-time setup function would return the render function so the render function can close over state.

Which is pretty much what a class with fields, a constructor, and a render method give you.

Re: Show HN: Tired of logic in useEffect, I built a class-based React state manager

#40

Post by oDot »

svieira wrote: post #30
oDot wrote: post #16

The problems OP tries to address are unfortunately a deep design flaw in mainstream frameworks like React and Vue. This is due to 2 properties they have: 1. They marry view hierarchy to state hierarchy 2. They make it very ergonomic to put state in components I've been through this endless times. There are significant ways to reduce this friction, but in the end there's a tight ceiling. This is why this kind of work…

Is this because Elm forces you to separate the model computations from the view computations, which then lets you compose the model shape in one place and the view shape in the other, or some other property of the framework that I'm not aware of?

Yes. In the Elm architecture it is possible (and ergonomic) to model your state separately from the view
Post reply on HN