In the React world, most developers don’t think twice before using closures in their component render methods, especially when mapping over lists. ...
For further actions, you may consider blocking this person and/or reporting abuse
Antonio Moruno Gracia on July 14, 2025
For further actions, you may consider blocking this person and/or reporting abuse
Im not a fan of this approach because only serialisable data can be inserted into the DOM and then extracted back out into JS, and while you can simply use the ID to
findthe item in the array but doing so will cause so many loops that you lose any performance gained by removing the closures.While always, it depends on the situation, so it's nice to have it in your pocket should the situation arise.
That's why functional components in React are sucks.
Also most React developers do not even know that
useMemouseEffectuseStateand all other React hooks it is not only "magic hook" - this is functions which do some calculations inside.Take a look at this great article
mbrizic.com/blog/react-is-insane/
I personally try to get rid of using React hooks, I'm using MVVM and MobX which works with classes
Also if we will use
data-*attributes then this is killing any types in TypeScript, so this is not good.Also modifying
data-*attributes is not performant (calls reflow after change)Every class component should have render function with all drawbacks of function components and without ability to use hooks but only terrible on componentShouldRecieveProps, already ReceivedProps, maybeItsHereTimeToHandlePropsButMaybeNot, componentWillUnmount etc. Do not remember exact names but it was very close to it
Yes, agreed with you, but in hook way you must keep in mind how works useEffect with dependencies and how works closures in use* hooks. How simple works functional component and why declaration a lot of hooks in functional component body can be hurtful for performance.
This is a terrible article lol
Hard disagree. This article is extremely accurate representation of what 90% of enterprise and startup codebases contain right now. Anyone who denies it either has no experience or is too far the react cult to realize what’s happening.
So much this
Why ?
React has plenty of issues, but he’s criticising React for problems he created himself because he doesn’t understand it and write shit code
I’m not criticizing React. Actually I love it. I’m just presenting another way of doing things 😙
You should. at this moment, frameworks like Vue or Angular are now better and more modern / performant than React.
youtu.be/DLa2FQQzCr4?si=rSh0tlV-R5...
tldr: this is not a great article
That video demonstrates and perfectly proves the points in the article by showcasing snippets from his own code that contain useEffect hooks and also sharing examples from large projects that contain similar problems…
TLDR: that video is an amazing demonstration why the article is accurate and how blind React worshippers are for their own misery.
I am inclined to comment, just use Svelte and be happy 😁
It's also not typesafe, and for large data or long lists you will be serialising the data into strings ahead of time, before you even need it. It's cheaper to make a new anonymous function than serialising large data sets to string.
Keeping the data in memory and only accessing when needed is sometimes more preferable.
With the rise of SSR this may become more important, however I remember the time when getting data out of the DOM was a big push. The thing is, you always want a single source of truth for your data. If you put things in the DOM and have things in memory, you will have to figure which one to trust when they fall out of sync. Moving everything to JavaScript is easy, because AJAX goes straight to JS. The DOM cannot query the server and only understands strings. So if the DOM is your source of truth, how are you going to get data into and out of it? Will it be able to keep up?
I like this, I can see the uses for it.
But like everything in writing code, there are many ways to skin a cat.
And as engineers, we need to be aware of the security risks and use this with caution.
OK for UI-related non-sensitive data
Not OK for anything security-sensitive (roles, tokens, permissions)
Safe Use Example:
<div data-product-id={product.id} onClick={handleClick}>{product.name}</div>function handleClick(e) {const id = e.currentTarget.dataset.productId;
// Use it to fetch more info securely from backend
}
Unsafe Example:
<div data-auth-token={user.token}>...</div> // Don't leak sensitive data<div data-role="admin" onClick={showAdminPanel}> // Role-based access is not secure on frontend
This isn't quite true. A new function is created each render, but this is the only function that gets called for every item map goes over, not per ID.
For buttons, checkboxes, radio buttons you could also use the
nameandvalueattributes.Such a simple trick but so underrated..
I couldn’t get past the hyperbolic, made up statistic “99% of devs don’t do…” 😆
I've been using data-* with Stimulus controllers for a while now
I've never used react or know too much JS tho to be honest.
negatable on performance and isn't safe. only applied to primitives. DO NOT USE THIS.
i have been using this method for so long that means i am in that 1% .
Absolutely loved this perspective 👏 — never thought of using data-* attributes this way in React. It’s such a clean and elegant alternative when optimizing large lists or working with React.memo.
Yeah it is right, but nowadays most of the India based top 3d game development services provider companies were using new coding style to optimize the code as well as they were improving the coding technique by following latest coding trends.
Aha, so we're falling back to VanilaJs because it's better... then maybe React itself is a problem?
Yeah, I know we all know that.
I just wanted to mention that I figured out a better alternative to React - denshya proton.
Yep, I know changing tools are difficult due to Market Jobs being oriented on React, but questioning status-quo is always good imho.
The approach to use data attributes is interesting. However, using performance as an argument does not look convincing without proper evidence. In a theory you can safe "some", but in practice it may be not a big deal.
Another alternative to avoid issues with memoized components and lists can be to implement list element as a separate component (with memo wrap) that will return desired value (passed as a prop) through one of the onClick arguments (same way you did with data attribute, but moving this logic to the child element). This way you don't need to rely on data attributes at all and worry about reference check.
Personally, I believe data attributes are quite nice for CSS mostly (for example to show dynamic content through the pseudo elements). Or display some hints for debugging purpose.
Why not extract the map function outside of the view and use use callback?
while you do:
const id = e.currentTarget.dataset.id
you can also access it by doing:
if(e.target.(you can use id, tagName, class whatever you define) == "id, tagName, class"){
const id = e.target.getAttribute('data-user-id')
}
From a functional programming perspective, wouldn't using dataset open the door to side effects?
Is there any benchmark? The cost of type conversion overhead, longer code, meh.
i am in that 1%
Better will be just use $mol
Interesting idea. This approach has its uses, but there are good alternatives and some good ideas in comments too.
Broh, data-* attributes are available since jQuery era.
Do you really need to discover the wheel every 5 years?!?
I don't use React
Keep the rendering and the actual data/state of things completely seperate. State management has nothing todo with DOM-Rendering (or any graphical interface for that matter).
Just because you can does not mean you should
The writer hatches more complex problems than the mentioned closure problem.