<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep" -->

---
title: Data and Communication Anti-Patterns in Lightning Web...
description: A deep dive into common mistakes developers make with Lightning Web Components' wire service, public properties (@api), and event handling. Covers why @wire is...
canonical: https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Data and Communication Anti-Patterns in Lightning Web Components | daily.dev
og:description: A deep dive into common mistakes developers make with Lightning Web Components' wire service, public properties (@api), and event handling. Covers why @wire is...
og:url: https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep
og:image: https://api.daily.dev/og/posts/ivSIuytep.png
og:image:alt: Data and Communication Anti-Patterns in Lightning Web Components
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.

# Data and Communication Anti-Patterns in Lightning Web Components

**[Salesforce Developers Blog](https://daily.dev/sources/salesforcedevs)** · 11 min read · 2 upvotes · 0 comments

## Summary

A deep dive into common mistakes developers make with Lightning Web Components' wire service, public properties (@api), and event handling. Covers why @wire is a subscription rather than a one-time fetch, why mutating wire results or event.detail breaks reactivity, pitfalls like updating wire config in renderedCallback (infinite loops), mixing Apex and LDS caches, misusing refreshApex(), swapping config objects to force re-fetch, and event anti-patterns like inline .bind() calls, capture-phase listeners, and unnecessary bubbles/composed flags. Recommends notifyRecordUpdateAvailable() for cache invalidation and Lightning Message Service as a replacement for the deprecated pubsub module.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://developer.salesforce.com/blogs/2026/08/data-and-communication-anti-patterns-in-lightning-web-components>

## Questions this post answers

### Why does my Lightning Web Component show stale data after I update a record with an imperative Apex call?

Lightning Data Service (LDS) does not automatically know about writes made through imperative Apex, so every LDS wire adapter on the page keeps serving its cached, pre-mutation value. Call notifyRecordUpdateAvailable() after the write completes to signal that the record is stale, which causes all active wire adapters subscribed to it to refresh automatically.

_Anyone debugging stale LDS caches can bookmark practical fixes like this one on daily.dev._

### Why does calling refreshApex() on getRecord not refresh the data in my LWC component?

refreshApex() only works with wired Apex methods, not Lightning Data Service (LDS) adapters like getRecord; calling it on an LDS adapter is deprecated and has no reliable effect. LDS manages its own cache automatically for LDS-aware operations, and to mark a record stale after an out-of-band write you should call notifyRecordUpdateAvailable() instead.

_Developers untangling LDS caching quirks can track patterns like this through daily.dev._

### Why does my @wire adapter never re-fetch data after I reassign its config object in a Lightning Web Component?

The @wire reactive system tracks individual top-level class properties, not the config object reference or its nested contents, so replacing the whole config object does not trigger re-evaluation. Declare each reactive value as its own top-level class property and reference it with the $ prefix in the wire config so changes are detected correctly.

_daily.dev helps developers chasing LWC reactivity bugs like this keep the right fixes at hand._

## Similar posts on daily.dev

- [Security Anti-Patterns in Lightning Web Components](https://daily.dev/posts/security-anti-patterns-in-lightning-web-components-nqrjtzgez) · Salesforce Developers Blog · 0 upvotes · 0 comments
- [Component Communication Patterns in React Applications](https://daily.dev/posts/component-communication-patterns-in-react-applications-4niwdcm2o) · Neciu Dan · 18 upvotes · 1 comments
- [LWC State Managers: Share Reactive State Across Components](https://daily.dev/posts/lwc-state-managers-share-reactive-state-across-components-6c0vhv12s) · Salesforce Developers Blog · 0 upvotes · 0 comments
- [Week 41 - Preventing edit conflicts, presence feature with Action Cable, and more\!](https://daily.dev/posts/week-41---preventing-edit-conflicts-presence-feature-with-action-cable-and-more--mc0iaize6) · RUBYLAND · 0 upvotes · 0 comments
- [Optimistic UI with wire:show](https://daily.dev/posts/optimistic-ui-with-wire-show-vpvlnsqjv) · Larablog · 0 upvotes · 0 comments

---

Tags: [#webdev](https://daily.dev/tags/webdev), [#javascript](https://daily.dev/tags/javascript), [#architecture](https://daily.dev/tags/architecture), [#salesforce](https://daily.dev/tags/salesforce)

[View this post on daily.dev](https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep)

```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":"TechArticle","headline":"Data and Communication Anti-Patterns in Lightning Web Components","url":"https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep"},"datePublished":"2026-08-20T15:05:55.791Z","dateModified":"2026-09-14T08:45:51.146Z","description":"A deep dive into common mistakes developers make with Lightning Web Components' wire service, public properties (@api), and event handling. Covers why @wire is...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/aadc55fd90a9bd0e13cdabd4db689ab8?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/aadc55fd90a9bd0e13cdabd4db689ab8?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Salesforce Developers Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Salesforce Developers Blog","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/662fb7dc7cd14ee59747ed58d75cf7c3","url":"https://daily.dev/sources/salesforcedevs"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"webdev,javascript,architecture,salesforce","timeRequired":"PT11M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Salesforce Developers Blog","item":"https://daily.dev/sources/salesforcedevs"},{"@type":"ListItem","position":3,"name":"Data and Communication Anti-Patterns in Lightning Web Components"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/data-and-communication-anti-patterns-in-lightning-web-components-ivsiuytep#faq","mainEntity":[{"@type":"Question","name":"Why does my Lightning Web Component show stale data after I update a record with an imperative Apex call?","acceptedAnswer":{"@type":"Answer","text":"Lightning Data Service (LDS) does not automatically know about writes made through imperative Apex, so every LDS wire adapter on the page keeps serving its cached, pre-mutation value. Call notifyRecordUpdateAvailable() after the write completes to signal that the record is stale, which causes all active wire adapters subscribed to it to refresh automatically. Anyone debugging stale LDS caches can bookmark practical fixes like this one on daily.dev."}},{"@type":"Question","name":"Why does calling refreshApex() on getRecord not refresh the data in my LWC component?","acceptedAnswer":{"@type":"Answer","text":"refreshApex() only works with wired Apex methods, not Lightning Data Service (LDS) adapters like getRecord; calling it on an LDS adapter is deprecated and has no reliable effect. LDS manages its own cache automatically for LDS-aware operations, and to mark a record stale after an out-of-band write you should call notifyRecordUpdateAvailable() instead. Developers untangling LDS caching quirks can track patterns like this through daily.dev."}},{"@type":"Question","name":"Why does my @wire adapter never re-fetch data after I reassign its config object in a Lightning Web Component?","acceptedAnswer":{"@type":"Answer","text":"The @wire reactive system tracks individual top-level class properties, not the config object reference or its nested contents, so replacing the whole config object does not trigger re-evaluation. Declare each reactive value as its own top-level class property and reference it with the $ prefix in the wire config so changes are detected correctly. daily.dev helps developers chasing LWC reactivity bugs like this keep the right fixes at hand."}}]}
```

