If you have 10 separate components on the same lightning page that are all using the getRecord wire and retrieving approximately the same subset of fields, is there a performance penalty in comparison to having a single component that has the getRecord wire and then passes the record data to all 10 sibling components via a Lightning Message Channel message or a Dynamic Interaction?
1 Answer
Multiple requests with the exact same parameters will coalesce into a single network call, or none, if the cache is warm. If any of the parameters are different, these are not considered identical requests and will result in multiple network calls. The suggestion would be to use as few subsets of parameters as possible, as it would be less wasteful to use layoutTypes: 'Full' for all components than it would be to use layoutTypes: 'Full' and layoutTypes: 'Compact' depending on the component's needs.
For the LMS route (or other techniques), you may incur additional memory/heap usage, as the wire itself will return one object, which may then be wrapped into another object when using LMS. How much extra memory depends on a number of factors, but it could easily end up costing far more than it would to just use @wire directly. However, there are additional ways to mitigate this memory cost.
One effective technique I've found is to set up a globally shared variable. In my case, the variables are stored in a service component that just exports something like:
export default const globals = {};
Each component can then import this:
import globals from 'c/globals';
Using this technique, all of your components can share data you want to store, then use LMS, pubsub, etc to notify other components of changes. While it is true that "Global Variables Are Bad" in the general programming sense, they actually make sense in a system where we're penalized for trying to pass data around too many times. You can dramatically improve performance in complicated LWCs with shared variables.
Of course, you don't need to make them literally global; you could choose to use a different global for each subset of components that need to share data.
-
1
-
1@PhilW redux is cool, but that implementation (lwc-redux) has a least a few problems (e.g. writing to a read-only field) that may not work in all situations. Also, I feel it would have been easier to load redux as a service component than force a loadScript cost upfront. If I get some time, I might come up with a PR for it, as it certainly has potential.– sfdcfox ♦Commented Mar 23, 2023 at 13:51
-
1I only linked to that one because it specifically links LWC and redux together; my point is, you can use a state management implementation built on redux within LWCs instead of your "globals" mechanism.– Phil WCommented Mar 23, 2023 at 14:47
-
1@PhilW Fair enough. It is indeed better to use a decent library than to roll your own solution when you can.– sfdcfox ♦Commented Mar 23, 2023 at 14:57
-
@sfdcfox Thank you for the response. To reiterate what you're saying and put a fine point on it, if I have 10 distinct components on a record page where each is using the getRecord wire with different arrays of fields (e.g. component 1 retrieves fieldA, fieldB, fieldD, component 2 retrieves fieldB, fieldF, etc.) each of those wires will require a separate network call. And we could expect that to be less performant than retrieving all (let's say 25 fields) that are needed between the 10 components in a service component and exporting the record data in a global variable to the 10 components? Commented Mar 23, 2023 at 15:52