--- title: Start naming your useEffect functions, you will thank me... description: Naming useEffect callback functions instead of using anonymous arrow functions is a small syntactic change with outsized benefits. Named effects make... canonical: https://daily.dev/posts/0b7zviajg twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Start naming your useEffect functions, you will thank me later | daily.dev og:description: Naming useEffect callback functions instead of using anonymous arrow functions is a small syntactic change with outsized benefits. Named effects make... og:url: https://daily.dev/posts/0b7zviajg og:image: https://api.daily.dev/og/posts/0B7ZviaJG.png og:image:alt: Post cover image og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Start naming your useEffect functions, you will thank me later **[Kirill Kurko](https://daily.dev/sources/ixalnaxwmtgrftz6xdx4u)** · [@kkurko](https://daily.dev/kkurko) · 270 upvotes · 31 comments ## Summary Naming useEffect callback functions instead of using anonymous arrow functions is a small syntactic change with outsized benefits. Named effects make components scannable at a glance, improve stack traces in error monitoring tools like Sentry, and surface design problems: if you struggle to name an effect without using 'and', it's doing too much and should be split. The naming discipline also reveals effects that shouldn't exist at all — derived state, event handler logic, or state-to-state sync that belongs elsewhere. The post walks through a real inventory sync component, shows before/after comparisons, discusses when to prefer custom hooks vs. inline named functions, and shares a story where naming five Mapbox effects led to consolidating them into three cleaner ones. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@yaireo** · 12 upvotes > hmm I don't think so. If you use sourcemaps (and you **should**) then you'll get the exact line which has caused a js error. and you should, very much, add code-commends everywhere, in order to better understand the reasoning of each code piece which isn't easily understandable and especially if the reasoning behind it is only known to the person who wrote it. > > I do not advise doing this and I'm a very senior frontend dev for over 20 years with maximum experience with React specifically **@itsabluecloud** · 7 upvotes > I had the same realisation and found it surprising how we have normalised anonymous functions in react. **@fabianletsch** · 6 upvotes > I am a huge fan of writing my code in the idiomatic way, basically the most standard way possible, because then you dont have to teach new talent conventions, you dont have to teach ai conventions, you dont have to explain your reasoning again and again and you dont have to write a custom eslint rule to enforce it. > > > In this case, i agree that the effects in his example make you parse what they do instead of just telling you with a name upfront, so i agree on the problem. > > > But i for one usually resort in such instances to writing a comment above the useEffect, explaining it. > > > Now i think... **@dhruvparmar92** · 5 upvotes > Insightful @kkurko, I will try too, as when working with [Socket.Io](http://Socket.Io) in frontend its hard to handle every useEffects for the Socket events. > > By applying this 'Naming to useEffect' would be easier to debug from where the data/ error is coming. > > Thanks! man @kkurko for sharing such an helpful content. **@alejandrobailo** · 4 upvotes > The best thing you can do is **not to use useEffects**. > > I've created a **SKILL** to achieve that: [https://github.com/alejandrobailo/no-use-effect](https://github.com/alejandrobailo/no-use-effect) ## Similar posts on daily.dev - [Don’t just attend KubeCon \+ CloudNativeCon, Merge Forward your experience\!](https://daily.dev/posts/don-t-just-attend-kubecon-cloudnativecon-merge-forward-your-experience--l0rpp73x8) · CNCF · 1 upvotes · 0 comments - [Announcing H2 2026 KCDs](https://daily.dev/posts/announcing-h2-2026-kcds-m96goajm1) · CNCF · 1 upvotes · 0 comments - [Two months of Open Community Groups](https://daily.dev/posts/two-months-of-open-community-groups-asf52zhbs) · CNCF · 0 upvotes · 0 comments - [CNCF Unveils Schedule for KubeCon \+ CloudNativeCon Europe 2026](https://daily.dev/posts/cncf-unveils-schedule-for-kubecon-cloudnativecon-europe-2026-ikhcoa5cb) · CNCF · 2 upvotes · 0 comments - [CNCF Debuts KubeCon \+ CloudNativeCon Japan 2026 Schedule](https://daily.dev/posts/cncf-debuts-kubecon-cloudnativecon-japan-2026-schedule-xp5pyudub) · CNCF · 1 upvotes · 0 comments --- Tags: [#react](https://daily.dev/tags/react), [#react-hooks](https://daily.dev/tags/react-hooks) [View this post on daily.dev](https://daily.dev/posts/0b7zviajg) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/0b7zviajg","headline":"Start naming your useEffect functions, you will thank me later","text":"Shared: Start naming your useEffect functions, you will thank me later","url":"https://daily.dev/posts/0b7zviajg","datePublished":"2026-04-01T15:08:56.534Z","dateModified":"2026-04-01T15:10:10.032Z","author":{"@type":"Person","name":"Kirill Kurko","url":"https://daily.dev/kkurko","image":"https://avatars.githubusercontent.com/u/58859242?v=4","description":"Frontend Developer and Penguin 🐧 ","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":31370}},"image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":270},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":31}],"sharedContent":{"@type":"WebPage","url":"https://api.daily.dev/r/l6NalCbSx"},"comment":[{"@type":"Comment","text":"hmm I don’t think so. If you use sourcemaps (and you should) then you’ll get the exact line which has caused a js error. and you should, very much, add code-commends everywhere, in order to better understand the reasoning of each code piece which isn’t easily understandable and especially if the reasoning behind it is only known to the person who wrote it.\nI do not advise doing this and I’m a very senior frontend dev for over 20 years with maximum experience with React specifically","datePublished":"2026-04-02T07:40:18.068Z","url":"https://daily.dev/posts/0B7ZviaJG#c-ohitKvqWT","author":{"@type":"Person","name":"Yair Even Or","url":"https://daily.dev/yaireo","image":"https://avatars.githubusercontent.com/u/845031?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":12}},{"@type":"Comment","text":"I had the same realisation and found it surprising how we have normalised anonymous functions in react.","datePublished":"2026-04-04T08:22:20.314Z","url":"https://daily.dev/posts/0B7ZviaJG#c-ibWdYaJKk","author":{"@type":"Person","name":"Akash","url":"https://daily.dev/itsabluecloud","image":"https://avatars.githubusercontent.com/u/30195464?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7}},{"@type":"Comment","text":"I am a huge fan of writing my code in the idiomatic way, basically the most standard way possible, because then you dont have to teach new talent conventions, you dont have to teach ai conventions, you dont have to explain your reasoning again and again and you dont have to write a custom eslint rule to enforce it.\nIn this case, i agree that the effects in his example make you parse what they do instead of just telling you with a name upfront, so i agree on the problem.\nBut i for one usually resort in such instances to writing a comment above the useEffect, explaining it.\nNow i think that would make sense in this instance as well, as naming things is one of the hardest things in software development (Which is one of the main benefits of tailwind for example, that it removes having to name things all the time)\nBut i also don’t think naming your effects is per se bad either, like described in the article, there are debugging benefits to it and having names increases readability and you could even write an eslint rule enforcing the naming of effects.\n(And just because the other person did this as well, i also have 9 years of experience, but i strongly disagree that that is a good argument for being right or wrong)","datePublished":"2026-04-02T14:45:55.977Z","url":"https://daily.dev/posts/0B7ZviaJG#c-RrZDj3iF9","author":{"@type":"Person","name":"Fabian Letsch","url":"https://daily.dev/fabianletsch","image":"https://lh3.googleusercontent.com/a/ACg8ocKR6BVy_wn23EoOKq7-BlszlcXcLmASlnb7l-GtS-q1bePnkaJf=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":6}},{"@type":"Comment","text":"Insightful @kkurko, I will try too, as when working with Socket.Io in frontend its hard to handle every useEffects for the Socket events.\nBy applying this ‘Naming to useEffect’ would be easier to debug from where the data/ error is coming.\nThanks! man @kkurko for sharing such an helpful content.","datePublished":"2026-04-03T04:38:03.451Z","url":"https://daily.dev/posts/0B7ZviaJG#c-KEKpI2Ldz","author":{"@type":"Person","name":"Dhruv Parmar","url":"https://daily.dev/dhruvparmar92","image":"https://media.daily.dev/image/upload/s--jOgxSgKk--/f_auto/v1759592543/avatars/avatar_PNBsgn7cuO9oYjF05Ji50?_a=BAMAK+ZW0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5}},{"@type":"Comment","text":"The best thing you can do is not to use useEffects.\nI’ve created a SKILL to achieve that: https://github.com/alejandrobailo/no-use-effect","datePublished":"2026-04-02T17:11:05.643Z","dateModified":"2026-04-02T17:11:36.820Z","url":"https://daily.dev/posts/0B7ZviaJG#c-Hsk4BnYVF","author":{"@type":"Person","name":"Alejandro","url":"https://daily.dev/alejandrobailo","image":"https://lh6.googleusercontent.com/-17qx85gf__o/AAAAAAAAAAI/AAAAAAAAAAA/AMZuucnUcVHIwVjBYEkbzzfibK3BnfmnBw/s100/photo.jpg"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/ixalnaxwmtgrftz6xdx4u","name":"Kirill Kurko"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Kirill Kurko","item":"https://daily.dev/sources/ixalnaxwmtgrftz6xdx4u"},{"@type":"ListItem","position":3,"name":"Start naming your useEffect functions, you will thank me later"}]} ```