Here is my honest question:

What's the actual problem with the useEffect hook? All over the X/twitter, I see a lot of negativity about this hook. It seems like a buggy thing in React.

My opinion is that developers blame useEffect because it's often used for data fetching as the primary use case. As we deal with various states like loading, data, error etc… synchronization of these causes bugs.

Also, a misunderstanding of the rendering cycle in React, such as where useEffect gets called could introduce additional misuses and bugs.

Hence, just saying useEffect is evil, may not be the right assumption is what I think. But, there could be cases that I'm missing.

What's your take or opinion about it?

If you're working on a React project and need some avatars for profiles, dashboards, user lists, comments, or mock data, here's a collection that might be useful.

There are 200+ free, open-source UI avatars that you can use in your projects.

There's also a UI Avatar Guide on the page if you want to learn more about using avatars in interfaces.

🔗 https://radianui.com/resources/avatar

Sharing it in case it's useful for anyone working on a React project!

Built this as a React and TypeScript single-page app with no server at all. It runs one prompt across up to 13 image models and shows the results in a grid so you can compare instead of guess.

React-specific bits that might interest people: all state is local (IndexedDB for images and metadata, localStorage for keys), the provider layer is a set of adapters behind one interface so a new provider is one file, and a strict CSP limits fetch to the provider domains, which forced some decisions about how errors surface in the UI. There's a light table component for marking up a contact sheet that I'm reasonably happy with.

MIT, single maintainer, happy to answer questions on the architecture.

Repo: https://github.com/hirashif/gridloom
Live: https://gridloom.app

What do people use for local-first persistence in React these days? I went straight IndexedDB and would do it differently next time.

A month ago I posted AdaptTable here. Since then the feature surface has grown quite a bit, and one of the more interesting problems has been keeping all of that optional functionality from turning the main table into one huge bundle.

Some of the heavier capabilities now have their own entry points:

@adapttable/core/xlsx
@adapttable/core/pdf
@adapttable/core/formula
@adapttable/core/pivot
@adapttable/core/stream
@adapttable/core/sparkline

The React adapters are moving in the same direction:

@adapttable/mantine/row-reorder
@adapttable/mantine/grouping
@adapttable/mantine/editing
@adapttable/mantine/virtualize
@adapttable/mantine/cell-navigation

The core entries already avoid the bundle cost unless they’re imported.
The adapter side is not completely there yet because some optional feature implementations are still reachable from the root DataTable import graph.

In v3 I’m moving those implementations out so the application only pays for the features it actually imports.

I’m also separating the framework-neutral engine logic from the React hooks/components, which should eventually make Vue and Angular bindings possible without duplicating the table engine.

For people who maintain larger React libraries: how far would you take this?

At what point do lots of feature-specific entry points become more annoying for users than the bundle-size savings are worth?

For context, this is the project:
GitHub⁠ · Live demo⁠ · v1 → v2.9 write-up⁠