It's not just react query, you can make a quick useFetch and useMutation hooks (or claude can), it's not that complex. If you don't need more advanced features (eg caching), you can easily cut down on 3rd party dependencies.

    import { useState, useEffect } from "react";

    function useFetch(url) {
      const [data, setData] = useState(null);
      const [loading, setLoading] = useState(true);
      const [error, setError] = useState(null);

      useEffect(() => {
        const controller = new AbortController();

        fetch(url, { signal: controller.signal })
          .then((res) => res.json())
          .then((json) => {
            console.log("Data:", json);
            setData(json);
          })
          .catch((err) => {
            if (err.name !== "AbortError") {
              console.error("Fetch error:", err);
              setError(err);
            }
          })
          .finally(() => setLoading(false));

        return () => controller.abort();
      }, [url]);

      return { data, loading, error };
    }







    function App() {
      const { data, loading, error } = useFetch("https://jsonplaceholder.typicode.com/todos/1");

      if (loading) return <p>Loading...</p>;
      if (error) return <p>Error</p>;
      return <pre>{JSON.stringify(data, null, 2)}</pre>;
    }

Yeah, fetching data from a server in useEffect is a widely acknowledged and documented antipattern.

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.

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?

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".

I was wondering if I was crazy for thinking "how is what he's suggesting different than just putting that 'class' into a hook function?" I'm glad to see someone already wrote it up, kudos.

@OP: PEBKAC, respectfully.

Far cleaner, how is testability though?

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 current state you can't introspect with dev tools!

The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).

It's actually quite mad.

And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.

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 maintainable React codebase. Good looking and performant React applications are even fewer and farther between.

Personally, writing idiomatic React has me focus too much on render cycles that I think less about how the application looks & feels. Appropriate abstractions become more difficult to conceptualize and any non-trivial application ends up a 5mb bundle with no multi-threading or optimizations. This is also what I have observed "the best JS devs" do in the wild.

> Javascript and classes go together like toothpaste and orange juice.

Even HN has been taken over by shills from Big Mint.

Encapsulation, inheritance and polymorphism all work fine with JavaScript classes. OOP works just fine.

What doesn't work in JavaScript is functional programming.

I think the biggest issue with classes is subclassing, it looks like a good feature to have, but ends up being a problem.

If one avoids subclassing, I think classes can be quite useful as a tool to organize code and to "name" structures. In terms of performance, they offer some good optimizations (hidden class, optimized instantiation), not to mention using the memory profiler when all your objects are just instances of "Object" can be a huge pain.

For clarity, what do you call "classical OOP"?

(disclaimer: FP all the way, regardless)

Potato potato. Js classes are just closure sugar. So what?

Syntax makes sense and improves readability in business logic. Readability is good

I went through the code, and it is roughly equivalent to doing it without classes. The nesting level in the example isn't deep - everything seems to be beneath a SnapStore or a SnapFormStore, without inheriting from user defined classes. I think the use of classes is fine, and the way that it's introduced in the blog post is good, it says "plain TypeScript classes". It is used as a means for ergonomically writing and understanding the code more than it is for setting up invariants or complex polymorphism.

I wish I'd never used current-day React as well