We have purposely made the decision of not allowing dynamic component creation yet (the equivalent of $A.createComponent) on the Salesforce platform to make sure we had a clean, statically analyzable and predictable behavior on which to build upon in LWC.
Note that the things we allow on the platform will always be more constraint to what you can do in LWC standalone or when is used off-platform (which will be supported officially soon).
Since the question of dynamic component creation came a bunch of times, I want to share an example of a bug that currently came to Aura long time ago that shows precisely why we decided to block it.
The following example is a simple use case where in aura you want to create dynamically (and programatically) a leaf component:
({
createComponent: function (component, facet, componentDef, fieldPath, attributes) {
// componentDef is a basic component: ex. markup://lightning:textarea
$A.createComponent(componentDef, attributes, callback);
function callback(newComponent, status, errorMessage) {
if (status === "SUCCESS") {
newComponent.addValueHandler({
value: "v.value",
event: "change",
globalId: component.getGlobalId(),
method: function (event) {
var record = component.get("v.record");
var value = event.getParam("value");
}
});
newComponent.set("v.name", fieldPath);
facet.push(newComponent);
}
}
}
})
What is wrong with this code?
1) You are potentially making a request just to fetch one simple leaf component.
2) The component has to be sent and cached somewhere, another layer of complexity.
3) It makes predictability and unit/functional testing much more harder let alone performance testing.
4) It breaks the rendering "fiber": You are losing your parent chain (forget about sending events up), you are rendering in the next tick (which has many bad perf and UI rendering side effects)
5) We are adding some crazy programmatic event handling which is much harder to read than a simple handler in the markup.
6) Dependency calculation becomes the insanity we are in right now in Aura.
Dynamic component creation should only be used in cases where you are loading a completely big, different, disconnected tree.
So the question is: Why would you want to lazy-load or dynamically create a very simple leaf component?
And the answer for 99% of the cases is for no good reason.
Does webpack route splitting sound familiar? Thats a common pattern in the industry to lazy load or preload components. But you render the whole subtree based on the route! Everything else is completely predictable down the tree.
Are there other valid use-cases? Absolutely, but 99% of the use cases fall into the declarative predictable category, rather than the dynamic craziness.
And thats why in LWC in the platform we don't allow you to shoot yourself in the foot creating small tiny components, and once we do, we will give you a water pistol first :), which means we will make it as predictable, restricted and side-effect free as possible.
Once we do allow it it will be very well documented and we will make sure we can still preserve as much as possible the invariants described above.
This is a timing issue, depending on when you are calling loadData() in your LWC and the Apex time to return the data, the iFrame may or may have not registered the listener yet.
An easy solution would be to just load the data after the iFrame finished loading:
<template>
<div>
<iframe src={viewerUrl} style={viewerStyling} onload={loadData}></iframe>
</div>
</template>
For reference, here is the MDN onload event:
Notes
The load event fires at the end of the document loading process. At
this point, all of the objects in the document are in the DOM, and all
the images, scripts, links and sub-frames have finished loading.
Best Answer
solved this by making a change in the
postmessage. Here's what I updated :this.template.querySelector('iframe').contentWindow.postMessage(this.pdfData, window.location.origin);I hope this helps someone load pdf in lwc.